Hi folks,
I'm trying to integrate IGL 7.1.1 P03 with our CyberArk vault through AIM. I have general connectivity, but I can't seem to nail down the secured connection.
WSDL URL: <AIM-WSDL-URL>
Authentication: One-Way SSL
I've made sure that the root CA cert in my organisation has been added to the /var/lib/ca-certificates/java-cacerts keystore (which is symlinked to $JAVA_HOME/jre/lib/security/cacerts). Its entry type is trustedCertEntry. However, the password vault has difficultly establishing the PKIX path. There are no intermediate certificates, just the root CA and the server certificate.
com.aveksa.server.passwordvault.VaultConnectionException: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
......
curl -k <AIM-WSDL-URL> works successfully from the server CLI.
Hi!
Certificates are great when they work, but can be fickle to set up. This will be a lenghty post, but should be useful for similar issues with certificates as it is a recurring problem.
One of the tools I use for debugging them is SSLPoke with a wrapper. I'm not sure where I first found it, but it may have been at Test of java SSL / keystore / cert setup. Check the comment #1 for howto. · GitHub .
I'll post the code in full here. Along with a wrapper and a short how-to.
SSLPoke.java
wrapper.sh
If needed, you can add -Djavax.net.debug=ssl:handshake to the arguments and see a lot more debugging info regarding the certificates. Change /etc/alternatives/java_sdk_openjdk/bin/java to reflect your environment based on the binary used by wildfly.
How to run
./wrapper.sh <host> <port>
From there you can swiftly test your certificate chain to see if your changes are effective or not rather than restart IG&L for each attempt.
With the tools in place, troubleshooting can start.
Grep your processes for wildfly to figure out which jdk/jre is used by IG&lL
In my case it is /etc/alternatives/java_sdk_openjdk/bin/java
From the regular structure of the java installation we know that the cacerts used by default is located at /etc/alternatives/java_sdk_openjdk/jre/lib/security/cacerts, which is a symlink to ../../../../../../../etc/pki/java/cacerts.
This is where you must add your organizations Root CA. You may also need to add your intermediate CA.
Now if you try the SSLPoke against your CyberArk you should see a successful connection.