Replacing the server certificate used for the RSA Identity Governance & Lifecycle appliance web administration interface

[#1]

Article Number

000030130

Applies To

RSA Product Set: Identity Governance & Lifecycle
RSA Product/Service Type: Appliances and Software Appliances
RSA Version/Condition: 6.8.x, 6.9.x, 7.x

Issue

Newer browsers are throwing the following error when the Subject Alternative Name (SAN) attribute is not present:
 

NET::ERR_CERT_COMMON_NAME_INVALID

Resolution

For versions 6.8.x and 6.9.x

• JBoss will load keystores and truststores based on the configuration found in /home/oracle/jboss-4.2.2.GA/server/default/deploy/jboss-web.deployer/server.xml.
• By default, the keystores and truststores are found in /home/oracle/jboss-4.2.2.GA/server/default/conf/keystore.

For version 7.0.x

• WildFly will load keystores and truststores based on the configuration found in /home/oracle/wildfly/standalone/configuration/aveksa-standalone-full.xml.
• By default, the keystores and truststores are found in /home/oracle/keystore

If your goal is to modify the web server certificate that a user sees when connecting to the Identity Governance & Lifecycle web console, you will need to edit the keystore called aveksa.keystore. After modification, this keystore should contain the web server's private key, its associated signed certificate, and all CA certificates up to the root CA.
 

The following commands assume you will be creating a new keystore file called my.keystore which will later be used to replace the existing aveksa.keystore. The example below utilizes a server hostname of rsa-img.rsa.com, and can be accessed using a hostname alias access.rsa.com or IP 1.1.1.1, as well.

1. Go to the default keystore and truststore location for your version:

• For versions 6.8.x and 6.9.x

cd /home/oracle/jboss-4.2.2.GA/server/default/conf/keystore

• For version 7.0.x

cd /home/oracle/keystore

2. Create a new keystore file and new RSA 2048-bit keypair, using the password Av3k5a15num83r0n3 when prompted.  This example creates a certificate valid for the URLs using rsa-img.rsa.com, rsa-img, access.rsa.com, and 1.1.1.1.  If you are using Java 6, then the -ext will report an Illegal option -ext error, so please see the Notes section below for the work-around.  (The alias name must be "server".  See the Notes section.)

keytool -genkeypair -keysize 2048 -alias server -keyalg RSA -keystore my.keystore -dname "CN=rsa-img.rsa.com" -ext san=dns:rsa-img.rsa.com,dns:rsa-img,dns:access.rsa.com,ip:1.1.1.1

3. Generate a certificate request (PKCS#10) from that keypair, use the password Av3k5a15num83r0n3 when prompted:

keytool -certreq -alias server -file rsa-img.rsa.com.csr -keystore my.keystore -ext san=dns:rsa-img.rsa.com,dns:rsa-img,dns:access.rsa.com,ip:1.1.1.1

4. Submit the certificate request (rsa-img.rsa.com.csr) to your CA for signing.  The steps below assume the following:

• cert.pem is the newly signed certificate generated from the certificate request
• sub.pem is the issuing CA of the certificate.
• root.pem is the root CA that signed the issuing CA sub.pem

5. Import the root CA in the default truststore (cacerts) as a trusted CA component (The default password is changeit😞

keytool -import -v -trustcacerts -alias root -file root.pem -keystore $JAVA_HOME/jre/lib/security/cacerts

6. Import the issuing CA in the default truststore (cacerts) as a trusted CA component (The default password is changeit😞

keytool -import -v -trustcacerts -alias sub -file sub.pem -keystore $JAVA_HOME/jre/lib/security/cacerts

7. Import the root CA into the keystore as a trusted CA component.  Enter "yes" when prompted, because the root certificate is already in the cacerts file, but is also needed in the keystore we are building:

keytool -import -v -trustcacerts -alias root -file root.pem -keystore my.keystore
Certificate already exists in system-wide CA keystore under alias <root>
Do you still want to add it to your own keystore? [no]: yes
Certificate was added to keystore

8. Import the issuing CA in the keystore as a trusted CA component:

keytool -import -v -trustcacerts -alias sub -file sub.pem -keystore my.keystore

9. Import the certificate in the keystore:

keytool -importcert -v -alias server -file cert.pem -keystore my.keystore

10. You can review the keystore entries with the following command:

keytool -list -v -keystore my.keystore

11. Make a copy of your current keystore file should you need to revert the changes:

cp -fp aveksa.keystore aveksa.keystore.ori

12. Make sure the file permissions, and ownership of the new my.keystore match that of aveksa.keystore:

ls -l *.keystore

13. Replace aveksa.keystore with my.keystore and restart the services:

cp my.keystore aveksa.keystore
chown oracle:oinstall aveksa.keystore
acm restart

14. Hit the appliance login page using a browser and verify that the new certificate is being presented by the appliance.

To revert these changes, run the following commands:
mv aveksa.keystore my.keystore
cp aveksa.keystore.ori aveksa.keystorechown oracle:oinstall aveksa.keystore
acm restart

Notes

The -ext option to specify a Subject Alternative Name (SAN) is not available in keytool for Java 6. This impacts any system running IMG 6.9.x or lower. You can work around this by working with the keystore on a system with Java 7 or 8 (e. g., a Windows desktop) and transferring the completed keystore file to the Identity Governance & Lifecycle server.

Note that the Identity Governance & Lifecycle WildFly server references the certificate specifically using the alias name "server".   If any alias name other than "server" is used the steps above will complete but the resultant keystore will not be usable by RSA IG&L.