apache Erros de autenticação de certificado de cliente: Verificação de certificado: Erro (18): certificado auto-assinado

3

Portanto, tenho seguido instruções sobre como configurar a autenticação de certificado de cliente no Apache2 com mod_ssl. Isso é somente para o propósito de testar um aplicativo contra o CAA, não para qualquer tipo de uso de produção.

Até agora eu segui http://www.impetus.us/~rjmooney/projects/misc/clientcertauth.html para conselhos sobre como gerar minhas informações de criptografia de CA, servidor e cliente. Eu coloquei todos os três em /etc/ssl/ca/private . Eu configurei as seguintes diretivas adicionais no meu arquivo de site default_ssl:

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
...
    SSLEngine on
    SSLCertificateFile    /etc/ssl/ca/private/server.crt
    SSLCertificateKeyFile /etc/ssl/ca/private/server.key
    SSLVerifyClient require
    SSLVerifyDepth 2

    SSLCACertificatePath /etc/ssl/ca/private
    SSLCACertificateFile /etc/ssl/ca/private/ca.crt
    <Location />
            SSLRequireSSL
            SSLVerifyClient require
            SSLVerifyDepth 2
    </Location>
    <FilesMatch "\.(cgi|shtml|phtml|php)$">
            SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
            SSLOptions +StdEnvVars
    </Directory>
...
</VirtualHost>
</IfModule>

Eu instalei o arquivo p12 no Chrome, mas quando vou visitar o link , recebo os seguintes erros

Chrome: Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

Apache: Certificate Verification: Error (18): self signed certificate

Se eu tivesse que adivinhar, uma das minhas diretivas não é configuração certa para carregar e verificar o p12 w / meu eu criado CA. Mas eu não posso para a vida de mim descobrir o que é. Alguém teria mais experiência aqui que pudesse me apontar na direção certa?

    
por decoy 20.12.2011 / 21:57

3 respostas

4

Primeiramente, sugiro que você evite usar SSLCACertificatePath e SSLCACertificateFile ao mesmo tempo. SSLCACertificatePath é usado para apontar para um diretório contendo vários arquivos, um para cada certificado de CA em que você confia. SSLCACertificateFile é usado para apontar para um único arquivo, sendo a concatenação de todos os certificados de CA nos quais você confia. Não faz sentido apontar SSLCACertificatePath para um diretório que também possua chaves privadas (embora eu não tenha certeza se isso causaria problemas de qualquer maneira).

O que importa é que o certificado de cliente que você está usando seja emitido por um dos certificados de CA (indicado por qualquer um dos SSLCACertificatePath ou SSLCACertificateFile que você esteja usando): o DN do emissor de seu certificado de cliente deve ser o DN do assunto de um dos certificados de CA que você configurou dessa maneira no Apache Httpd (além disso, ele deve realmente ser emitido por essa CA, portanto a assinatura do seu certificado de cliente deve ser verificável pela chave pública do certificado de CA, mas supondo que você tenha criado sua CA e emitido certificados corretamente: você pode querer verificar isso, apenas no caso).

Você pode verificar o conteúdo de um certificado (CA ou não) no formulário PEM (geralmente .pem ou .crt ) usando:

openssl x509 -text -noout -in filename.pem

(Isso deve exibir informações suficientes sobre o certificado.)

EDITAR:

Apenas para o caso de haver um problema com seus certificados, você pode tentar estes certificados de teste:

link

(Todas as senhas são testtest .)

Você pode importar testclient.p12 no seu navegador. cacert.pem é o certificado de CA no formato PEM e localhost-cert.pem é um certificado de servidor para localhost (portanto, destina-se a testes da própria máquina). localhost-key.pem é a chave privada do certificado do servidor. Você pode desprotegê-lo usando:

openssl rsa -in localhost-key.pem -out localhost-key-unprotected.pem

Talvez seja necessário confiar cacert.pem temporariamente no seu navegador, mas removê-lo após os testes (porque obviamente testtest não é muito secreto, portanto qualquer pessoa pode usar essa CA).

    
por 21.12.2011 / 02:25
2

Eu tive o mesmo problema (sob o Nginx). A solução era tornar o nome comum do meu cliente diferente do nome comum do servidor. Originalmente, achei que meu certificado CN tinha que corresponder ao FQDN do certificado do servidor.

EX:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Minnesota
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCo
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:Ryan Pendergast
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Signature ok
subject=/C=US/ST=Minnesota/O=MyCo/CN=Ryan Pendergast/[email protected]
    
por 21.11.2012 / 23:43
0

Eu também tive esse problema com o nginx, semelhante a @rynop, e a solução acabou sendo a nomeação correta.

No meu caso, garantir que a organização / nomes comuns para a CA do cliente e o certificado de cliente fossem diferentes. Isso foi resolvido.

Se os nomes forem os mesmos, nginx / openssl verá um certificado autoassinado, em vez de um assinado por uma autoridade de certificação.

O guia a seguir foi útil na configuração da autenticação do certificado de cliente com o nginx e orienta o usuário a usar nomes diferentes para CA e cert:

link

    
por 02.02.2015 / 17:45