Autenticação Apache baseada em LDAP (mod_ldap + mod_authnz_ldap) usando CA própria para SSL / TLS


2

RESOLVIDO: O problema acabou sendo causado por LDAPTrustedGlobalCertdiretivas herdadas esquecidas em vários arquivos de configuração, usando certificado antigo para o mesmo FQDN

tl; dr: Usamos uma CA autoassinada e nunca tivemos que usar diretivas que desativam a verificação de certificados: como fazer o Apache confiar em nossa CA autoassinada mod_ldap?

Estou tentando configurar meu servidor Web Apache para uma autenticação HTTP usando um diretório LDAP como base de usuários.

Tudo funciona bem no modo não criptografado, mas falha com um código de erro HTTP 500 com SSL ou STARTTLS.

Aqui está minha configuração do Apache:

AuthType Basic
AuthName "WebServer"
AuthBasicProvider ldap
AuthzLDAPAuthoritative on

# Plain:
AuthLDAPURL "ldap://ldap.example.com/dc=example,dc=local?uid?sub?(objectClass=person)"

# SSL:
LDAPTrustedGlobalCert CA_BASE64 /etc/ssl/certs/ca-certificates.crt
AuthLDAPURL "ldaps://ldap.example.com:636/dc=example,dc=local?uid?sub?(objectClass=person)" SSL

# StartTLS
LDAPTrustedGlobalCert CA_BASE64 /etc/ssl/certs/ca-certificates.crt
LDAPTrustedMode TLS
AuthLDAPURL "ldap://ldap.example.com/dc=example,dc=local?uid?sub?(objectClass=person)"

AuthLDAPBindDN "cn=webserver.example.com,ou=Apps,dc=example,dc=local"
AuthLDAPBindPassword "secret"

/etc/ssl/certs/ca-certificates.crté uma concatenação de vários certificados CA (gerados pelo pacote Debian ca-certificates ). Tentei apontar LDAPTrustedGlobalCertpara o rootCA ou o subCA assinando os certificados ldap.example.com: mesmo problema.

error.log diz:

# TLS:
auth_ldap authenticate: user john-doe authentication failed; URI / [LDAP: ldap_start_tls_s() failed][Connect error]

# SSL:
auth_ldap authenticate: user john-doe authentication failed; URI / [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]

Estamos usando uma PKI com uma CA raiz auto-gerenciada (autoassinada) e várias sub-CAs que assinam certificados para servidores Web e LDAP. Adicionando o arquivo sub-CA PEM em nossos servidores e configurando o pacote Debian ca-certificates e o ldap.conf (for TLS_CACERT), o LDAP pode ser acessado com êxito por meio de criptografia simples não criptografada (porta 389), StartTLS (porta 389) e SSL ( porta 636) para Linux PAM ( pacote Debian libnss-ldapd ) e softwares de navegador LDAP.

Como posso dizer ao Apache para verificar os certificados recebidos e confiar no meu rootCA?

Editar às respostas @ shane-madden ideas

  • Funciona se estiver usando LDAPVerifyServerCert Off.
  • openssl s_client -connect ldap.example.com:636 -showcerts retorna o seguinte:

    CONNECTED(00000003)
    depth=3 CN = ExampleRootCa, O = Example, C = FR
    verify error:num=19:self signed certificate in certificate chain
    verify return:0
    ---
    Certificate chain
     0 s:/CN=ldap.example.com/O=Example/C=FR
       i:/CN=ExampleSrvCa/O=Example/C=FR
    -----BEGIN CERTIFICATE-----
    MIIGcDCCBF
    ...
    iyrFEYDcs=
    -----END CERTIFICATE-----
     1 s:/CN=ExampleSrvCa/O=Example/C=FR
       i:/CN=ExampleMainCa/O=Example/C=FR
    -----BEGIN CERTIFICATE-----
    MIIF2DCCA8
    ...
    GrskgqnaEg
    -----END CERTIFICATE-----
     2 s:/CN=ExampleMainCa/O=Example/C=FR
       i:/CN=ExampleRootCa/O=Example/C=FR
    -----BEGIN CERTIFICATE-----
    MIIF1TCCA7
    ...
    RozDAcZnph
    -----END CERTIFICATE-----
     3 s:/CN=ExampleRootCa/O=Example/C=FR
       i:/CN=ExampleRootCa/O=Example/C=FR
    -----BEGIN CERTIFICATE-----
    MIIFWzCCA0
    ...
    RY5xwHgA==
    -----END CERTIFICATE-----
    ---
    Server certificate
    subject=/CN=ldap.example.com/O=Example/C=FR
    issuer=/CN=ExampleSrvCa/O=Example/C=FR
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 6410 bytes and written 934 bytes
    ---
    New, TLSv1/SSLv3, Cipher is AES256-SHA256
    Server public key is 4096 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1.2
        Cipher    : AES256-SHA256
        Session-ID: ABC...
        Session-ID-ctx:
        Master-Key: DEF...
        Key-Arg   : None
        PSK identity: None
        PSK identity hint: None
        SRP username: None
        Start Time: 1391654253
        Timeout   : 300 (sec)
        Verify return code: 19 (self signed certificate in certificate chain)
    
  • A execução openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt CN=ldap.example.com_O=Example_C=FR.crtdiz que o certificado está OK

Encontrei algumas LDAPTrustedGlobalCertdiretivas em vários arquivos do VirtualHost ( /etc/apache2/sites-available/), mas fora dele <VirtualHost>. Teses em que aponta para um antigo certificado autoassinado para o mesmo FQDN (testes herdados). Depois de limpar toda a configuração do Apache, SSL e autenticação LDAP TLS funcionou muito bem (não há necessidade de qualquer LDAPTrustedGlobalCertlugar ...)
CDuv

Respostas:


4

Bem, primeiro vamos confirmar que a confiança do certificado é realmente o problema. Isso funciona LDAPVerifyServerCert Off?

Além disso, vamos confirmar que o serviço LDAP está falando com um certificado que funcionará; conectar a ele:

openssl s_client -connect ldap.example.com:636 -showcerts

Se estiver enviando apenas o certificado do host e não os certificados intermediários ou raiz que o assinaram, será necessário confiar explicitamente no certificado intermediário com o Apache.

Pegue o s_clientcertificado do host que foi produzido durante essa conexão e grave-o em um arquivo e verifique se a assinatura está correta:

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt received-cert.crt

Desculpe, esqueci de especificar que está funcionando se eu usar LDAPVerifyServerCert Off. openssl s_client ... -showcertsenvie todos os certificados primeiro ao servidor LDAP, depois a CA intermediária e a CA raiz. openssl verify -CAfilediz que o certificado do servidor LDAP (o primeiro recebido) está OK (postagem original editada para adicionar informações sobre teses).
CDuv 6/14
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.