Replacing the IWSVA Admin Web Interface SSL Certificate

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 = youremailaddressgoeshere@somedomain.tld

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/emailAddress=youremailaddressgoeshere@somedomain.tld
        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
certpluschain.cer: OK

After that you can proceed with the conversion from X.509 PEM to PKCS12 explained in step number 5.

Advertisements

16 thoughts on “Replacing the IWSVA Admin Web Interface SSL Certificate

  1. This works great! Just implemented it. Any ideas on replacing the inspection cert? Running into a brick wall with Trend. I can get it to install, but it lists as invalid – this is the same wildcard that exists and works everywhere else on my network and also secures the trend captive portal from this article.

    • I’m not sure about the SSL inspection cert, it’s weird that Trendmicro wants a java keystore file for the web interface without actually stating that information anywhere, while wanting a PKCS12 (PFX) certificate for the Java applet re-signing feature.

      From what I can see in the help, they apparently want a normal X509 certificate in base64 (PEM) format for the SSL decryption stuff. In this case you would stop after step 4, or you can export it from a PKCS12 PFX file like:
      # openssl pkcs12 -in certbundle.pfx -nokeys -out cert.cer
      (Delete any extra lines that are not between the BEGIN/END CERTIFICATE.)

      In addition, the SSL inspection feature acts as a certificate authority (CA). It needs to issue its own certificates in place for the HTTPS sites being accessed.
      This is different from a static end point certificate you have on a web server (like the IWSVA web interface).
      A wildcard certificate is still just the same kind of endpoint certificate, it may be valid for a certain domain but that’s not what a CA is about. It needs to issue and sign certificates for every possible domain name out there. You need a different certificate that can act as a CA.

      The end point certificate here is being created with some parameters that make sure it can only be used for that purpose, namely:
      basicConstraints = CA:FALSE
      keyUsage = digitalSignature, keyEncipherment
      extendedKeyUsage = serverAuth

      You should instead set something like this for a generic CA certificate:
      basicConstraints = CA:TRUE
      keyUsage = cRLSign, keyCertSign
      (Remove the extendedKeyUsage)

      Maybe some other keyUsage parameters are required by IWSVA as well, I’m not sure but in that case you could try omitting keyUsage parameter completely to not force restrictions.

      You can then verify the certificate with this, it should include the CA:TRUE and other requested parameters:
      # openssl x509 -in cachain.cer -text -noout

  2. Greetings! Thanks for this awesome guide! Everything is successful for me until I put in the keystore passphrase in the web console and click Save… Then I get the following error: Failed to load key/certificate pair: No private key/end certificate pairs found in KeyStore

    Any idea what might be causing that?

    • Which IWSVA version are you using? Are you replacing a current certificate or enabling SSL for the first time?
      I don’t think I’ve had that issue but I vaguely remember one time where I ran into issues which may have been caused by using different passwords for the PFX and keystore, though I doubt that was the issue.

      Can you check the following command and whether you get similar output (especially “Entry type: PrivateKeyEntry”):
      # /usr/iwss/AdminUI/jre/bin/keytool -list -v -keystore keystore | head -15
      Enter keystore password: ***********

      Keystore type: JKS
      Keystore provider: SUN

      Your keystore contains 1 entry

      Alias name: 1
      Creation date: Jul 8, 2015
      Entry type: PrivateKeyEntry
      Certificate chain length: 3
      Certificate[1]:
      Owner: [Your end-certificate CN]

      This will export the keystore contents into test.pfx in PKCS12 format:
      # /usr/iwss/AdminUI/jre/bin/keytool -importkeystore -srckeystore keystore -destkeystore test.pfx -deststoretype PKCS12
      Enter destination keystore password:
      Re-enter new password:
      Enter source keystore password:
      Entry for alias 1 successfully imported.
      Import command completed: 1 entries successfully imported, 0 entries failed or cancelled

      You can then check whether a private key is included in the export with this:
      # openssl pkcs12 -in test.pfx -nodes -nocerts | openssl rsa -check

      To verify your server/end-certificate in included run:
      # openssl pkcs12 -in test.pfx -nodes -nokeys | openssl x509 -text -noout

  3. Thank you so much for the quick reply! We are running version 6.5.

    I ran the commands you listed and everything looked good up until this command:
    # openssl pkcs12 -in test.pfx -nodes -nocerts | openssl rsa -check

    When I ran that it gave me this:
    MAC verified OK
    Error outputting keys and certificates
    digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:535:
    PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error:p12_decr.c:97:
    PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error:p12_decr.c:123:
    unable to load Private Key
    PEM routines:PEM_read_bio:no start line:pem_lib.c:698:Expecting: ANY PRIVATE KEY

    Now, I followed your instructions explicitly except for making one change to the config file. Instead of key.rsa I put in a folder/key.rsa value to have it create a new one and when I ran it said “creating new private key” or something to that affect and it succeeded. I then used that in place of “key.rsa” wherever it was in your instructions. The reason I did this was that I followed them exactly the first time using key.rsa but when I went to import my certificate after downloading it, it would give me an error saying no matching certificate found or something to that affect.

    I REALLY appreciate your help!!!

  4. Some additional info, if I run the following command on the .pfx file created in step 5 above it succeeds with “MAC verified OK, RSA key ok”

    # openssl pkcs12 -in test.pfx -nodes -nocerts | openssl rsa -check

    But if run the steps to build the keystore, then I run the following you provided to export it back to .pfx and run the check again it fails with the provided errors.

    # /usr/iwss/AdminUI/jre/bin/keytool -importkeystore -srckeystore keystore -destkeystore test.pfx -deststoretype

    Not sure that helps any.

    Thanks!!

    • That seems odd. Sounds like the private key is not being added to the keystore file from the pfx bundle that contains certificates and private keys. Did you try using the same password in every step? Does it display as “Entry type: PrivateKeyEntry” in the step above from my comment?

      I can try to replicate it tomorrow but I currently don’t really have an idea what could be causing it.

  5. I didn’t try the same password in every step, I will try that.

    Yeah, when I ran the script above it says “Entry type: PrivateKeyEntry” just like the example you provided. Definitely odd.

    Thanks!

  6. Victory! (I think)

    I started back from the beginning with my .p7b file and went through all the instructions again this time using the same password throughout. After I had my keystore I used the steps above to re-export a .pfx from it and then check the private key and it completed successfully!! The next step is to install into my IWSVA and see if it takes it there but I’m quite certain it will. I will be attempting that tonight I believe and will let you know.

    Thanks!!!!

    • Great to hear, I hope the last step will go well.
      I’ll add a note to the article pointing out that identical pass phrases should be used. Thanks for your feedback!

  7. Greetings!
    Just wanted to follow up and let you know that after using the same pass phrase in each step everything went smoothly and I was able to complete the last of actually installing the new keystore into my IWSVA.

    Thanks again for all your help, I really appreciate it!

    • Nice! Just as an additional hint: When you upgrade to a new service pack like IWSVA 6.5 SP2, the installer actually replaces the web console certificate with a new self-signed one. So I would recommend backing up your keystore/cert+private key to some secure (offline) location.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s