000030161 - Unable to find valid certification path to requested target error when hitting Test Email in RSA Identity Management and Governance 6.9.1

Document created by RSA Customer Support Employee on Jun 14, 2016•Last modified by RSA Customer Support Employee on Apr 22, 2017
Version 3Show Document
  • Comment • 0
  • View in full screen mode

Article Content

Article Number000030161
Applies ToRSA Product Set: Identity Management and Governance
RSA Product/Service Type: Appliance
RSA Version/Condition: 6.9.1
 
IssueWhen clicking on the option to Test Email, the following error displays:
User-added image
CauseThis error is caused by the underlying system not having the root and or subordinate root certificates needed to verify the integrity of the email server's server certificate.
ResolutionTo resolve this issue,
  1. Transfer a copy of the root and subordinate root certificates (public key only) to /tmp on your IMG server.
  2. Import the certificates one at a time into our JDK trusted CA keystore.
  3. This example is where the root certificate was named root1.cer with a nickname of exchange-root1:

    1.   
      keytool -import -trustcacerts -alias exchange-root1 -file /tmp/root1.cer -keystore /etc/alternatives/jre_openjdk/lib/security/cacerts -storepass changeit

       
  4. If there are subordinate roots, adjust the alias and filename for each with their unique values, and run the above  keytool -import command for each.
  5. Using the commands below, restart IMG for the changes to the trust store to take effect:

    1.   
      su - oracle
      acm stop
      acm start

       
  6. If you have problems you may have used the wrong set of certificates.  To get a copy of the server certificate (not the root) directly from the port for verification, run this command:

    1.   
      openssl s_client -connect exchangeserver.domain.com:995

       
  7. The output will contain the server certificate PEM that you can put into a file.  To view the details of the certificate you can run this command:

    1.   
      keytool -printcert -file /tmp/pem.txt

       
  8. The server certificate will identify itself and the name of the root that issued it.
NotesIn the case where the trust store has been changed from /etc/alternatives/jre_openjdk/lib/security/cacerts, the following procedure can be used to determine the correct location set in the current JVM process for JBoss:
Use the command below to find the JBoss process.  In the output (which will be 3 or more lines), the JBoss process is the one with the longer command, not the script (.sh), or the grep command:
ps –elFa | grep jboss

The correct process line will look similar to this:
0 S oracle    7181  7083  4  80   0 - 1378441 futex_ 811840 0 Feb09 ?       07:57:47 /etc/alternatives/java_sdk_1.6.0/bin/java -Dprogram.name=run.sh -Xmx4096m -XX:MaxPermSize=512M -Djava.awt.headless=true -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/oracle -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/home/oracle/jboss/lib/endorsed -classpath /home/oracle/jboss/bin/run.jar:/etc/alternatives/java_sdk_1.6.0/lib/tools.jar org.jboss.Main -c default -b 0.0.0.0

 
Where the second number, 7181 in the above example, would be the process ID.  Use that process ID with jinfo to get the list of system properties:
 
jinfo <process ID>

 
The jinfo command will take ~30-120 seconds to complete, and JBoss (and Aveksa) will become unresponsive during that time.
 
In the output for jinfo you will see a number of system properties, key-value pairs of the form: key = value.  Locate the key javax.net.ssl.truststore, the value for that system property is your truststore file.  If the key javax.net.ssl.truststore is not present then the default (referenced in the resolution) is correct.  You can also use find to locate the default cacerts file:
find / -name cacerts

Attachments

    Outcomes