OpenSSL não obtendo CAs na pasta certs

Estamos com problemas para curlnão conectar a um servidor HTTPS:

$ curl https://the-problem-site.com    (not the real URL!)   
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

1112 é SSL_R_TLSV1_UNRECOGNIZED_NAMEem ssl.h.

Se eu tentar, openssl s_client -connect the-problem-site.com:443então eu vejo

CONNECTED(00000003)   
depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
verify error:num=20:unable to get local issuer certificate   
verify return:0   

Certificate chain   
0 s:/serialNumber=xx/C=xx/ST=xx/L=xxxx/O=xx/OU=xx/CN=the-problem-site.com   
i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA   

ou seja, parece que o problema é que não confia /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA. No entanto, esse certificado está instalado: é /etc/ssl/certs/GeoTrust_Global_CA.pem, e se eu correr

openssl s_client -conecte o-problem-site.com:443 -CAfile /etc/ssl/certs/GeoTrust_Global_CA.pem

então tudo funciona. O cert também está presente como um arquivo chamado hash b0f3e76e.0e está em ca-certificates.crt. No entanto, tanto quanto posso ver, nem curl nem openssl estão tentando ler nenhum certificado; se eu straceeles, então não há nenhuma tentativa de ler /usr/lib/ssl/certsou /etc/ssl/certsde todo, nem mesmo com erros. Ele lê openssl.cnf embora. Nós corremos update-ca-certificates.

Este é o Ubuntu 10.04 com o openssl 0.9.8k. Podemos reproduzir o problema em duas instalações separadas (embora seja possível que seja um clone do outro no caminho de volta). Se eu tentar o mesmo teste em uma VM do CentOS com o openssl 0.9.8e, ele funcionará bem e posso vê-lo lendo o arquivo de certificado strace. Não há acesso equivalente a arquivos no mesmo ponto nos traços do Ubuntu. Se eu copiar o openssl.cnfarquivo da CentOS VM para as máquinas Ubuntu, não faz diferença. Não há nada óbvio no ambiente ou em um arquivo .rc que possa estar causando isso.

Alguma idéia do que estou fazendo de errado? Isso deve funcionar, isto é, o openssl e o curl selecionam as CAs instaladas automaticamente na linha de comando? Como isso está configurado? Obrigado!

Outro ponto de dados: em uma instalação limpa de 13 servidores, curlpega o arquivo de certificados e funciona bem. openssl s_clientainda não, no entanto. Por que isso seria?

Existem várias bibliotecas criptográficas no seu sistema:

• OpenSSL (o padrão ouro, com uma licença no estilo BSD (muito gratuita) que inclui uma cláusula um tanto problemática (impedindo a compatibilidade com GPL, mas nada de “ruim”) limitando sua adoção no mundo GNU)
• GnuTLS (a substituição da FSF; vem em dois tipos: licenciado LGPLv2 (mas não mantido) e licenciado LGPLv3 (e, portanto, incompatível com programas somente GPLv2); historicamente não é tão abrangente quanto o OpenSSL, um pouco mais problemático, mas mais rigoroso também, o que aumenta a segurança)
• NSS (biblioteca do Netscape / Mozilla, raramente usada fora; lenta para adotar novos padrões)
• menores como PolarSSL, MatrixSSL, NaCl / Salt

Todos eles têm, é claro, semelhanças e diferenças. O software que os utiliza (para fins criptográficos ou para usar SSL / TLS) às vezes suporta o uso de mais de uma dessas bibliotecas (por exemplo, Lynx, o navegador da web, normalmente está vinculado ao OpenSSL, mas também suporta o GnuTLS (não tão bom) em para apaziguar o povo GNU).

O cURL também é um dos projetos de suporte ao uso de uma das três principais bibliotecas de criptografia. Isso ocorre principalmente porque o cURL é, principalmente, uma biblioteca destinada a ser usada por outros programas quando eles querem baixar (ou até carregar) coisas usando conexões http, ftp, etc. A curlferramenta de linha de comando pode vir de qualquer uma dessas variantes.

Agora, tenho certeza de que o problema que você está enfrentando com o sistema não recém-instalado é o seguinte:

O OpenSSL e o GnuTLS suportam o uso de /etc/ssl/certs/<hash>.<number>diretórios CA de estilo. O OpenSSL versão 0.xe GnuTLS, no entanto, usam um algoritmo diferente para calcular o hash mencionado acima do OpenSSL versão 1.x. (Ambos podem coexistir em um sistema; se certificados diferentes tiverem o mesmo hash, basta usar um número diferente para eles. Mas, por alguma razão, o ca-certificatespacote Debian / Ubuntu parece não fazer isso.) Além disso, algumas versões do GnuTLS não suporte usando o diretório, mas apenas usando um arquivo /etc/ssl/certs/ca-certificates.crt(que geralmente também é gerenciado pelos ca-certificatesscripts de manutenção do pacote, mas pode se desviar); você parece estar usando uma versão mais antiga; portanto, essa pode ser a coisa que você acertou.

openssl s_clientpor padrão (ou seja, sem a opção -CApathou -CAfile), não procura certificados em nenhum lugar .

Seu curlpartir da instalação atualizada provavelmente usa uma biblioteca de criptografia diferente do que o curlda instalação do zero.

openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443Além de openssl s_client -CApath /etc/ssl/certs -connect the-problem-site.com:443imitar o comportamento de versões mais antigas do GnuTLS, tente .

Verifique novamente se há um OpenSSL 1.x em qualquer lugar do seu sistema (o Ubuntu é conhecido por apresentar grandes atualizações mesmo nas versões LTS) e, se sim, verifique o hash do arquivo:

openssl x509 -noout -hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash_old -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem

Normalmente, o segundo e o terceiro comando devem falhar (OpenSSL 0.x) ou o primeiro e o terceiro comando devem exibir o mesmo hash, mas o segundo deve exibir um hash diferente (OpenSSL 1.x). O GnuTLS usaria a saída do segundo comando (se o OpenSSL 1.x estiver instalado); se o OpenSSL 0.x estiver instalado, é o mesmo hash. Você pode criar esses links simbólicos manualmente.

Posso atualizar esta postagem assim que você fornecer comentários sobre a depuração.