Gfrktyl

I have the below ElasticSearch configuration, where ES is configured to trust both the root CA and the issuing CA. (The LDAP1 realm contains the relevant information.)

xpack:

  security:

    enabled: true

    transport:

      ssl:

        enabled: true

        verification_mode: certificate

        keystore:

          path: /etc/elasticsearch/security/elastic-certificates.p12

        truststore:

          path: /etc/elasticsearch/security/elastic-certificates.p12

    http:

      ssl:

        enabled: true

        verification_mode: certificate

        certificate_authorities: ["/etc/elasticsearch/security/rootCA.pem", "/etc/elasticsearch/security/issuingCA.pem"]

        certificate: "/etc/elasticsearch/security/elstcweb1.company.com.cer"

        key: "/etc/elasticsearch/security/elstcweb1.company.com.key"

    authc:

      realms:

        native:

          type: native

          order: 0

        ldap1:

          type: ldap

          order: 1

          url: "ldaps://ldapserver.company.com:636"

          bind_dn: "user"

          user_search:

            base_dn: "redacted"

          group_search:

            base_dn: "redacted"

          ssl:

            certificate_authorities: ["/etc/elasticsearch/security/rootCA.cer", "/etc/elasticsearch/security/issuingCA.cer"]

However, when attempting to log in to the service, I am receiving the below LDAP exception.

[es-prod-1] Authentication to realm ldap1 failed - authenticate failed (Caused by LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to connect to server ldapserver.company.com:636:  java.io.IOException: LDAPException(resultCode=91 (connect error), errorMessage='Unable to verify an attempt to to establish a secure connection to 'ldapserver.company.com:636' because an unexpected error was encountered during validation processing:  SSLPeerUnverifiedException(message='peer not authenticated', trace='getPeerCertificates(SSLSessionImpl.java:440)

I was initially informed that root and issuing CA certificates were those that were used to sign the LDAP servers certificate. However, when troubleshooting using openssl verify, I received the following exception, which led me to believe that may not be the case:

openssl verify -verbose -CAfile /etc/elasticsearch/security/[rootCA.cer,issuingCA.cer,combinedRootIssuingCA.cer] ldap.pem

ldap.pem: C = US, L = REDACTED, O = REDACTED, OU = DSS, CN = ldapserver.company.com, emailAddress = REDACTED

error 20 at 0 depth lookup:unable to get local issuer certificate

I obtained the LDAP server's certificate (ldap.pem in the above example) via openssl s_client:

openssl s_client -connect ldapserver.company.com:636 2>/dev/null </dev/null |  sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ldap.pem

Given the above, is my assessment that the certificate of the LDAP server was not signed by the root/issuing CA correct? Or was the s_client method not the appropriate way to obtain the LDAP server's CA?

EDIT: Full error message with manually inserted line breaks:

[2019-01-21T15:03:22,268][WARN ][o.e.x.s.a.AuthenticationService] [es-prod-1] Authentication to realm ldap1 failed - authenticate failed (Caused by LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to connect to server ldapserver.company.com:636:  java.io.IOException: LDAPException(resultCode=91 (connect error), errorMessage='Unable to verify an attempt to to establish a secure connection to 'ldapserver.company.com:636' because an unexpected error was encountered during validation processing:  SSLPeerUnverifiedException(message='peer not authenticated', trace='getPeerCertificates(SSLSessionImpl.java:440) 

 verifySSLSocket(HostNameSSLSocketVerifier.java:113) 

 <init>(LDAPConnectionInternals.java:166)  connect(LDAPConnection.java:860) 

 connect(LDAPConnection.java:760) 

 connect(LDAPConnection.java:710) 

 <init>(LDAPConnection.java:534) 

 getConnection(SingleServerSet.java:229) 

 getConnection(ServerSet.java:98) 

 getConnection(FailoverServerSet.java:545) 

 createConnection(LDAPConnectionPool.java:1205) 

 createConnection(LDAPConnectionPool.java:1178) 

 getConnection(LDAPConnectionPool.java:1706) 

 doPrivileged(AccessController.java:native) 

 privilegedConnect(LdapUtils.java:75) 

 searchForEntry(LdapUtils.java:258) 

 searchForEntry(LdapUtils.java:210) 

 findUser(LdapUserSearchSessionFactory.java:225) 

 getSessionWithPool(LdapUserSearchSessionFactory.java:78) 

 session(PoolingSessionFactory.java:101) 

 lambda$doAuthenticate$1(LdapRealm.java:125) 

 doRun(LdapRealm.java:283) 

 doRun(ThreadContext.java:723) 

 run(AbstractRunnable.java:37) 

 runWorker(ThreadPoolExecutor.java:1149) 

 run(ThreadPoolExecutor.java:624) 

 run(Thread.java:748)', revision=24201)')'))

There ended up being a third CA that needed to be trusted. This CA signed their LDAP server's VIP cert.