• Product: RSA Identity Governance & Lifecycle
• Versions: 6.8.x, 6.9.x, 7.x,8.x
• Component: Web Console
• Tool: Java keytool utility
• Operating System: Linux

 Browsers are throwing "Not Secure" while accessing the application

NOTE: The commands below use the following example placeholders — replace them with your actual values:

1. Log in to the application server as the oracle user.
2. Navigate to the keystore directory 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

3. Back up the existing keystore before making any changes:

   cp -fp aveksa.keystore aveksa.keystore.ori

   CAUTION: Do not skip this step. If the new keystore is invalid, you will need this backup to restore service. Verify the backup file exists before continuing:

   ls -l aveksa.keystore.ori

4. Create a new keystore file and generate a new RSA 2048-bit keypair. When prompted for a password, enter your_keystore_password(Av3k5a15num83r0n3):

   keytool -genkeypair -keysize 2048 -alias server -keyalg RSA -keystore my.keystore -dname "CN=your-server.example.com" -ext san=dns:your-server.example.com,dns:your-server-short,dns:your-alias.example.com,ip:your.server.ip

   CAUTION: The alias name must be server. If any other alias name is used, the resulting keystore will not be recognized by RSA Identity Governance & Lifecycle and the web console will fail to start.

   NOTE: If you are running Java 6 (versions 6.9.x or lower), the -ext flag is not supported and will return Illegal option: -ext. See the Notes section for the Java 6 workaround.

5. Generate a Certificate Signing Request (CSR) from the keypair. When prompted, enter your_keystore_password:

   keytool -certreq -alias server -file your-server.example.com.csr -keystore my.keystore -ext san=dns:your-server.example.com,dns:your-server-short,dns:your-alias.example.com,ip:your.server.ip

6. Submit the CSR file (your-server.example.com.csr) to your Certificate Authority (CA) for signing. The remaining steps assume your CA returns the following files:

   File	Description
   cert.pem	The newly signed server certificate
   sub.pem	The issuing (intermediate) CA certificate
   root.pem	The root CA certificate

7. Import the root CA into the default Java truststore (cacerts). When prompted, enter the cacerts password (default: changeit):

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

8. Import the issuing CA into the default Java truststore (cacerts):

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

9. Import the root CA into the new keystore. When prompted "Do you still want to add it to your own keystore? [no]:", type yes:

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

   Expected output:

   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

10. Import the issuing CA into the new keystore:

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

11. Import the signed server certificate into the new keystore:

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

12. Verify the contents of the new keystore and confirm all entries are present (root CA, issuing CA, and server certificate):

    keytool -list -v -keystore my.keystore

13. Confirm the file permissions and ownership of my.keystore match those of aveksa.keystore:

    ls -l *.keystore

14. Replace aveksa.keystore with the new keystore:

    cp my.keystore aveksa.keystore

15. Set the correct ownership on the replaced keystore:

    chown oracle:oinstall aveksa.keystore

16. Restart the RSA Identity Governance & Lifecycle services:

    acm restart

Verification: Open a browser and navigate to the RSA Identity Governance & Lifecycle web console login page. Click the padlock icon in the browser address bar and confirm the new certificate is being presented, is trusted, and shows the correct SAN entries.

Reverting the Change

If the new certificate causes issues, restore the original keystore and restart services:

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

Notes

• Java 6 Workaround (Versions 6.9.x and Lower): The -ext flag used in Steps 4 and 5 to specify Subject Alternative Names (SANs) is not available in keytool for Java 6. To work around this, perform Steps 4 and 5 on a separate machine that has Java 7 or Java 8 installed (e.g., a Windows workstation). Once the keystore (my.keystore) is complete, use scp or another secure file transfer method to copy it to the application server, then continue from Step 6.
• Configuration File Locations by Version: The keystore and truststore locations referenced in this article are controlled by the following configuration files:
  • Versions 6.8.x and 6.9.x (JBoss): /home/oracle/jboss-4.2.2.GA/server/default/deploy/jboss-web.deployer/server.xml
  • Version 7.0.x (WildFly): /home/oracle/wildfly/standalone/configuration/aveksa-standalone-full.xml
• Related Article: How to Update the Root (Server) and Client Certificates in RSA Identity Governance & Lifecycle — use this article if you need to update the certificates used for AFX Server and remote collection agent communication, not the web console certificate.
• Search Keywords: replace certificate, web server certificate, SSL certificate, TLS certificate, SAN, Subject Alternative Name, NET::ERR_CERT_COMMON_NAME_INVALID, aveksa.keystore, keytool, JBoss, WildFly, IMG, Aveksa, ACM, Via L&G, Identity Governance, IGL, certificate expired, certificate renewal.