The problem we are seeing is when we go into Catalog and initiate a request. Catalog kicks off an ITPAM workflow, which is supposed to create a ticket in SDM but instead throws the following soap error. The ticket never gets created.
<ErrorMessage>INVALID ; nested exception is:
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to request target; nested exception is
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to request target
CA Process Automation 4.3 and up
CA Service Desk Manager 17.3 and up
The error message suggests the application is trying to communicate with the other application through SSL but cannot handshake because it does not know it. We need to import the certificate(s) of the other application into the application that is trying to communicate.
Example: If you get the error in SDM, you would need to get all the certificate(s) from the other application (ie: ITAM/PAM/Catalog) and import them into the SDM keystore and the Java cacerts and restart services for the changes to take effect.
To import certificate(s) into the SDM Keystore:
pdm_perl pdm_keystore_mgr.pl -import <file.cer>
## Repeat the above pdm_perl command to import all needed certificates into the certificate chain for <file.cer>
Optionally run these commands to view the certificates in the NX.keystore:
pdm_perl pdm_keystore_mgr.pl -list -v
If the issue remains, import the certificate(s) into the Java cacerts being used by SDM (you can check this in NX.env to confirm the Java being used) using keytool.exe from the Java bin folder.
ie: keytool -import -trustcacerts -alias root -file <path to root certificate file> -keystore <path to java cacerts>
To resolve this problem, we downloaded the ITPAM certificate from the browser, copied the certificate file to all SDM servers, and used the above pdm_keystore_mgr.pl command to import it into the SDM keystore for all SDM servers.
The problem can also manifest in the other direction, for example, Service Desk or Service Catalog not being able to communicate with ITPAM. Here is an article about this scenario: