OpenSSL ne récupère pas les autorités de certification dans le dossier des certificats

Nous ne parvenons curlpas à nous connecter à un serveur HTTPS:

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

1112 est SSL_R_TLSV1_UNRECOGNIZED_NAMEen ssl.h.

Si j'essaie à la openssl s_client -connect the-problem-site.com:443place, je vois

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   

c'est-à-dire que le problème est qu'il ne fait pas confiance /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA. Cependant, ce certificat est installé: c'est /etc/ssl/certs/GeoTrust_Global_CA.pem, et si à la place je lance

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

alors tout fonctionne. Le certificat est également présent sous la forme d'un fichier nommé par hachage b0f3e76e.0et il est dans ca-certificates.crt. Cependant, pour autant que je puisse voir, ni curl ni openssl ne tentent de lire des certificats; si je straceles ai alors il n'y a aucune tentative de lecture /usr/lib/ssl/certsou pas /etc/ssl/certsdu tout, pas même avec des erreurs. Il lit cependant openssl.cnf. Nous avons couru update-ca-certificates.

Il s'agit d'Ubuntu 10.04 avec openssl 0.9.8k. Nous pouvons reproduire le problème sur deux installations distinctes (bien qu'il soit possible que l'un soit un clone de l'autre depuis le début). Si j'essaie le même test sur une machine virtuelle CentOS avec openssl 0.9.8e, cela fonctionne bien et je peux le voir lire le fichier de certificat dans strace. Il n'y a pas d'accès aux fichiers équivalent au même point dans les strates Ubuntu. Si je copie le openssl.cnffichier de la machine virtuelle CentOS sur les machines Ubuntu, cela ne fait aucune différence. Il n'y a rien d'évident dans l'environnement ou un fichier .rc qui pourrait être à l'origine de cela.

Des idées sur ce que je fais mal? Est-ce que cela devrait fonctionner, c'est-à-dire que openssl et curl devraient récupérer les autorités de certification installées automatiquement à partir de la ligne de commande? Comment est-ce configuré? Merci!

Autre point de données: sur une installation propre de 13 serveurs, curlrécupère le fichier de certificats et fonctionne correctement. openssl s_clientne le fait toujours pas, cependant. Pourquoi serait-ce?

Il existe plusieurs bibliothèques cryptographiques sur votre système:

• OpenSSL (l'étalon-or, avec une licence de type BSD (très gratuite) qui inclut une clause quelque peu problématique (empêchant la compatibilité GPL, mais rien de "mauvais") limitant son adoption dans le monde GNU)
• GnuTLS (le remplacement de la FSF; existe en deux versions, sous licence LGPLv2 (mais non entretenue) et sous licence LGPLv3 (et donc incompatible avec les programmes GPLv2 uniquement); historiquement pas aussi caractéristique qu'OpenSSL, un peu plus bogué, mais plus strict aussi, ce qui améliore la sécurité)
• NSS (bibliothèque Netscape / Mozilla, rarement utilisée à l'extérieur; lent à adopter de nouvelles normes)
• mineurs comme PolarSSL, MatrixSSL, NaCl / Salt

Tous ont, bien sûr, des similitudes et des différences. Les logiciels qui les utilisent (à des fins cryptographiques ou pour utiliser SSL / TLS) prennent parfois en charge l'utilisation de plusieurs de ces bibliothèques (par exemple Lynx, le navigateur Web, est normalement lié à OpenSSL mais prend également en charge GnuTLS (mais pas aussi bien) dans pour apaiser le peuple GNU).

cURL est également l'un des projets prenant en charge l'utilisation de l'une des trois principales bibliothèques de chiffrement. C'est principalement parce que cURL est, principalement, une bibliothèque destinée à être utilisée par d'autres programmes quand ils veulent télécharger (ou même télécharger) des choses en utilisant des connexions http, ftp, etc. L' curloutil de ligne de commande peut provenir de l'une de ces variantes.

Maintenant, je suis assez sûr que le problème que vous voyez avec le système non nouvellement installé est le suivant:

OpenSSL et GnuTLS prennent tous deux en charge l'utilisation /etc/ssl/certs/<hash>.<number>des répertoires d'autorité de certification -style. OpenSSL version 0.x et GnuTLS utilisent cependant un algorithme différent pour calculer le hachage susmentionné que celui utilisé par OpenSSL version 1.x. (Les deux peuvent coexister sur un système; si différents certificats ont le même hachage, vous utilisez simplement un nombre différent pour eux. Mais pour une raison quelconque, le ca-certificatespaquet Debian / Ubuntu ne semble pas le faire.) De plus, certaines versions de GnuTLS ne l'ont pas prendre en charge l'utilisation du répertoire, mais uniquement en utilisant un fichier /etc/ssl/certs/ca-certificates.crt(qui est également généralement géré par les ca-certificatesscripts de maintenance du package, mais peut dévier); vous semblez utiliser une version plus ancienne, donc c'est peut-être ce que vous avez frappé.

openssl s_clientpar défaut (c'est-à-dire sans l' option -CApathou -CAfile) ne recherche nulle part les certificats.

Votre curlinstallation mise à niveau utilise probablement une bibliothèque de chiffrement différente de celle curlde l'installation récente.

Essayez openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443en plus d' openssl s_client -CApath /etc/ssl/certs -connect the-problem-site.com:443imiter le comportement des anciennes versions de GnuTLS.

Vérifiez s'il y a un OpenSSL 1.x n'importe où sur votre système (Ubuntu est connu pour diffuser des mises à jour majeures même dans les versions LTS), et si oui, vérifiez le hachage du fichier:

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

Normalement, la deuxième et la troisième commande doivent échouer (OpenSSL 0.x) ou la première et la troisième commande doivent afficher le même hachage, mais la seconde doit afficher un hachage différent (OpenSSL 1.x). GnuTLS utiliserait la sortie de la deuxième commande (si OpenSSL 1.x est installé); si OpenSSL 0.x est installé, c'est le même hachage. Vous pouvez créer ces liens symboliques manuellement.

Je peux mettre à jour cette publication une fois que vous avez fourni des commentaires de débogage.