web-dev-qa-db-fra.com

OpenSSL ne récupère pas les CA dans le dossier certs

Nous avons des problèmes avec curl ne pas se 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_NAME dans ssl.h.

Si j'essaie plutôt openssl s_client -connect the-problem-site.com:443 alors 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 qu'il semble que le problème est qu'il ne fait pas confiance à /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA. Cependant, ce cert est installé: c’est /etc/ssl/certs/GeoTrust_Global_CA.pem et si j’exécute plutôt

openssl s_client -connecte le-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é [HOMME] b0f3e76e.0 et il se trouve dans ca-certificates.crt. Cependant, autant que je sache, ni curl ni openssl ne tentent de lire des certificats; si je strace alors aucune tentative de lecture de /usr/lib/ssl/certs ou /etc/ssl/certs, même avec des erreurs. Il lit cependant openssl.cnf. Nous avons exécuté update-ca-certificates.

C'est Ubuntu 10.04 avec openssl 0.9.8k. Nous pouvons reproduire le problème sur deux installations distinctes (même s’il est possible que l’on soit un clone de l’autre depuis le passé). Si j'essaie le même test sur un CentOS VM avec openssl 0.9.8e, alors cela fonctionne bien et je peux le voir lire le fichier de certificat dans strace. Il n’ya pas d’accès équivalent au fichier au même endroit dans les couches Ubuntu. Si je copie le fichier openssl.cnf du CentOS VM sur les machines Ubuntu, cela ne fait aucune différence. Il n'y a rien d'évident dans l'environnement ou dans un fichier .rc qui pourrait être la cause.

Des idées que je fais mal? Cela devrait-il fonctionner, c’est-à-dire si openssl et curl devaient récupérer automatiquement les autorités de certification installées à partir de la ligne de commande? Comment est-ce configuré? Merci!

Un autre point de données: sur une nouvelle installation du serveur 13, curl récupère le fichier de certificats et fonctionne correctement. openssl s_client ne le fait toujours pas. Pourquoi serait-ce?

curlopenssl
9
Rup

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

  • OpenSSL (le standard de référence, avec une licence de type BSD (très libre) qui inclut une clause quelque peu problématique (empêcher 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 uniquement GPLv2); aussi, ce qui améliore la sécurité)
  • NSS (la bibliothèque de Netscape/Mozilla, rarement utilisée à l'extérieur; tarder à adopter de nouvelles normes)
  • les plus 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)). apaiser les GNU personnes).

cURL est également l’un des projets prenant en charge l’utilisation de l’une des trois principales bibliothèques de chiffrement. Cela est principalement dû au fait que cURL est, à l’origine, une bibliothèque destinée à être utilisée par d’autres programmes qui souhaitent télécharger (ou même télécharger) des éléments à l’aide de connexions http, ftp, etc. L'outil de ligne de commande curl peut provenir de l'une ou l'autre de ces variantes.

Maintenant, je suis à peu près sûr que le problème que vous rencontrez avec le système non-fraîchement installé est le suivant:

OpenSSL et GnuTLS prennent tous deux en charge l’utilisation de répertoires d’autorité de certification de style /etc/ssl/certs/<hash>.<number>-. OpenSSL version 0.x et GnuTLS utilisent toutefois un algorithme différent pour calculer le hachage susmentionné de celui utilisé par OpenSSL version 1.x. (Les deux peuvent co-exister sur un système; si différents certificats ont le même dièse , vous utilisez simplement un nombre différent mais, pour une raison quelconque, le paquet ca-certificates de Debian/Ubuntu ne semble pas le faire.) De plus, certaines versions de GnuTLS ne prenaient pas en charge l’utilisation du répertoire, mais uniquement file /etc/ssl/certs/ca-certificates.crt (généralement géré par les scripts de maintenance du package ca-certificates, mais peut différer); vous semblez utiliser une version plus ancienne, alors c'est peut-être ce que vous avez frappé.

openssl s_client par défaut (c'est-à-dire sans l'option -CApath ou -CAfile) ne recherche pas nulle part les certificats.

Votre curl de l'installation mise à niveau utilise probablement une bibliothèque de chiffrement différente de celle de curl de la nouvelle installation.

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

Vérifiez deux fois s'il y a un OpenSSL 1.x n'importe où sur votre système (Ubuntu est connu pour avoir inséré des mises à jour majeures même dans les versions LTS), et si oui, vérifiez le hash 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, les deuxième et troisième commandes doivent échouer (OpenSSL 0.x) ou les première et troisième commandes doivent afficher le même hachage, mais la deuxième doit afficher un hachage différent (OpenSSL 1.x). GnuTLS utiliserait le résultat 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 de tels liens symboliques manuellement.

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

4
mirabilos