Unable to Login to Pulse via LDAPS due to "PKIX path building failed" in Pivotal GemFire
search cancel

Unable to Login to Pulse via LDAPS due to "PKIX path building failed" in Pivotal GemFire

book

Article ID: 294092

calendar_today

Updated On:

Products

VMware Tanzu Gemfire

Issue/Introduction

Symptoms:

When attempting to log in to Pulse with an LDAP over SSL (LDAPS) user, it throws the following exception and fails to login:

HTTP ERROR 401

Problem accessing /pulse/j_spring_security_check. Reason:
Authentication Failed: simple bind failed: centos7v64.myexample.com:636; nested exception is javax.naming.CommunicationException: simple bind failed: centos7v64.myexample.com:636 [Root exception is 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]

Powered by Jetty://

Environment


Cause

Whenever Java attempts to connect to another application over SSL (e.g.: HTTPS, IMAPS, LDAPS), it will only be able to connect to that application if it can trust it. The way trust is handled in the Java world is that you have a truststore, typically in $JAVA_HOME/lib/security/cacerts. This contains a list of all known Certificate Authority (CA) certificates, and Java will only trust certificates that are signed by one of those CA's or public certificates that exist within that truststore.

In this case, Pulse attempts to connect to LDAPS via the spring security framework internally. It uses j_spring_security_check to check whether the truststore (cacerts), on the host that is hosting the Pulse web application, contains the right LDAPS certificate. If it doesn't find the right LDAPS certificate, j_spring_security_check will throw out the error shown in the Symptom section:

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

Resolution

You may consider using -Djavax.net.ssl.trustStore to override the location of the default truststore and let the java process find the right LDAPS certificate, but for this case, the quick resolution is to import the LDAPS certificate (truststore file) into the truststore (cacerts) where Pulse is hosted by using the keytool utility.

Example:

keytool -import -file /etc/pki/tls/certs/myexampleldap.pem -keystore $JAVA_HOME/jre/lib/security/cacerts