1 votes

ElasticSearch ne parvient pas à authentifier l'hôte LDAP

J'ai la configuration ElasticSearch ci-dessous, où ES est configuré pour faire confiance à la fois à l'autorité de certification racine et à l'autorité de certification émettrice. (Le domaine LDAP1 contient les informations pertinentes).

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"]

Cependant, lorsque j'essaie de me connecter au service, je reçois l'exception LDAP suivante.

[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)

J'ai d'abord été informé que les certificats de l'autorité de certification racine et émettrice étaient ceux qui étaient utilisés pour signer le certificat des serveurs LDAP. Cependant, lors du dépannage à l'aide de openssl verify J'ai reçu l'exception suivante, ce qui m'a amené à penser que ce n'était peut-être pas le cas :

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

J'ai obtenu le certificat du serveur LDAP ( ldap.pem dans l'exemple ci-dessus) 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

Compte tenu de ce qui précède, mon évaluation selon laquelle le certificat du serveur LDAP n'a pas été signé par l'autorité de certification racine/émettrice est-elle correcte ? Ou est-ce que le certificat du serveur LDAP a été signé par l'autorité de certification ? s_client n'est pas la manière appropriée d'obtenir l'autorité de certification du serveur LDAP ?

EDIT : Message d'erreur complet avec retours à la ligne insérés manuellement :

[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)')'))

0voto

mongolol Points 111

En fin de compte, il y avait une troisième autorité de certification à laquelle il fallait faire confiance. Cette autorité de certification a signé le certificat VIP de leur serveur LDAP.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X