Regarding Step 2 (in the resolution section), please note the following keytool guidelines for importing certificates:
This section will provide details on enabling more verbose diagnostic data for cases where additional troubleshooting is necessary. It will walk through enabling additional logging for an example scenario. Additional details of how Java's SSL works, tracing, etc.. can be found here: https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html
In this scenario we are trying to look at the details behind the same PKIX error for this KB: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.
In this case I believe I have already imported a certificate and want to look at the certificate being received by the secure endpoint. Using the certificate's "serial number" is a pretty decent way to compare what's being received vs what is in the truststore. There are a few key items that we'll find such as:
Enable SSL Tracing On Agent:
The PKIX error appears in nolio_all.log AND nolio_action_exe.log. To begin understanding why:
The wrapper.log does NOT log the truststore used each time the truststore is referenced. It shouldn't change between agent restarts. But it is an important piece of information. If the problem is intermittent, which might happen due to a load balanced secured endpoint returned a misconfigured server, then getting/keeping the truststore information is valuable. In the end, the successful/failed ssl handshakes is determined by which truststore the agent is using. All of this is being mentioned in case you know your agents log files only capture 2 days worth of data but it took 2 weeks to see the error. In this case it is recommended to make sure you capture the "trustStore is" message and then either:
The trustStore used by the agent defaults to <AgentInstall>/jre/lib/security/cacerts. But it almost certainly can be changed (for example: possible via conf\wrapper.conf or via jre\lib\management\management.properties and possibly other ways too). Most of the areas where a alternative truststore can be specified would be done using a string similar to: -Djavax.net.ssl.trustStore=<path to truststore>
Once you've identified/confirmed the trustStore used by the agent then proceed identifying the problematic certificate received during/after the ServerHello exchange message. Do this by looking at the the details of the certificate in the "Certificate chain". The certificate with have a Subject, Signature, Validity Date, Issuer, and Serial Number as well as other information. But it is this information that you can use to verify whether that the certificate does exist in the truststore using the command: <AgentInstallDir>\jre\bin\keytool -list -v -keystore <trustStore file location identified earlier>
From the keytool output you can search for the certificates serial number. It, as well as the other properties mentioned above, should be in the trustStore. If not then this error will occur. You may not be able to identify the server that is presenting this certificate. If it is a certificate that you are not expecting and the servername where the certificate from is not available then that portion of it will need to be investigated using network tool such as wireshark or router/switch/loadbalancer logs.
Information for Technical Support:- conf\wrapper.conf.
- a copy of logs directory (with "all" tracing enabled).
- a copy of the truststore used.
There are other tools that can be used to gather more diagnostic data. For example: