PKIX or java.security.cert.CertPathValidatorException or unable to find valid certification path to requested target error

ERROR: PKIX path validation failed | subject/issuer name chaining check failed

Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: subject/issuer name chaining check failed

...

...

Caused by: java.security.cert.CertPathValidatorException: subject/issuer name chaining check failed

(OR)

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

Problem: whenever Java Attempts to connect to another application over SSL ex: HTTPS, IMAPS, LDAPS). it will only be able to connect to that application if it can trust it. the way trust is handled in java world is that you have a keystore(typically $JAVA_HOME/lib/security/cacerts), also known as truststore. this contains a list of all known Certificate Authority(CA) certificates. and java will only trust that certificates that are signed by one of those CA's or public certificates that exist in keystore.

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

Rosoultion:

1.Make sure you have imported the public certificate (root)of the target instance into the truststore.

2.Make sure any certificates have been imported into the correct truststore; you may have multiple JRE/JDKs.

importing the Public cert(root cert of server)

Ex: <JAVA_HOME>/bin/keytool -import -alias <server_name> -keystore <JAVA_HOME>/jre/lib/security/cacerts -file public.crt

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. 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.

4.If connecting to a mail server, such as Exchange, ensure authentication allows plain text.

Verify that the target server is configured to serve SSL correctly.

Alternative KeyStore Locations

Java will normally use a system-wide keystore in $JAVA_HOME/jre/lib/security/cacerts, but it is possible to use a different keystore by specifying a parameter,

-Djavax.net.ssl.trustStore=/path/to/keystore, where '/path/to/keystore' is the absolute file path of the alternative keystore.

However, setting this is not recommended because if Java is told to use a custom keystore (eg. containing a self-signed certificate),

then Java will not have access to the root certificates of signing authorities found in $JAVA_HOME/jre/lib/security/cacerts, and

 accessing most CA-signed SSL sites will fail. It is better to add new certificates (eg. self-signed) to the system-wide keystore

configuring the alternate keystore location in websphere application server

Add the trustStore information to WAS via the admin console in the

Generic JVM arguments.

->Application Servers

-> server1

-> Process Definition

-> Java Virtual Machine
in custom properties

javax.net.ssl.trustStore=/ourownLocation/cacerts
javax.net.ssl.trustStorePassword=changeit
javax.net.ssl.trustStoreType=jks



second way to fix the issue by not disclosing the password in console

Password will no longer be displayed on the process list by including the JKS password to a file in the following step.
1. Create the following file.

/usr/jksProps.txt;
=====
-Djavax.net.ssl.trustStore=/usr/IBM/abcapp.jks -Djavax.net.ssl.trustStorePassword=password
=====

2. Add the trustStore information to WAS via the admin console in the
Generic JVM arguments.

->Application Servers
-> server1
-> Process Definition
-> Java Virtual Machine

example;
-Dclient.encoding.override=UTF-8 -Xoptionsfile=/usr/IBM/jksProps.txt

3. Restart JVM