AWI: PKIX path building failed ... unable to find valid certification path to requested target

[Michael A. Lowry]

A couple of weeks ago, I posted a thread: JCP error: U00045101 The alias "jetty" does not exist in the keystore 'keystore'.

I was pleased to find a solution, and developed a script to automate the process of converting the certificate chain provided by the certificate authority to the sort of key store required by the JCP. Then a few days ago I tried out the script on another Automation Engine server. It appeared to work fine, and the JCP started up with SSL enabled. I confirmed that I was able to connect to the JCP over SSL using Postman. However, I noticed a problem immediately in the AWI. The following error appeared when I tried to log in.

com.uc4.ecc.backends.exceptions.AutomationEngineAPIException: Can't connect to any REST-endpoint, please check if at least one JCP is running and is reachable via network.

When I looked in the AWI log, I saw the following error:

Can't connect to REST endpoint... PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Has anyone seen this before?

[Marcin Uracz]

Hi Michael,

Yeah. In my cases it indicated that the Java installation that you use on you Tomcat ( I assume ) does not have the Root CA or the intermediate certificates imported into the trust store. 

Solved by doing the following:

https://docs.oracle.com/cd/E19906-01/820-4916/geygn/index.html

The trust store you will find in lib/security/cacerts

Of the Java Installation. 

[Michael A. Lowry]

I fixed the problem by making two changes:

1. I changed the value of the hostname parameter in the ucsrv.ini file to the host alias (DNS CNAME record) instead of the host name (DNS A record). This is because the server certificate I obtained for the JCP is based on the host alias.
   Before, the hostname parameter was set to the host's ordinary hostname (DNS A record). However, the server certificate was issued in the name of the host's alias (DNS CNAME record). This mismatch may have caused the AWI not to trust the certificate provided by the JCP.
   I learned from AWI log entries that when the AWI starts up, it connects to the CP and that these endpoints are based on the hostname parameter in the ucsrv.ini file. (I realized that the AWI might not trust the server if there were a difference between the endpoint the AWI is trying to connect to and the name in the certificate provided by that server.)
2. I added our company's CA certificates file to the META-INF directory of the AWI installation directory (extracted from the awi.war file), and added the following system properties to the JAVA_OPTS variable set before starting the AWI: '-Duser.timezone=Europe/Zurich -Djavax.net.ssl.trustStore=$PWD/META-INF/cacerts'. The cacerts file was provided by the team that administers our company's certificate authority (CA). This change was important to make the AWI trust the certificate provided by the JCP.

It would be helpful the above two steps were also added to the KB article How to implement HTTPS for JCP.

I updated my own JCP SSL instructions.

Ping @Elina McCafferty