Configurando a autenticação de certificado de cliente no apache

Question

Estou tentando configurar parte de um Virtualhost no apache para exigir autenticação de cliente. O VirtualHost em questão também atua como um proxy reverso para o servidor da Web real. Aqui está o que eu fiz:

• Criado ca.crt , ca.csr e ca.key no servidor que estou usando como CA.
• Modificada a configuração do VirtualHost para ficar assim:

...

ProxyPass / http://xxx.xxx.xxx.xxx:80/
ProxyPassReverse / http://xxx.xxx.xxx.xxx:80/
ProxyPassReverseCookiePath / /

SSLEngine On
SSLCertificateFile "/private/etc/apache2/server.crt"
SSLCertificateKeyFile "/private/etc/apache2/server.key"
SSLCertificateChainFile "/private/etc/apache2/ca_bundle.crt"
SSLCACertificateFile "/private/etc/apache2/self_ca.crt"
SSLVerifyClient none
SSLOptions StrictRequire   
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Location /clientauth>
    # These options force the client to authenticate with a client certificate.
    SSLVerifyClient require
    SSLVerifyDepth 1
</Location>

• Criei um certificado de cliente de teste usando minha CA personalizada.
• Instalou o certificado de cliente no keychain de login no Mac OS X Lion e manualmente no Firefox.

Mas não consigo navegar para o caminho /clientauth .

• O Firefox diz "O peer SSL não conseguiu negociar um conjunto aceitável de parâmetros de segurança".
• O Opera diz "Conexão segura: erro fatal (40) do servidor".
• Chrome e Safari dizem "HTTP 403 proibido".
• cURL (usando o arquivo .p12) por algum motivo não pode encontrar a chave ...
• cURL (usando os arquivos .crt e .key) faz o handshake, envia a solicitação e, em seguida, diz "Resposta vazia do servidor".
• Os logs de erro do apache continuam repetindo a linha Re-negotiation handshake failed: Not accepted by client!?

Este é um conflito entre usar a autenticação do cliente e ser um proxy reverso? Ou fiz outra coisa errada?

    

Answer 1

O problema subjacente aqui é a recusa da renegociação. Isso decorre da atividade durante o último ano ou dois para corrigir uma vulnerabilidade TLS e várias correções temporárias se recusaram a renegociar até que uma nova extensão TLS fosse implementada. Então, uma coisa que você precisa fazer é garantir o seu SSL (OpenSSL) e possivelmente, portanto, o seu Apache HTTPD também é / são o mais atualizado possível.

    

Answer 2

O cliente HTTP envia somente a solicitação HTTP depois que a sessão SSL é negociada, o que significa que o servidor só conhece a URL solicitada pelo cliente depois que o SSL for configurado. Como você está alterando o valor de SSLVerifyClient com base na URL, o Apache não pode solicitar o certificado de cliente quando a sessão SSL é negociada pela primeira vez e, em vez disso, precisa forçar uma renegociação da sessão assim que conhecer a URL. Parece que o problema está na renegociação, então sugiro testá-lo sem isso, definindo SSLVerifyClient require no bloco VirtualHost e removendo-o do bloco Location .