Streaming application error: PKIX path building failed: unable to find valid certification path to requested target

Streaming application error: PKIX path building failed: unable to find valid certification path to requested target

book

Article ID: KB0072595

calendar_today

Updated On:

Products Versions
TIBCO Streaming 10.6 and later

Description

My Streaming application needs to make a secure (SSL/TLS) connection to a remote server. However, I get the following error when I start my application:
 
 2022-01-28 16:44:12.018000+0300 [14024:apd9773-216] ERROR com.tibco.ep.dtm.stderr:   sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

How can I determine the cause of this error and resolve it?

Issue/Introduction

Provides general guidance on enabling javax.net.debug log messages to troubleshoot the error noted in the article title.

Resolution

This error indicates that the remote server's issuer certificate (and possibly the issuer's root CA certificate) has not been added to the Streaming application's trust store. This is required for the Streaming client to make a successful SSL/TLS connection.

To determine what certificates are needed, enable SSL debug logging by adding the following system property to your SB Engine HOCON configuration :
 
 systemProperties = {   "javax.net.debug" = "all" }

Alternatively, you can add this to your jvmArgs section in the SB Engine HOCON configuration:
 
 jvmArgs = [   "-Djavax.net.debug=all" ]

Or, add it to your Studio Run Configuration, which may be more convenient when testing fragments in Studio:

ssl debug run config

Then run your Streaming application again, and collect the resulting console log.

NOTE: It is generally best not to attempt to read the Console view in Studio. Instead, use a capable text editor such as Notepad++ to search through the log. As soon as the error is reproduced, you may stop the Streaming application and review the log file. By default, the console log will be placed under /path/to/your/workspace/.nodes/<NodeName>/logs/, and the default trust store used by your Streaming application is located at $TIBCO_HOME/sb-cep/x.y/jdk/lib/security/cacerts.

In the resulting debug console log, you will see the remote server present its public certificate to the client in the following log entry:
 
 2022-01-28 16:44:11... ERROR com.tibco.ep.dtm.stderr: javax.net.ssl|DEBUG...|2022-01-28 16:44:11.983 AST|CertificateMessage.java:366|Consuming server Certificate handshake message ( 2022-01-28 16:44:11... "Certificates": [ 2022-01-28 16:44:11...   "certificate" : { 2022-01-28 16:44:11...     "version"            : "v3", 2022-01-28 16:44:11...     "serial number"      : "21 00 00 27 87 68 48 64 4B 71 35 47 0D 00 00 00 00 37 68", 2022-01-28 16:44:11...     "signature algorithm": "SHA256withRSA", 2022-01-28 16:44:11...     "issuer"             : "CN=My Issuer CA, DC=domain, DC=com", 2022-01-28 16:44:11...     "not before"         : "2020-09-08 10:58:38.000 EST", 2022-01-28 16:44:11...     "not  after"         : "2022-12-07 10:58:38.000 EST", 2022-01-28 16:44:11...     "subject"            : "CN=Remote Server",

Here, we can see that the remote server's certificate was issued by ' CN=My Issuer CA, DC=domain, DC=com'. This issuer certificate must be added to the Streaming application's trust store.

To confirm which certificates have been added to the trust store, inspect the debug console log for the following entry (which will occur earlier in the log):
 
 2022-01-28 16:42:22.789000+0300... adding as trusted certificates (

Immediately below this line will be a list of certificates. These are the certificates that the running jvm has detected in the ' cacerts' trust store. Inspect this list for the issuer's common name ( CN=My Issuer CA, DC=domain, DC=com):
 
 2022-01-28 16:42:22...   "certificate" : { 2022-01-28 16:42:22...     "version"            : "v3", 2022-01-28 16:42:22...     "serial number"      : "45 37 D0 CC 7D 2B 6D 92 59 E5 36 88 62 9F AA CB", 2022-01-28 16:42:22...     "signature algorithm": "SHA256withRSA", 2022-01-28 16:42:22...     "issuer"             : "CN=Root CA, DC=domain, DC=com", 2022-01-28 16:42:22...     "not before"         : "2015-02-17 12:50:20.000 EST", 2022-01-28 16:42:22...     "not  after"         : "2035-02-17 12:50:20.000 EST", 2022-01-28 16:42:22...     "subject"            : "CN=My Issuer CA, DC=domain, DC=com", 2022-01-28 16:42:22...     "subject public key" : "RSA",

Here, we can see that the remote server's issuer certificate exists in the trust store. However, in some cases, the certificate may not be listed under the " adding as trusted certificates" debug log entry. In that case, you would then need to import the issuer certificate into the cacerts trust store. This can be done using the keytool utility provided with your Streaming JDK installation. For example..
 
 keytool -import -alias MyIssuerCA -file MyIssuerCA.cer -storetype JKS -keystore C:\TIBCO\sb-cep\10.6\jdk\lib\security\cacerts -keypass changeit

If your debug console log does list the remote server's issuer certificate in the Streaming application's trust store, then inspect the ' issuer' attribute. In the above example, the issuer of ' CN=My Issuer CA, DC=domain, DC=com' is ' CN=Root CA, DC=domain, DC=com'. That means you would also need to add the root CA certificate (i.e. the certificate whose 'subject' attribute is CN=Root CA, DC=domain, DC=com) to the trust store.

Also, confirm that the ' serial number' values (shown in each of the above log entries) are the same. In some cases, the Subject and Issuer values match, but the serial numbers do not match.

Finally, confirm that the certificate is not expired by inspecting the ' not after' value shown in the above log entries (which is the expiration date for that certificate). If needed, regenerate the certificate to have a valid expiration date.