Since documentation on this by Trend Micro is pretty sparse and I’ve had to do this on a number of systems recently, I’ll document the process of replacing or adding a certificate for the IWSVA Admin Web Console with a new CA-signed one here.
Note: This documentation is NOT for replacing the IWSVA SSL-Inspection certificate, though similarities may exist.
I’ve done this successfully on IWSVA 5.6 and 6.5, the process should work without issues on IWSVA 6.0 as well.
The whole process of requesting/creating/converting the SSL certificate described here mainly involves openssl commands and can be done from the IWSVA root shell. I also generally recommend to create at least the certificate public/private key pair always on the system that will in the end host the certificate. This reduces the risk of getting the private key compromised when you create key pairs on a different system and then have to somehow transfer the key over the network or some other way (yes, you can encrypt the keys, but it’s best if the key never left the target system in the first place).
Of course you can also use any other method to create the CSR or to get the certificate file, but the following is a description of how I’m doing it.
1. So first off, we’ll create the certificate signing request (CSR) to submit to our CA for signing. Create the following openssl config file on the IWSVA machine and make sure you adjust your parameters accordingly (at least the bold red ones):
[ req ] string_mask = utf8only utf8 = yes prompt = no default_keyfile = key.rsa default_bits = 4096 encrypt_key = no default_md = sha256 req_extensions = v3_req distinguished_name = req_distinguished_name [ v3_req ] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = DNS:myiwsvaservername.domain.fqdn [ req_distinguished_name ] countryName = US stateOrProvinceName = CA localityName = Tumbleweed Town 0.organizationName = YourCompany Corp. organizationalUnitName = YourCompanyDepartment commonName = youriwsvaservername.domain.fqdn emailAddress = email@example.com
2. Now create the CSR based on this config with the following command:
# openssl req -new -config csrconfig.cfg -out certrequest.csr
This will generate a new 4096 bit private key in the file ./key.rsa for the certificate as specified in the openssl config. We can now confirm that the settings of the config file (Key length, Subject, Extensions etc) were properly adopted in the CSR by checking it with:
# openssl req -in certrequest.csr -text -noout Certificate Request: Data: Version: 0 (0x0) Subject: C=US, ST=CA, L=Tumbleweed Town, O=YourCompany Corp., OU=YourCompanyDepartment, CN=youriwsvaservername.domain.fqdn/emailAddressfirstname.lastname@example.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: ...[REDACTED]... Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: DNS:myiwsvaservername.domain.fqdn Signature Algorithm: sha256WithRSAEncryption ...[REDACTED]...
3. The base64 encoded CSR in the certrequest.csr file content can then be submitted to your CA for signing. You will get a signed certificate from your CA in return. If possible, get your certificate in .p7b (PKCS7) base64 (PEM) format including the certificate chain. If you can only get the certificate in base64 X.509 format (usually .cer, .crt file) without the certificate chain, follow the instructions I’ve described at the end of the article in the Adding the certificate chain manually section.
I will proceed with the steps for a PCKS7 file including the chain for now. First we’ll confirm our certificate was properly signed including the requested extensions with:
# openssl pkcs7 -in cert.p7b -print_certs -text -noout
This command will list all certificates in the chain, you basically only have to care about the first one which is the one you requested. It should contain the requested extensions and most likely some more added by the CA (most of which are probably normal, hopefully no useless and/or proprietary extensions you don’t need at all, tough that’s usually not really an issue).
4. Now we’ll convert the PKCS7 .p7b file to raw X.509 PEM format with:
# openssl pkcs7 -in cert.p7b -print_certs -out cert.cer
Again we can confirm the contents of the new file with (only lists the first, server certificate):
# openssl x509 -in cert.cer -text -noout
5. Now we’ll convert the just created X.509 PEM format certificate yet again to PKCS12 format (.pfx or .p12), including the private key we created in the beginning with:
# openssl pkcs12 -export -in cert.cer -inkey key.rsa -out cert.pfx
Surprise, we can confirm the contents of the certificate in this format too with:
# openssl pkcs12 -in cert.pfx -info -nokeys
# openssl pkcs12 -in cert.pfx -info -nokeys | openssl x509 -text -noout
6. Now we’re almost done and just need to convert the PKCS12 file to the final Java Keystore format we can use for import on the IWSVA web interface. This can’t be done with openssl, but with the Java keytool that is available on the IWSVA or from some other Java installation:
# /usr/iwss/AdminUI/jre/bin/keytool -importkeystore -destkeystore keystore -srckeystore cert.pfx -srcstoretype PKCS12
Caution: You should use the same pfx/keystore pass phrase for all commands in steps 5 and 6, otherwise the private key may get lost on the way to the keystore! See comments of this article.
The output format is a bit harder to read, but we can confirm the keystore contents that should include all our certificates with (the latter command will only show the end-certificate in X.509 style):
# /usr/iwss/AdminUI/jre/bin/keytool -list -v -keystore keystore
# /usr/iwss/AdminUI/jre/bin/keytool -list -rfc -keystore keystore | openssl x509 -text -noout
7. Backup the current keystore in case something goes wrong (only required if you’re replacing an existing certificate):
# cp –preserve /var/iwss/AdminUI/tomcat/keystore /root/keystore.bak
In case you need to manually replace the file when something goes wrong, make sure the file owner and group are set to “iscan” or configure it accordingly:
# chown iscan:iscan /var/iwss/AdminUI/tomcat/keystore
# ll /var/iwss/AdminUI/tomcat/keystore
-rw-rw-rw- 1 iscan iscan 8027 Feb 26 15:47 /var/iwss/AdminUI/tomcat/keystore
8. Now that everything is ready, we can proceed to replace the actual certificate on the IWSVA. Download the resulting keystore file and open the IWSVA web console.
Browse for the keystore file and hit the Upload button.
Next, input the passphrase for the keystore you entered when you converted from PKCS12 to Java keystore, set the port number and hit Save.
Caution: This will restart all IWSVA services and as such disrupt network traffic through this IWSVA node.After the services have been restarted, you will be redirected to the IWSVA login prompt. You can check the certificate in your browser or via openssl with:
# openssl s_client -connect myiwsvaserver.domain.fqdn:8443 | openssl x509 -text -noout
(May not work from the IWSVA server shell directly because of silly iptables firewall rules that don’t allow a connection from localhost.)
On a side note, when installing a new service pack like IWSVA 6.5 SP2, your custom certificate is actually replaced with a generic new self-signed one! So it’s better to back up your keystore/cert+private key to a secure offline location.
Adding the certificate chain manually
If you can’t download a PKCS7 format (.p7b) file from your CA but just the certificate and chain file separately (X.509 certificates in base64 encoded PEM format), then just append the contents of the chain file to your certificate file (e.g. cat cert.cer chain.cer > certpluschain.cer) so it looks similar to this:
-----BEGIN CERTIFICATE----- [your base64 encoded end-server certificate] -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- [base64 encoded intermediate CA certificate, possibly multiple entries like these depending on the depth of the chain] -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- [base64 encoded root certificate] -----END CERTIFICATE-----
The following commands can be used to confirm the certificate contents (lists the first, server one) and verify that the certificate chain is correctly contained:
# openssl x509 -in certpluschain.cer -text -noout
# openssl verify -CAfile certpluschain.cer certpluschain.cer
After that you can proceed with the conversion from X.509 PEM to PKCS12 explained in step number 5.