Pkix path building failed ошибка

0 Flares

Twitter


0

Facebook


0

Google+


0

LinkedIn


0

Email


—

Filament.io

0 Flares

×

How To Fix Error : sun.security.validator.ValidatorException: PKIX path building failed:

sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

You could get the error “PKIX path building failed” validation error when working on a client that works with an SSL enabled server running in https protocol. This article focuses on detecting the root cause of the error and on how to fix the issue.
There are other similar issues related the SSL certificates. One of the common situation is the missing certificate in trust store. In that case you may see the following error message.

Caused by: java.security.cert.CertificateException: No name matching localhost found at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210) at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)

See the following article to read more about the above error and its solution.

How to Fix : java.security.cert.CertificateException: No name matching localhost found

The first part of the error, “javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: “,  indicates the type of error and the second part of the error message “sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target” gives an indication on what exactly went wrong.
Before diving into the cause and solution let us get some general knowledge 🙂

What is PKIX?

PKIX is Public-Key Infrastructure X.509. PKIX is public key infrastructure standards based on X.509 protocol. X.509 is an ITU-T cryptography standard for a public key infrastructure (PKI) and Privilege Management Infrastructure (PMI). Read references for more details on The PKIX (Public-Key Infrastructure X.509) Working Group (PKIX-WG).

PKIX path building failed : sun.security.validator.ValidatorException

This error is one of the many SSL related errors you may experience when you start developing applications those communicates securely. This happens during one of the SSL Handshake phase. This exception is of type javax.net.ssl.SSLHandshakeException,  which indicates that the client and server could not negotiate the desired level of security. The connection is no longer usable.
The complete exception message is below:

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

How to Detect PKIX Path Building Failed Error?

Even though this is a common exception while connecting a service over HTTPS,  identifying the exact problem without proper debugging configuration is difficult. Unless you enable the SSL handshake debug mode (Java VM parameter -Djavax.net.debug=ssl:handshake) you will not be able to identify the root cause. Without SSL debug enabled you most likely will see the following error.

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)

The above message is more generic and in most cases will not give you the root cause of the issue. Once you enable SSL handshake debug mode you will see the following exception trace:

 http-localhost/127.0.0.1:8443-1, SEND TLSv1 ALERT: fatal, description = certificate_unknown
http-localhost/127.0.0.1:8443-1, WRITE: TLSv1 Alert, length = 2
http-localhost/127.0.0.1:8443-1, called closeSocket()
http-localhost/127.0.0.1:8443-1, 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
http-localhost/127.0.0.1:8443-1, called close()
http-localhost/127.0.0.1:8443-1, called closeInternal(true)

The above error indicates a missing trusted certificate in the trusted Java  store. Some other cases where,  you already have the certificate but there is a problem with its validity, you may see the following error (“timestamp check failed“).

handling exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed.

We will be addressing the first scenario in which there is no certificate available (certificate_unknown).

Unable to Find Valid Certification Path to Requested Target: Possible Reason For The Error

If we look at the phase of the SSL handshake we’re in, we can see that we’ve already sent our client certificate and finishing up the handshake when we receive this error.

2015-02-04 21:59:33,002 INFO  [stdout] (http-localhost/127.0.0.1:8443-2) -  - *** ServerHelloDone
http-localhost/127.0.0.1:8443-2, WRITE: TLSv1 Handshake, length = 865
http-localhost/127.0.0.1:8443-1, READ: TLSv1 Handshake, length = 865
*** ServerHello, TLSv1
RandomCookie:  GMT: 1406265764 bytes = { 30, 87, 196, 168, 159, 159, 7, 254, 62, 168, 199, 80, 108, 117, 48, 3, 113, 72, 1, 226, 31, 195, 238, 86, 88, 192, 96, 94 }
Session ID:  {84, 210, 234, 164, 204, 121, 25, 56, 166, 145, 81, 180, 26, 103, 98, 72, 207, 54, 246, 139, 136, 17, 1, 140, 50, 131, 195, 18, 157, 80, 142, 4}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: 
***
%% Created:  [Session-9, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
*** Certificate chain
Version: V3
Subject: CN=************************************
Signature Algorithm: SHA1withRSA, OID = *********************
Key:  Sun RSA public key, 2048 bits
.................................................
...................................................
***
SEND TLSv1 ALERT:  fatal, description = certificate_unknown
WRITE: TLSv1 Alert, length = 2
READ: TLSv1 Alert, length = 2
called closeSocket()
RECV TLSv1 ALERT:  fatal, certificate_unknown
called closeSocket()
handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
handling exception: 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

The above error stack trace is actually helpful. It says that “unable to find valid certification path to requested target“. This means that the certificate the server certificate is not issued by certification authority, but a self signed or issued by a private CMS. If the certificate is issued by a trusted authority (VeriSign etc) the error will not happen.

Fix for PKIX path building failed Error:sun.security.provider.certpath.SunCertPathBuilderException

All you need to do to fix this error is to add the server certificate to your trusted Java key store. First You need to download the document from the server.

To download: access the URL of the service from any browser.You will get a certificate related warning message. Click on view certificate and then Install certificate. You can export the certificate from browser to some location in hard drive (In IE go to Tools->’Internet Options’ ->Content->Certificates).

Once you have the certificate in your hard drive you can import it to the Java trust store. To import the certificate to the trusted Java key store, you can use the java ‘keytool‘ tool.
Use keytool command as follows to import the certificate to JRE.

keytool -import -alias _alias_name_ -keystore ..libsecuritycacerts -file _path_to_cer_file

It will ask for a password. By default the password is “changeit”. If the password is different you may not be able to import the certificate.
Note: You can also use the installcert java program from here.
Once completed restart/re-run your client application. You will be able to see successful SSL handshakes.

References:

1. X.509 Public-key and attribute certificate frameworks
2. Internet X.509 Public Key Infrastructure Certificate and CRL Profile RFC 2459
3. Import the Certificate as a Trusted Certificate 

Incoming search terms:

• pkix path building failed
• pkix validation failed
• PKIXPathBuildingFailed(Validation):sun security validator ValidatorException
• sun security validator ValidatorException: PKIX path building failed: sun security provider certpath SunCertPathBuilderException: unable to find valid certification path to requested target
• https://java globinch com/enterprise-java/security/pkix-path-building-failed-validation-sun-security-validatorexception/
• PKIX path building failed: sun security provider certpath SunCertPathBuilderException: unable to find valid certification path to requested target
• feign RetryableException: PKIX path building failed: sun security provider certpath SunCertPathBuilderException:
• pkix path validation failed: java security cert certpathvalidatorexception: validity check failed
• dbviewer download driver javax net ssl SSLHandshakeException:PKIX
• Couldnt download vanilla jar! sun security validator ValidatorException: PKIX path building failed: sun security provider certpath SunCertPathBuilderException: unable to find valid certification path to requested target

0 Flares

Twitter


0

Facebook


0

Google+


0

LinkedIn


0

Email


—

Filament.io

0 Flares

×

The article presents the steps to import required certificates and enable Java application to connect to Azure SQL DB/Managed Instance. If required certificates are missing on client machine when connecting via AAD authentication, a similar error will be prompted in the application logs:

«SQLServerException: Failed to authenticate the user in Active Directory (Authentication=ActiveDirectoryPassword).
Caused by: ExecutionException: mssql_shaded.com.microsoft.aad.adal4j.AuthenticationException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Caused by: AuthenticationException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. «

This is an issue in Java Certificate Store. As a quick workaround, if you enable TrustServerCertificate=True in the connection string, the connection from JDBC succeeds. When TrustServerCertificate is set to true, the transport layer will use SSL to encrypt the channel and bypass walking the certificate chain to validate trust. If TrustServerCertificate is set to true and encryption is turned on, the encryption level specified on the server will be used even if Encrypt is set to false. The connection will fail otherwise. However, for security considerations, it is not recommended to bypass the certificate validation. Hence, to address the issue, follow the steps below to change the connection string and import the required certificates. 

• Change the connection string to point to the Java certificate path

  String connectionUrl =  «jdbc:sqlserver://localhost:1433;» + 
      «databaseName=AdventureWorks;integratedSecurity=true;» + 
      «encrypt=true; trustServerCertificate=false;» + 
      «trustStore= C:Program FilesJavajdk-14.0.2libcacert;trustStorePassword=changeit»;

• Import all the certificates mentioned in this document.

  Note: To import above certificates into the keystore cacerts, please use below command and please note you must mention truststore and truststore password in the connection string to successfully connect.  
  

keytool -importcert -trustcacerts -alias TLS2 -file «C:UsersDocumentsMicrosoft RSA TLS CA 02.crt» -keystore «C:Program FilesJavajdk-14.0.2libsecuritycacerts»

Certificate was added to keystore.

Problem

Attempting to access applications or websites that are encrypted with SSL (for example HTTPS, LDAPS, IMAPS) throws an exception and the connection is refused. This can happen when attempting to establish a secure connection to any of the following:

• Active Directory server, JIRA User Server or Crowd
• Mail server 
• Another Atlassian application using Application Links
• Atlassian Marketplace
• Atlassian Migration Service

For example, the following error appears in the UI when Using the JIRA Issues Macro:

Error rendering macro: java.io.IOException: Could not download: https://siteURL/jira/secure/IssueNavigator.jspa?view=rss&&type=12&type=4&type=3&pid=10081&resolution=1&fixfor=10348&sorter/field=issuekey&sorter/order=DESC&sorter/field=priority&sorter/order=DESC&tempMax=100&reset=true&decorator=none

While the following appears in the logs:

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

Diagnosis

1. Download SSLPoke.class

2. Execute the class as per the below, changing the URL and port appropriately. Take care that you are running the same Java your application (Confluence, Jira, etc.) is running with. If you used the installer you will need to use <application-home>/jre/java

   $JAVA_HOME/bin/java SSLPoke jira.example.com 443

A failed connection would produce the below:

$JAVA_HOME/bin/java SSLPoke jira.example.com 443
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
	at sun.security.validator.Validator.validate(Validator.java:260)
	at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1351)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:156)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:925)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:860)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1043)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343)
	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:728)
	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138)
	at SSLPoke.main(SSLPoke.java:31)
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
	at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
	at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
	... 15 more

java -Djavax.net.debug=ssl SSLPoke jira.example.com 443

A successful connection would look like this:

$JAVA_HOME/bin/java SSLPoke jira.example.com 443
Successfully connected

If -Djavax.net.ssl.trustStore is present in your JVM arguments, Java will use the truststore configured instead of the default (cacerts).  You can verify whether the -Djavax.net.ssl.trustStore parameter is causing problems by running the SSLPoke test using the same JVM argument which will execute SSLPoke using your custom truststore. For example:

$JAVA_HOME/bin/java -Djavax.net.ssl.trustStore=/my/custom/truststore -Djavax.net.debug=ssl SSLPoke jira.example.com 443

If this fails (confirming that the truststore doesn’t contain the appropriate certificates), the certificate will need to be imported into your defined custom truststore using the instructions in Connecting to SSL Services.

Cause

Whenever Java attempts to connect to another application over SSL (e.g.: HTTPS, IMAPS, LDAPS), it will only be able to connect to applications it can trust.  The way trust is handled in Java is that you have a truststore (typically $JAVA_HOME/lib/security/cacerts). The truststore contains a list of all known Certificate Authority (CA) certificates, and Java will only trust certificates that are signed by one of those CAs or public certificates that exist within that truststore. For example, if we look at the certificate for Atlassian, we can see that the *.atlassian.com certificate has been signed by the intermediate certificates, DigiCert High Assurance EV Root CA and DigiCert High Assurance CA-3. These intermediate certificates have been signed by the root  Entrust.net Secure Server CA :

These three certificates combined are referred to as the certificate chain, and, as they are all within the Java truststore (cacerts), Java will trust any certificates signed by them (in this case, *.atlassian.com). Alternatively, if the *. atlassian.com  certificate had been in the truststore, Java would also trust that site.

This problem is therefore caused by a certificate that is self-signed (a CA did not sign it) or a certificate chain that does not exist within the Java truststore. Java does not trust the certificate and fails to connect to the application.

For details on how to examine a website’s certificate chain, see the section, View a certificate, in Secure Website Certificate.

Resolution

1. Make sure you have imported the public certificate of the target instance into the truststore according to the Connecting to SSL Services instructions.
2. Make sure any certificates have been imported into the correct truststore; you may have multiple JRE/JDKs. See Installing Java for this.
3. Check to see that the correct truststore is in use. If -Djavax.net.ssl.trustStore has been configured, it will override the location of the default truststore, which will need to be checked.
4. If this error results while integrating with an LDAP server over LDAPS and there is more than one LDAP server, then deselect the Follow referrals option within the LDAP user directory configuration per Connecting to and LDAP Directory.  Optionally, import the SSL certificates from the other LDAP servers into the Confluence truststore.
5. Check if your Anti Virus tool has «SSL Scanning» blocking SSL/TLS. If it does, disable this feature or set exceptions for the target addresses (check the product documentation to see if this is possible.)
6. If connecting to a mail server, such as Exchange, ensure authentication allows plain text.
7. Verify that the target server is configured to serve SSL correctly. This can be done with the SSL Server Test tool.
8. If all else fails, your truststore might be out of date. Upgrade Java to the latest version supported by your application.

More on SSL Poke

Atlassian’s SSL Poke source code can be found here.

You can find forked versions of SSL Poke in the community with support for extra features like Java 11, Proxy, etc.

Good examples:

• https://github.com/gebi/sslpoke
• https://gist.github.com/bric3/4ac8d5184fdc80c869c70444e591d3de

How do I resolve PKIX “path building failed” errors for my agent when connecting to my Controller over SSL?

When establishing a secure SSL-based connection between your agent and Controller, the agent connectivity may fail with a PKIX error — even if you followed the Enable SSL for the Java Agent documentation instructions. This may be due to configuration in your environment or in the agent.

In this article…

• What PKIX error may arise if the agent-to-Controller connectivity fails? 
• What does the PKIX path building error mean?
• What causes this error?
• What is the most convenient resolution?
• How do I import the correct certificates manually?
• How do I troubleshoot further if I continue to see PKIX errors?
• Resource Summary

What PKIX error may occur if the agent-to-Controller connectivity fails?

Even if you followed the instructions in the Enable SSL for the Java Agent documentation, given your environment OR agent configuration, the agent connectivity to your Controller over SSL may fail with the following PKIK error:

[system-thread-0] 02 Jun 2021 07:07:47,848  WARN SystemAgent - Certificate chain validation failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target attempting validation.
[system-thread-0] 02 Jun 2021 07:07:47,850 ERROR ControllerTimeSkewHandler - Fatal transport error while connecting to URL [/controller/instance/1265056/current-time]: 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
[system-thread-0] 02 Jun 2021 07:07:47,850 ERROR ControllerTimeSkewHandler - Error response from controller: Fatal transport error while connecting to URL [/controller/instance/1265056/current-time]

What does the PKIX path building error mean?

PKIX stands for Public Key Infrastructure X509. Whenever Java attempts to connect to another application over SSL, the connection will only succeed if it can trust the application. 

In Java, trust is handled with a keystore, also known as the truststore (typically <agent_home>/<version_number>/conf/cacerts.jks or <agent_home>/conf/cacerts.jks in the AppDynamics Agent context). This contains a list of all known certificate authority (CA) certificates, and Java will only trust certificates that are signed by one of the CAs or public certificates that exist within that keystore. 

See Explaining the Chain of Trust — Learn What is it & How it Works and PKIX path building failed error message – CloudBees Support to learn more.

What causes this PKIX error? 

The PKIX  ‘path building failed’ error can arise due to:

• If the agent is not able to locate the truststore (cacerts.jks), it won’t be able to validate the certificate produced by the Controller. Eventually, the PKIX ‘path building failed’ error will result.
• Some enterprises may have an SSL interpreting proxy sitting between the agents and the Controller. In such situations, the root CA’s (which issued the certificate to your proxy) SSL certificate needs to be imported into the agent’s truststore.
• In order to ensure a valid trust chain between the agent and the Controller, the intermediate certificate may also need to be imported, or the ‘PKIX path building’ will not be complete.
• It is possible that you would want to only use your application truststore. In that case, the relevant certificates need to be imported into your application truststore.

What is the most convenient resolution to the PKIX error?

The most convenient solution is to replace the Agent’s current truststore (cacerts.jks) with a working agent’s truststore (i.e., an agent sitting in the same environment as the non-working agent node in question, but that is communicating fine with the Controller). 

To accomplish this:

1. Take a backup of the cacerts.jks in the non-working agent node
2. Copy over the cacerts.jks from an agent that is working fine and move it to the cacerts.jks in the non-working agent node’s directory, below :
   

   <agent_home>/<version_number>/conf/cacerts.jks

   or

   <agent_home>/conf/cacerts.jks

3. Restart the agent and wait for 1-2 minutes. Verify whether the agent begins to report to the Controller.

If importing the truststore from an agent that is working is not an option, then follow the steps below, under Troubleshooting by manually importing the certificates.

Troubleshooting by manually importing the certificates

The following steps are a comprehensive approach to the problem.

1. Review the output of the command below:
   

   <jre-home>/bin/keytool -printcert -sslserver <controller-host>:<controller-port> > cert.out

   
   This command will print the content of the certificate being presented by the endpoint that your agent speaks to (given your environment).
   
   For example, it could be directly talking to the SaaS Controller without an SSL interpreting proxy server OR there could be an SSL interpreting proxy server being managed by your organization intercepting all outgoing communication from all agents to the Controller. As a result, you may see two or more certificates in the certificate chain and metadata for those certificates which get captured in cert.out in the above command.
2. Review the certificate chain:
   

   <jre-home>/bin/keytool -printcert -sslserver <controller-host>:<controller-port> -rfc > cert_rfc.out

   
   The above command helps us to print the raw certificate chain. Once we get this chain, it can be examined in a third-party tool called KeyStore Explorer. This helps you to visualize the certificate chain right from the top of the trust chain (i.e., the CA) down to the Controller.

3. You can directly import this cert_rfc.out file to third party tool KeyStore Explorer and export the root and the intermediate entities’ certificates one by one by following the steps as seen under the heading Export a trusted certificate.
   
   Alternatively, you may follow the steps below on the KeyStore Explorer:
   1. Select the top certificate by clicking on the top root certificate under the ‘Certificate Hierarchy’.
   2. Click on Export in the bottom-most row of the KeyStore Explorer window.
   3. As soon as you click on Export in the above step, you’ll see another window that reads as Export Certificate from entry <your-certificate-name-selected-in-step1>. With Export Format as X.509 and PEM options selected, click on Export.
   4. Similarly, extract the root and the other intermediate certificates.
   5. Import the certificates into the agent’s truststore by executing the below commands:
      

      keytool -import -file root_ca.pem -alias root_ca -keystore cacerts.jks -storepass changeit
      keytool -import -file intermediate1.pem -alias intermediate1 -keystore cacerts.jks -storepass changeit
      keytool -import -file intermediate2.pem -alias intermediate2 -keystore cacerts.jks -storepass changeit

      In the above code snippet, most of the time it will be enough to just import the root certificate. In rare cases, you might want to import the intermediate certificates as well.
      

      
      If you wish to export the certificate from the browser, then please refer to Exporting SSL certificate from your browser.
      

1. Restart the agent and after 1-2 minutes verify directly on the Controller whether the agent begins to report on the controller.

How do I troubleshoot further if I continue to see agent-related PKIX errors?

If you continue to see the PKIX errors in the agent log even after importing the correct certificates, please contact AppDynamics Support.

Resource Summary

• Enable SSL for the Java Agent
• Explaining the Chain of Trust — Learn What is it & How it Works
• PKIX path building failed error message – CloudBees Support
• Download Keystore Explorer
• Export a Trusted Certificate
• Exporting SSL certificate from your browser
• My extension is getting a ‘PKIX path building failed’ error. Why?