Comprendre la sortie de openssl s_client
Depuis que notre fournisseur de messagerie a changé son certificat SSL, un client POP3 basé sur mono refuse de se connecter à son serveur POP sécurisé pour télécharger des e-mails. D'autres clients n'ont pas de problème; par exemple. Thunderbird et Outlook; la plupart des sites SSL ne sont pas non plus capables de vérifier les ports impairs, sauf celui-ci . J'ai travaillé avec les deux fournisseurs pour tenter de cerner le problème, mais j'ai finalement atteint une impasse avec les deux, car je ne connais pas suffisamment les certificats SSL pour pouvoir guider l'un ou l'autre fournisseur à comprendre où se situe la faute.
Au cours de l'enquête, mon attention a été attirée sur la différence de sortie des deux commandes suivantes (j'ai supprimé les certificats de la sortie pour plus de lisibilité):
echo "" | openssl s_client -showcerts -connect pop.gmail.com:995
CONNECTED (00000003) Depth = 2/C = US/O = GeoTrust Inc./CN=GeoTrust Global CA Erreur de vérification : num = 20: impossible d'obtenir le certificat d'émetteur local vérifier le retour: 0 --- Chaîne de certificats 0 s :/C = US/ST = California/L = Mountain View/O = Google Inc/CN = pop.gmail.com I:/C = US/O = Google Inc/CN = Google Internet Authority G2 ----- DÉBUT DU CERTIFICAT ----- ----- FIN DU CERTIFICAT ----- 1 s:/C = US/O = Google Inc/CN = Google Internet Authority G2 I:/C = US/O = GeoTrust Inc./CN=GeoTrust Global CA ----- BEGIN CERTIFICATE ----- ----- FIN CERTIFICAT ----- 2 s:/C = US/O = GeoTrust Inc./CN=GeoTrust Global CA i:/C = US/O = Equifax/OU = Equifax Secure Certificate Authority ----- BEGIN CERTIFICATE ----- ----- FIN CERTIFICAT ----- --- Certificat serveur Sujet =/C = US/ST = Californie/L = Mountain View/O = Google Inc/CN = pop.gmail.com Émetteur =/C = US/O = Google Inc/CN = Google Int ernet Authority G2 --- Aucun nom d'autorité de certification de certificat client envoyé --- La négociation SSL a lu 3236 octets et écrit 435 octets --- Nouveau, TLSv1/SSLv3, le chiffre est RC4-SHA La clé publique du serveur est de 2048 bits Renégociation sécurisée IS pris en charge Compression: AUCUNE Expansion: AUCUNE SSL-Session: Protocole: TLSv1 Cipher: RC4-SHA ID de session: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06 session-ID-CTX: Maître-clé: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2 Key-Arg: Aucun Heure de début: 1397678434 Délai d'attente: 300 ( sec) Vérifiez le code retour: 20 (impossible d'obtenir le certificat d'émetteur local) --- + OK Gpop prêt pour les demandes du 69.3.61.10 c13mb42148040pdj TERMINÉ
echo "" | openssl s_client -showcerts -connect secure.emailsrvr.com:995
CONNECTED (00000003) Depth = 2/C = US/O = GeoTrust Inc./CN=GeoTrust Global CA Erreur de vérification : num = 19: certificat auto-signé dans la chaîne de certificats vérifier le retour: 0 --- Chaîne de certificats 0 s :/serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD/OU = 4159320284/OU = Voir www.rapidssl.com/resources/cps (c) 14/OU = Contrôle de domaine validé - RapidSSL (R) /CN=secure.emailsrvr.com i:/C = US/O = GeoTrust, Inc./CN=RapidSSL CA ----- BEGIN CERTIFICATE ----- ----- END CERTIFICATE- ---- 1 s:/C = US/O = GeoTrust, Inc./CN=RapidSSL CA I:/C = US/O = GeoTrust Inc./CN=GeoTrust Global CA ----- DÉBUT DU CERTIFICAT ----- ----- FIN DU CERTIFICAT ----- 2 s:/C = US/O = GeoTrust Inc./CN=GeoTrust Global CA i:/C = US/O = GeoTrust Inc./CN=GeoTrust Global CA ----- BEGIN CERTIFICATE ----- ----- END CERTIFICATE ----- --- Certificat de serveur subject =/serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJ qAWZ/dD/OU = 4159320284/OU = Voir www.rapidssl.com/resources/cps (c) 14/OU = Contrôle de domaine validé - RapidSSL (R) /CN=secure.emailsrvr.com émetteur =/C = US/O = GeoTrust, Inc./CN=RapidSSL CA --- Aucun nom de CA de certificat client envoyé --- Prise de contact SSL a lu 3876 octets et écrit 319 octets --- Nouveau, TLSv1/SSLv3, le chiffre est DHE-RSA-AES256-SHA La clé publique du serveur est 2048 bits Renégociation sécurisée IS pris en charge Compression: AUCUNE Expansion: AUCUNE Session SSL: Protocole: TLSv1 [. ____] Cipher. DHE-RSA-AES256-SHA [.____] session ID:. 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161 [.____] session-ID-CTX: master-Key] [.____:... 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F [.____] Key- Arg: Aucun Heure de début: 1397678467 Délai d'expiration: 300 (sec) Vérifiez le code retour: 19 (certificat auto-signé en certi ficate chain) --- TERMINÉ
J'ai essayé de comprendre si cela avait un sens, car lorsque le -CApath option est fournie, les commandes ne produisent aucune erreur:
openssl s_client -CApath /etc/ssl/certs -showcerts -connect secure.emailsrvr.com:995
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = "GeoTrust, Inc.", CN = RapidSSL CA
verify return:1
depth=0 serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD, OU = 4159320284, OU = See www.rapidssl.com/resources/cps (c)14, OU = Domain Control Validated - RapidSSL(R), CN = secure.emailsrvr.com
verify return:1
...
openssl s_client -CApath /etc/ssl/certs -showcerts -connect pop.gmail.com:995
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = pop.gmail.com
verify return:1
...
Je peux également utiliser le -CAfile avec succès après avoir téléchargé le CAfile cert directement depuis GeoTrust.
Néanmoins, Fog Creek semble penser que le problème réside dans le certificat, car ils ont essayé d'ajouter le certificat au magasin Trust de mono sans succès. Je ne serais pas d'accord avec eux, mais (comme mentionné ci-dessus), alors que la plupart des vérificateurs SSL ne vérifient pas le port 995 ou ne réussissent pas lors de la tentative, j'ai trouvé cette page qui produit l'erreur SSL 7.
Dois-je interpréter la sortie correctement pour signifier qu'il n'y a rien de mal avec le certificat?
La réponse (comme expliqué dans ce security.SE post ) est que les deux GeoTrust Global CA certificat que vous voyez dans la chaîne sont en fait pas le même certificat, l'un est dérivé de l'autre.
En raison de la signature croisée de CA!
Lorsque le certificat GeoTrust Global CA a été créé et signé pour la première fois, aucun ordinateur/navigateur/application ne l'aurait eu dans leur magasin de confiance.
En faisant un autre CA (avec une réputation et une distribution préexistantes) signer le certificat de l'autorité de certification racine GeoTrust, le certificat résultant (appelé certificat "pont") peut maintenant être vérifié par le second CA, sans que le certificat racine de GeoTrust ne soit explicitement approuvé par le client.
Lorsque Google présente la version de signature croisée du certificat d'autorité de certification racine GeoTrust, un client qui ne fait pas confiance à l'original peut simplement utiliser le certificat CA Equifax pour vérifier GeoTrust - donc Equifax agit comme une sorte d'ancre de confiance "héritée".
J'ai eu un problème similaire avec fetchmail lorsque j'ai activé la vérification ssl pour pop.gmail.com.
J'ai téléchargé le fichier pem d'Equifax mais cela n'a pas fonctionné tel quel, j'ai dû exécuter c_rehash ssl/certs qui a créé un lien symbolique avec une valeur de hachage, cela a alors juste fonctionné.
Alternativement, la valeur de hachage peut également être connue en exécutant ...
openssl x509 -in Equifax_Secure_Certificate_Authority.pem -fingerprint -subject -issuer -serial -hash -noout | sed -n /^[0-9]/p
Lors de la génération et de la configuration des certificats, il faut également mettre à jour le fichier openssl.cnf (Debian - /etc/ssl/openssl.cnf), Pour indiquer le chemin d'accès approprié, les noms de certificats, etc., puis vous pouvez exécuter la commande et les vérifier sans -CApath Option.
En conséquence, les hôtes distants pourraient également vérifier correctement vos certificats dans ce cas.
Voici la section openssl.cnf Appropriée:
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = /etc/ssl