Remedy Single Sign On - Importing the RSSO certificates to agent / application java truststores to avoid and resolve SSL handshake errors

Knowledge Article

Article Number

000374764

Old Article Number

Article Type

Solutions to a Product Problem

Title

Remedy Single Sign On - Importing the RSSO certificates to agent / application java truststores to avoid and resolve SSL handshake errors

Summary

If you are using an https url for your sso-service-url on your AR Server, Midtier, or any other Application Servers (DWP, SmartIT, SmartRpt, TrueSight, etc), you will need to import the RSSO Certificate(s) to the java trust store on each of those servers. This should fix handshake issues from the midtier agent, AR Server or other integrated application.

Product

Remedy Single Sign On

Component

BMC Remedy Single Sign On

Applies to

Any application that integrates with RSSO. Should apply to versions prior to 19.02 as well as after 19.02.

Problem

When attempting an RSSO login on various applications including Midtier getting below error :
The RSSO server is not responding or is not available. Please contact your administrator.

Found below exception in rsso-agent.log:

javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
sun.security.ssl.Alert.createSSLException(Unknown Source)

Cause

RSSO Certificate chain was missing in Application's Java cacerts

Solution

This knowledge article may contain information that does not apply to version 21.05 or later which runs in a container environment. Please refer to Article Number 000385088 for more information about troubleshooting BMC products in containers.

Check that the RSSO server is up and running, and that you can connect to it on the correct URL and port from the application server, to confirm that it is not a connection issue. You will see handshake errors in rsso-agent.log. Which will point to an issue with the application servers trusting the RSSO certificate.

1) Open the RSSO Cert in the Windows Crypto Shell, and from there look at the Certification path / cert chain. You will see something like:

Root Cert ("CA Vendor" AddTrust root)
- Intermediate 1 ("CA Vendor" RSA Certificate Authority)
-- Intermediate 2 ("CA Vendor" RSA Domain Validation Secure Server CA)
--- RSSO Server Certificate / wildcard certificate (*.domainname.org)

2) Check the Java cacerts file (the default java truststore) on each application server (ARS, MT, DWP, SmartIT, SmartRpt) to see if each of the above certificate is present in those trust stores.

List out the certs in your trust store using keytool and see if the intermediate certs are there.
a) From a CMD/DOS window: keytool -list -keystore YourJavaHome\lib\security\cacerts > cacertoutput.txt
b) Using the windows crypto shell, look at each certificate level and use thumbprint (2d:e4:6f: etc) to search in the output file.
c) If you can't find an intermediate certificate in your trust store that matches the intermediate certs issued by your CA Vendor, export then import the missing certs with the next steps.

3) Obtain the root and intermediate certs if you don't have them. You should be able to get these from your CA. You can also use the Windows crypto shell to export copies of the certificates. When viewing a certificate in the Windows Crypto Shell, you can export a copy of that cert by:

     a) Go to the "Details" tab
     b) Click "copy to file"
     c) Select Base-64 encoded X.509 (.CER)
     d) Give the certificate a name (this can be very specific, or can just be something like root, intermediate1, intermediate2...)
     e) This will export a .cer file of the cert in question

4) Import the needed certificates to the java truststores (cacerts file) on the appropriate servers. Note that in general, you might think that just importing the root certificate would be enough, but for some reason, we've noticed that java sometimes has problems establishing trust especially if the certificate chain includes multiple intermediate certificates. For this reason, we will suggest importing the full certificate chain into each trust store (root, intermediates, and server certificate).

a) Use the keytool import command to add those certs to your trust store:
keytool -import -trustcacerts -alias "AliasNameNotAlreadyInTrustStore" -storepass TrustStorePW -file PATH\Certificates\Intermediate1.cer -keystore YourJavaHome\lib\security\cacerts
b) If the keytool tells you the cert already exists, say NO when asked to import as this means that the certificate is already present in the truststore.

5) Restart Tomcat service on the application servers to get them to pick up the new cacerts file with the added trusted certificates. Which should resolve any handshake issues for RSSO.

***As a note, there may be rare cases where the cacerts file is not the truststore in use, or is not easy to identify. To be specific, you will want to make sure that you are importing the certificates to the trust store being used by the instance of Java that the application integrating with RSSO is running on. Sometimes there may be multiple instances of Java on a server, and in rare cases, Java may be running with a specific configuration to point it to a different truststore (-Djavax.net.ssl.trustStore=/home/custom/mycacerts).

You might have to update the cacerts file after every Java update, To avoid that you can follow below steps:

- When you create a truststore (as example with Tools like keystore explorer) and add your root or intermediate certificate.
- You then can just place it somewhere in the filesystem and tell the setenv.sh (I use tomcat as an example here) where to find it:
# Truststore
export JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=/opt/bmc/java/cacerts \
-Djavax.net.ssl.trustStorePassword=changeit"

Attachment(s):