4 votes

Comment déboguer les chaînes de certificats avec OpenSSL ?

Je suis complètement novice en matière d'OpenSSL et je suis en train de lire un tutoriel sur la programmation d'OpenSSL pour me connecter à un serveur :

www.rtfm.com/openssl-examples/part1.pdf
www.rtfm.com/openssl-examples/part2.pdf

La mise en place des bons certificats s'avère plus délicate que prévu... :(

Lorsque je teste le message avec openssl s_client :

openssl s_client -connect 123.456.789.0:666 -CAfile test.crt -debug

J'obtiens le message d'erreur suivant

profondeur=2 C = GB, ST = Limited, CN = COMODO RSA Certification Authority verify error:num=20:Impossible d'obtenir le certificat de l'émetteur local verify return:0

et ensuite :

error:14094412:Routines SSL:SSL3_READ_BYTES:sslv3 alerte mauvais certificat:s3_pkt.c:1257:alerte SSL numéro 42 140685406562208:error:140790E5:SSL routines:SSL23_WRIT ssl handshake:s23_lib.c:177 :

Voici la chaîne de certificats :

 Certificate chain  
 0 
   s:myself    
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA  
 1 
   s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA    
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority  
 2 
   s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority    
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

Cela fait des heures que j'essaie de faire en sorte que le système reconnaisse ces certificats comme étant corrects, mais en vain...

Ce que j'ai essayé jusqu'à présent :

  • diverses variantes de l'ajout du certificat de COMODO à la liste des certificats de confiance en utilisant update-ca-trust.
  • ajouter les certificats à la liste des certificats de confiance dans /etc/ssl/certs
  • créer des fichiers pem dans un dossier et les ajouter avec -CApath.
  • Le problème avec Google, c'est que la plupart des tutoriels abordent ce sujet du point de vue d'un administrateur de serveur, mais je n'ai pas accès au serveur.

Le système d'exploitation est Fedora.

Existe-t-il une méthode structurée pour aborder cette question ?


Modifier : le certificat a été créé comme suit :

 openssl req -new -x509 -sha256 -days 365 -key mykey.key -out test.crt

6voto

Falcon Momot Points 24815

Veillez à inclure tous les certificats intermédiaires et vérifiez qu'ils sont à jour. Dans le cas où test.crt est en fait un fichier contenant uniquement /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root c'est la bonne approche. Vous pouvez également inclure la racine, et la plupart des clients accepteront de telles chaînes, mais quelques-uns s'étoufferont.

En général, la meilleure pratique consiste à inclure tous les certificats, du vôtre jusqu'au dernier avant la racine, au cas où un client ne disposerait pas du dernier certificat intermédiaire.

Il est également possible que test.crt contient d'autres éléments que la chaîne correcte. OpenSSL n'effectue pas de validation partielle de la chaîne par défaut (dans les anciennes versions, il ne le fait pas du tout). Lorsqu'il fonctionne dans ce mode, il ne se soucie pas de ce qui se trouve dans /etc/ssl/certs.

Il se peut également que vous présentiez un certificat d'intermédiaire expiré. Les autorités de certification recertifient souvent leurs intermédiaires avec la même clé ; si c'est le cas, il suffit de télécharger le certificat intermédiaire de l'autorité de certification mis à jour et de remplacer celui qui a expiré dans votre chaîne.

Enfin, avec openssl s_client, vous devez spécifier ce qu'il valide. Par exemple, utilisez l'option -CApath /etc/ssl/certs o -CAfile your_ca.crt . Pour la première option, utilisez la liste de confiance de votre système, et pour la seconde, spécifiez le certificat de l'autorité de certification racine.

2voto

MarkHelms Points 161

Vérifier les fichiers cert les uns par rapport aux autres.

Par défaut, nous disposons de 3 fichiers (basés sur une autorité de certification ordinaire ou auto-signée) :

  • clé (privée)
  • certificat (public)
  • fichier (public) de l'autorité de certification (chaîne) <- y compris tous les intermédiaires

Alors, est-ce que la clé correspond au cert, et le cert à l'AC ? Annotation : Bien que les noms soient *.crt ou *.key, le format est PEM.

# (openssl x509 -noout -modulus \
  -in /path/to/server.crt | \
  openssl md5 ; openssl rsa  -noout -modulus \
  -in /path/to/server.key | openssl md5) | uniq

Le résultat attendu est exactement 1 ligne, par exemple

(stdin)= a634dfd21796c72dcf8c809d3bacc966

Si vous voyez deux lignes, c'est que la clé et le certificat ne correspondent pas.

Si c'est le cas, poursuivre avec

# openssl verify -CAfile /path/to/ca.crt /path/to/server.crt

Vous voulez voir

server.crt: OK

Si l'une des deux étapes échoue, il est conseillé de recréer les certificats/clés. Si les deux sont corrects, vous savez que vous devez chercher à un autre endroit pour lever les obstacles (permissions, changement de CA, est-ce qu'un côté fonctionne avec openssl et l'autre avec GNUTls, ...).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X