OpenSSL: incapable de vérifier le premier certificat pour l'URL d'Experian

Question

Je suis en train de vérifier une connexion SSL à Experian sur Ubuntu 10.10 avec le client OpenSSL.

openssl s_client -CApath /etc/ssl/certs/ -connect dm1.experian.com:443

Le problème est que la connexion se ferme avec un code de retour de vérification : 21 (impossible de vérifier le premier certificat).

J'ai vérifié la liste des certificats, et le certificat utilisé pour signer Experian (VeriSign Class 3 Secure Server CA - G3) est inclus dans la liste.

/etc/ssl/certs/ca-certificates.crt 

Pourtant, je ne sais pas pourquoi il n'est pas capable de vérifier le premier certificat.

La réponse complète peut être vue ici : https://gist.github.com/1248790

Answer 1

Le premier message d'erreur vous en dit plus sur le problème :

erreur de vérification : numéro=20 : impossible d'obtenir le certificat d'émetteur local

L'autorité d'émission du certificat de serveur d'entité finale est

VeriSign Class 3 Secure Server CA - G3

Regardez attentivement dans votre fichier CA - vous ne trouverez pas ce certificat car il s'agit d'une CA intermédiaire - ce que vous avez trouvé était une CA publique primaire G3 de VeriSign portant un nom similaire.

Mais pourquoi la connexion avec un autre serveur fonctionne-t-elle, mais pas celle-ci ? Le problème est une mauvaise configuration des serveurs (voyez par vous-même en utilisant l'option -debug). Le serveur "bon" envoie l'intégralité de la chaîne de certificats lors du handshake, vous fournissant ainsi les certificats intermédiaires nécessaires.

Mais le serveur qui échoue vous envoie uniquement le certificat d'entité finale, et OpenSSL n'est pas capable de télécharger dynamiquement le certificat intermédiaire manquant (ce qui serait possible en interprétant l'extension Authority Information Access). Par conséquent, votre tentative échoue en utilisant s_client mais elle réussirait néanmoins si vous accédiez à la même URL par exemple avec FireFox (qui prend en charge la fonction "découverte de certificat").

Vos options pour résoudre le problème sont soit de le corriger côté serveur en envoyant également toute la chaîne, soit de transmettre le certificat intermédiaire manquant à OpenSSL en tant que paramètre côté client.

Answer 2

Ajout d'informations supplémentaires à la réponse de emboss.

Pour simplifier, il y a un certificat incorrect dans votre chaîne de certificats.

Par exemple, votre autorité de certification vous aura probablement fourni 3 fichiers.

• your_domain_name.crt
• DigiCertCA.crt # (Ou quel que soit le nom de votre autorité de certification)
• TrustedRoot.crt

Vous avez probablement combiné tous ces fichiers en un seul bundle.

-----BEGIN CERTIFICATE----- 
(Votre certificat SSL principal : your_domain_name.crt) 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
(Votre certificat intermédiaire : DigiCertCA.crt) 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
(Votre certificat racine : TrustedRoot.crt) 
-----END CERTIFICATE-----

Si vous créez le bundle, mais utilisez une ancienne version incorrecte de votre certificat intermédiaire (DigiCertCA.crt dans mon exemple), vous obtiendrez les symptômes exacts que vous décrivez.

• Les connexions SSL semblent fonctionner à partir du navigateur
• Les connexions SSL échouent à partir d'autres clients
• Curl échoue avec l'erreur: "curl: (60) SSL certificate : unable to get local issuer certificate"
• openssl s_client -connect donne l'erreur "verify error:num=20:unable to get local issuer certificate"

Téléchargez à nouveau tous les certificats de votre autorité de certification et créez un nouveau bundle.

Answer 3

J'ai rencontré le même problème lors de l'installation de mon certificat signé sur une instance Amazon Elastic Load Balancer.

Tout semblait bien se passer via un navigateur (Chrome), mais en accédant au site via mon client java, j'ai obtenu l'exception javax.net.ssl.SSLPeerUnverifiedException

Ce que je n'avais pas fait était de fournir un fichier "chaîne de certificats" lors de l'installation de mon certificat sur mon instance ELB (voir https://serverfault.com/questions/419432/install-ssl-on-amazon-elastic-load-balancer-with-godaddy-wildcard-certificate)

Nous n'avions reçu que notre clé publique signée de l'autorité de certification, j'ai donc dû créer mon propre fichier de chaîne de certificats. En utilisant le panneau de visualisation des certificats de mon navigateur, j'ai exporté chaque certificat de la chaîne de signature. (L'ordre de la chaîne de certificats est important, voir https://forums.aws.amazon.com/message.jspa?messageID=222086)

Answer 4

Voici ce que vous pouvez faire :-

Certificats SSL Exim

Par défaut, le fichier /etc/exim.conf utilisera les fichiers cert/key :

/etc/exim.cert
/etc/exim.key

donc si vous vous demandez où définir vos fichiers, c'est là.

Ils sont contrôlés par les options de exim.conf :

tls_certificate = /etc/exim.cert
tls_privatekey = /etc/exim.key

Certificats intermédiaires

Si vous avez un certificat CA Root (fichier ca bundle, chaîne, etc.), vous ajouterez le contenu de votre CA dans le fichier exim.cert, après votre certificat réel.

Probablement une bonne idée de vous assurer d'avoir une copie de tout ailleurs au cas où vous feriez une erreur.

Dovecot et ProFtpd devraient également le lire correctement, donc dovecot n'a plus besoin de l'option ssl_ca. Donc, pour les deux cas, il n'est pas nécessaire d'apporter des modifications ni à exim.conf ni à dovecot.conf (/etc/dovecot/conf/ssl.conf)

Answer 5

Si vous utilisez MacOS, utilisez :

sudo cp /usr/local/etc/openssl/cert.pem /etc/ssl/certs

après cela, l'erreur Trust anchor not found disparaît