Por que openssl s_client verifica um certificado em um arquivo CA incorreto?

Question

Estou tentando gerar um erro de verificação de certificado com openssl s_client , assim:

$ openssl s_client -crlf -verify 9 \
  -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem \
  -starttls smtp -host mx-ha03.web.de -port 25

O certificado do servidor web.de é certificado pela Deutsche Telekom CA, e não pelo TURKTRUST, portanto, o comando acima deve falhar, certo?

Mas informa:

    Verify return code: 0 (ok)

Por quê?

Quero dizer, um comando analógico gnutls-cli falha como esperado:

$ { echo -e 'ehlo example.org\nstarttls' ; sleep 1 } | \
   gnutls-cli --starttls --crlf \
   --x509cafile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem \
   --port 25 mx-ha03.web.de
[..]
*** Verifying server certificate failed...

Fazendo uma verificação cruzada, ou seja, usando em vez de --x509cafile /etc/ssl/certs/ca-certificates.crt com gnutls-cli, obtenho:

[..]
- The hostname in the certificate matches 'mx-ha03.web.de'.
- Peer's certificate is trusted

(que também é esperado)

Openssl s_client é impresso para certificados de ca.crt:

    Verify return code: 0 (ok)

O mesmo resultado que para o TURKTRUST ...

Primeiro, suspeitei do openssl usando uma configuração padrão para -CApath (ou seja, / etc / ssl / certs) - mas quando eu strace o processo eu acabei de ver apenas o open syscall para o argumento CAfile .

(todos os testes feitos em um servidor Ubuntu 10.04)

Atualização: copiei o certificado TURKTRUST para um sistema Fedora 20 e executei a primeira instrução openssl - lá obtive um resultado diferente:

Verify return code: 19 (self signed certificate in certificate chain)

    

Answer 1

Acontece que o openssl s_client no Ubuntu 10.04 ainda consulta um local padrão para certificados instalados pelo sistema, mesmo se -CApath e -CAfile forem especificados:

8466  open("/usr/lib/ssl/certs/4e18c148.0", O_RDONLY) = 4

(saída strace)

Onde:

$ ls -l /usr/lib/ssl/certs/4e18c148.0
lrwxrwxrwx 1 root root 30 2014-04-11 21:50 /usr/lib/ssl/certs/4e18c148.0 ->
    Deutsche_Telekom_Root_CA_2.pem

O diretório /usr/lib/ssl/certs é um link simbólico para /etc/ssl/certs no Ubuntu 10.04, portanto, a linha open do registro de strace não é selecionada quando o grepping for '/ etc / ssl' ...

Fonte

Olhando para o openssl-0.9.8k, a origem deste problema está localizada em crypto/x509/by_dir.c , dir_ctrl() :

dir=(char *)Getenv(X509_get_default_cert_dir_env());
if (dir)
    ret=add_cert_dir(ld,dir,X509_FILETYPE_PEM);
else
    ret=add_cert_dir(ld,X509_get_default_cert_dir(),
                     X509_FILETYPE_PEM);

Em que X509_get_default_cert_dir retorna /usr/lib/ssl/certs e X509_get_default_cert_dir_env retorna SSL_CERT_DIR .

Solução alternativa

Assim, pode-se usar a seguinte solução no Ubuntu 10.04 / openssl 0.9.8k para obter o comportamento esperado:

$ SSL_CERT_DIR="" openssl s_client -crlf -verify 9 \
    -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.crt \
    -starttls smtp -host mx-ha03.web.de -port 25

E com a verificação falha:

Verify return code: 19 (self signed certificate in certificate chain)

Situação atual

Felizmente, com o openssl 1.0.1e (por exemplo, no Fedora 20), essa solução alternativa não é necessária, porque o problema é fixo. Isso significa que, ao especificar uma opção como -CAfile ou -CApath , nenhum diretório do sistema de certificado padrão será adicionado à lista de pesquisa de diretório.