Comprendre la sortie de openssl s_client

14

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 être en mesure de guider l'un ou l'autre fournisseur pour comprendre où réside 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

CONNECTÉ (00000003)
profondeur = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
vérifier l' erreur: 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
----- COMMENCER LE CERTIFICAT -----
----- CERTIFICAT FINAL -----
 1 s: / C = US / O = Google Inc / CN = Google Internet Authority G2
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- COMMENCER LE CERTIFICAT -----
----- CERTIFICAT FINAL -----
 2 s: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = Equifax / OU = Equifax Secure Certificate Authority
----- COMMENCER LE CERTIFICAT -----
----- CERTIFICAT FINAL -----
---
Certificat de serveur
subject = / C = US / ST = California / L = Mountain View / O = Google Inc / CN = pop.gmail.com
émetteur = / C = US / O = Google Inc / CN = Google Internet 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 chiffrement est RC4-SHA
La clé publique du serveur est de 2048 bits
La renégociation sécurisée est prise en charge
Compression: AUCUNE
Expansion: AUCUNE
Session SSL:
    Protocole: TLSv1
    Chiffrement: RC4-SHA
    ID de session: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    ID de session-ctx:
    Clé principale: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2
    Argument clé: Aucun
    Heure de début: 1397678434
    Délai d'expiration: 300 (sec)
    Vérifiez le code retour: 20 (impossible d'obtenir le certificat d'émetteur local)
---
+ OK Gpop prêt pour les demandes de 69.3.61.10 c13mb42148040pdj
TERMINÉ

echo "" | openssl s_client -showcerts -connect secure.emailsrvr.com:995

CONNECTÉ (00000003)
profondeur = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
vérifier l' erreur: 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
----- COMMENCER LE CERTIFICAT -----
----- CERTIFICAT FINAL -----
 1 s: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- COMMENCER LE CERTIFICAT -----
----- CERTIFICAT FINAL -----
 2 s: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- COMMENCER LE CERTIFICAT -----
----- CERTIFICAT FINAL -----
---
Certificat de serveur
subject = / 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
émetteur = / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
---
Aucun nom d'autorité de certification de certificat client envoyé
---
La négociation SSL a lu 3876 octets et écrit 319 octets
---
Nouveau, TLSv1 / SSLv3, le chiffrement est DHE-RSA-AES256-SHA
La clé publique du serveur est de 2048 bits
La renégociation sécurisée est prise en charge
Compression: AUCUNE
Expansion: AUCUNE
Session SSL:
    Protocole: TLSv1
    Chiffrement: DHE-RSA-AES256-SHA
    ID de session: 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161
    ID de session-ctx:
    Clé principale: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Argument clé: Aucun
    Heure de début: 1397678467
    Délai d'expiration: 300 (sec)
    Vérifiez le code retour: 19 (certificat auto-signé dans la chaîne de certificats)
---
TERMINÉ

J'ai essayé de comprendre si cela était significatif, car lorsque l' -CApathoption 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 l' -CAfileoption avec succès après avoir téléchargé le certificat CAfile 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 Trustmagasin 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?

ssl-certificate openssl jobu1324
la source
2
Je pense que l'erreur "certificat auto-signé dans la chaîne de certificats" est un hareng rouge. Une autorité de certification racine est toujours auto-signée, donc un serveur qui renvoie sa chaîne de certificats complète retournera toujours un certificat auto-signé. Plus d'infos ici .
bennettp123
2
En fait, il openssl s_clientne semble pas importer de certificats racine par défaut. Essayez ceci à la place:, openssl s_client -connect secure.emailsrvr.com:995 -showcerts -CApath /etc/ssl/certset vous constaterez probablement que l'erreur auto-signée disparaît.
bennettp123
@ bennettp123 Je note la sortie de cette commande vers le bas de la question. Ai-je raison de comprendre que la sortie des deux versions de la commande signifie que le certificat est valide?
jobu1324
oui, selon cette sortie, openssl pense que le certificat est valide. Pourquoi est-il rejeté? Je ne sais pas. C'est peut-être parce que le champ Organisation n'est pas défini, mais c'est juste une supposition.
bennettp123

Réponses:

5

La réponse (comme expliqué dans ce post security.SE ) est que les deux certificats GeoTrust Global CA que vous voyez dans la chaîne 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 son magasin de confiance.

En faisant signer un certificat de l'autorité de certification racine GeoTrust par une autre autorité de certification (avec une réputation et une distribution préexistantes), le certificat résultant (appelé certificat "pont") peut désormais être vérifié par la deuxième autorité de certification, sans que le certificat de l'autorité de certification racine GeoTrust n'ait être explicitement approuvé par le client.

Lorsque Google présente la version à signature croisée du certificat de l'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".

Mathias R. Jessen
la source
C'est pourquoi les deux chaînes de serveurs sont différentes et pourtant toutes deux valides. Mais ce n'est pas nécessairement la raison du problème de l'OP avec le client mono, sans données claires sur quelles racines sont et ne sont pas installées dans le magasin de confiance de l'instance mono particulière.
dave_thompson_085
0

J'ai eu un problème similaire avec fetchmail lorsque j'ai activé la vérification ssl 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/certsce qui a créé un lien symbolique avec une valeur de hachage, cela a ensuite 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

https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.pem

chetangb
la source
Pourriez-vous s'il vous plaît étendre quoi faire avec le fichier pem lié?
sebix
# ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10
chetangb
ce que j'ai lu quelque temps en arrière est que fetchmail utilise des bibliothèques openssl et il ne regarde que par la valeur de hachage du certificat productforums.google.com/forum/#!topic/gmail/tqjOmqxpMKY # ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10 yum whatprovides libssl.so.10 openssl-libs-1.0.1e-42.el7.i686: bibliothèque de cryptographie à usage général avec implémentation TLS Repo: base Matched à partir de: Fournit: libssl.so.10
chetangb
Veuillez étendre votre réponse et expliquer quel est le problème que vous souhaitez atteindre.
sebix
0

Lors de la génération et de la configuration des certificats, il faut également mettre à jour le openssl.cnffichier (Debian - /etc/ssl/openssl.cnf), pour indiquer le chemin approprié, les noms des certificats, etc., alors vous pouvez exécuter la commande et les vérifier sans -CApathoption.

Et en conséquence, les hôtes distants pourraient également vérifier correctement vos certificats dans ce cas.

Voici la openssl.cnfsection appropriée :

####################################################################
[ ca ]

default_ca  = CA_default        # The default ca section

####################################################################
[ CA_default ]

dir     = /etc/ssl
user155270
la source
1
C'est faux . Les default_cadonnées du (tout) fichier de configuration openssl sont utilisées uniquement pour que l'utilitaire «ca» émette et révoque éventuellement des certificats, jamais pour vérification. La façon de changer le magasin de vérification par défaut (en plus de la recompilation) est avec les variables d'environnement SSL_CERT_ {FILE, DIR}. Cependant (1) en raison d'un bogue s_clientn'utilise pas la valeur par défaut (correction prévue en avril 2015) que (2) cet OP ne voulait pas changer de toute façon.
dave_thompson_085