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