Autenticação de usuário SSL não funciona no Apache

4

Estou enfrentando um problema com a autenticação de clientes por meio de seus certificados ssl, o que parece ser semelhante a muitos problemas que encontrei em toda a rede - infelizmente sem solução.

A configuração é: apache 2.2, mod_ssl, openssl no Debian linux. Eu tenho um cliente usando um certificado PersonalSign Globalsign para autenticar. Eu configurei o SSLCACertificatePath corretamente, pois a depuração do apache informa:

[Thu May 10 15:31:35 2012] [debug] ssl_engine_init.c(1196): CA certificate: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[Thu May 10 15:31:35 2012] [debug] ssl_engine_init.c(1196): CA certificate: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2
[Thu May 10 15:31:35 2012] [debug] ssl_engine_init.c(1196): CA certificate: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2
[Thu May 10 15:31:35 2012] [debug] ssl_engine_init.c(1196): CA certificate: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA

Eu não sei porque ambos os certificados são duas vezes nesta lista. Os hashes são vinculados corretamente por meio do utilitário c_rehash.

Agora o cliente autentica (eu copio o que eu acho que são entradas relevantes do log de depuração):

Certificate Verification: depth: 1, subject: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
Certificate Verification: Error (20): unable to get local issuer certificate
OpenSSL: Write: SSLv3 read client certificate B
OpenSSL: Exit: error in SSLv3 read client certificate B
Re-negotiation handshake failed: Not accepted by client!?

que, para meu entendimento limitado, significa que ele não está obtendo o certificado do emissor para o certificado GlobalSign 1 PersonalSign 1 CA-G2 . Na verdade, o issuer_hash deste certificado corresponde ao hash da GlobalSign Root CA que é de fato encontrado no SSLCACertificatePath corretamente vinculado a este mesmo hash e mencionado anteriormente no log conforme carregado.

Então estou preso. Alguma idéia alguém?

Editar:

Se eu verificar o certificado do usuário por meio do utilitário de linha de comando openssl, ele funcionará:

# openssl verify -CApath conf/ssl.user.crt/ test.pem  
test.pem: OK

( conf / ssl.user.crt é meu SSLCACertificatePath)

    
por tim 10.05.2012 / 15:55

1 resposta

2

Resolveu. Acontece que foi um problema de permissões:

Eu configurei uma configuração similar em uma máquina limpa do Debian Squeeze e funcionou desde o início. A diferença na saída de depuração foi:

[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 2, subject: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA 
[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 1, subject: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 0, subject: /[email protected]/[email protected], issuer: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2

no lado "bom", vs:

[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 1, subject: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[error] [client 80.252.98.156] Certificate Verification: Error (20): unable to get local issuer certificate

do lado "ruim".

A principal diferença entre as duas configurações são as permissões para o diretório / conf da instalação do apache em que residem os CA-certs. Por motivos de segurança, temos as permissões definidas para 750 e o dir de propriedade de root. Mover os arquivos CA para um dir legível (ou para ser preciso 'executável' para ser usado no caminho) fez com que o problema desaparecesse.

Portanto, parece que embora o mod_ssl afirme ler os certificados na inicialização do servidor, ele ainda precisa acessar os arquivos com hash durante a execução (e ter perdido seus privilégios de root).

    
por 22.05.2012 / 11:50