Error received in SDM:
There is a problem accessing CA IT PAM Workflow - please try again or contact the administrator. Details: ; nested exception is: java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)
This happens when attempting to select a CA IT PAM Definition from a macro action information within SDM.
Errors in SDM log as follows:
12/19 10:26:05.26 ESMDEV-SDM web:local 6780 ERROR freeaccess.spl 34520 Error invoking class: com.ca.ServicePlus.pdm_rpc.ItpamWorkflow 12/19 10:26:05.31 ESMDEV-SDM web:local 6780 SIGNIFICANT session.c 4083 This request took 4487 milliseconds to complete. session id:1180496243 login name:OR0199896 htmpl name:wfITPAMdef.htmpl
I did notice that the upgrade to 184.108.40.206 cleared out the CACERTS in the CA/JC folder for the JRE. I have returned those values and upgraded the server_secondary.ver file as we have done in the past and as it is called in the documentation.
We have never gotten this kind of error on 220.127.116.11.
PAM is currently operating on 4.3.03
JAVA version on PAM is JRE1.8.0_191 (Upgraded to meet minimum requirements of PAM 4.3.03)
JAVA version on CA SDM is JRE1.8.0_112 (Packaged JRE)
This mismatch was NOT a problem on 18.104.22.168 confirmed. But appears to be a problem on 22.214.171.124.
I'm wondering if the issue is not more with the cacerts in Java/lib/security/ as we do not upgrade JRE as part of 17.1.02
I am suspecting that the NX_ROOT/pdmconf/nx.keystore file somehow lost its connection. Usually SDM -> PAM / SDM -> Catalog etc., those integrations happen through this keystore.
I'd recommend raising a case with support on this for one of us to look into this with you further.
The nx.keystore is actually not something that we use. PAM is balanced through an Apache LB. The connections between SDM and PAM pass-thru that LB. Which overwrites the PAM SSL connections from having to be used. We discovered that we could apply the SSL used by the Apache LB directly to the SDM cacerts store and that resolved the problem. I applied the root, imt, and base to that store.
Typically in the past when the SSL certs themselves were not working a handshake error was given. This new error shown above is quite a bit different than anything we've gotten in the past.
I have also opened up a case with you guys to investigate this as well.
I also upgraded just now to 191 to match PAM. Error persists exactly the same.
Just curious if it resolved yet? was it anything to do with missing NX_KEYSTORE_REF in nx.env ?