La prise de contact SSL échoue avec - un certificat de chaîne Verisign - qui contient deux certificats signés CA et un certificat auto-signé
Je suis coincé avec un problème et j'essaie de le déboguer. Nous avons acheté un certificat Verisign. Quand nous utilisons:
openssl> s_client -connect myweb.com:443 -showcerts
La prise de contact SSL ne se termine jamais et à la fin, nous voyons une erreur:
Verify return code: 19 (self signed certificate in certificate chain)
Il affiche 3 balises ---BEGIN/END CERTIFICATE---. Deux certificats en chaîne sont signés Verisign mais un est auto-signé.
Si quelqu'un peut expliquer comment ce certificat auto-signé apparaît dans un certificat signé par une autorité de certification?
Cette erreur
19 (self signed certificate in certificate chain)est-elle bénigne? Sinon, qu'est-ce qui pourrait en être la cause?Le client a le certificat CA dans le magasin approuvé, mais il n'y a rien pour le certificat auto-signé. Pensez-vous que cela pourrait poser problème? Si oui, comment dois-je:
- Comment puis-je me débarrasser du certificat auto-signé du certificat de chaîne en ne laissant que 2 certificats signés CA dans la chaîne?
- Ajouter ce certificat auto-signé sur le magasin de confiance du client?
Les certificats racine émis par les autorités de certification ne sont que des certificats auto-signés (qui peuvent à leur tour être utilisés pour émettre des certificats d'autorité de certification intermédiaires). Ils n'ont pas grand-chose de spécial à leur sujet, sauf qu'ils ont réussi à être importés par défaut dans de nombreux navigateurs ou ancres de confiance du système d'exploitation.
Bien que les navigateurs et certains outils soient configurés pour rechercher par défaut les certificats d'autorité de certification approuvés (dont certains peuvent être auto-signés), à ma connaissance, la commande openssl ne l'est pas.
En tant que tel, tout serveur qui présente la chaîne complète de certificats, depuis son certificat d'entité finale (le certificat du serveur) jusqu'au certificat d'autorité de certification racine (éventuellement avec des certificats d'autorité de certification intermédiaires) aura un certificat auto-signé dans la chaîne: l'autorité de certification racine .
openssl s_client -connect myweb.com:443 -showcerts n'a aucune raison particulière de faire confiance au certificat d'autorité de certification racine de Verisign, et parce qu'il est auto-signé, vous obtiendrez "certificat auto-signé dans la chaîne de certificats".
Si votre système possède un emplacement avec un ensemble de certificats approuvés par défaut (je pense que /etc/pki/tls/certs sur RedHat/Fedora et /etc/ssl/certs sur Ubuntu/Debian), vous pouvez configurer OpenSSL pour les utiliser comme ancres de confiance, par exemple comme ceci:
openssl s_client -connect myweb.com:443 -showcerts -CApath /etc/ssl/certs
Il semble que le certificat intermédiaire soit manquant. Depuis avril 2006, tous les certificats SSL émis par VeriSign nécessitent l'installation d'un certificat CA intermédiaire.
Il se peut que vous n'ayez pas chargé toute la chaîne de certificats sur votre serveur. Certaines entreprises n'autorisent pas leurs ordinateurs à télécharger des certificats supplémentaires, ce qui entraîne l'échec de l'exécution d'une négociation SSL.
Voici quelques informations sur les chaînes intermédiaires:
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR657
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AD146
À propos du serveur peut fournir aux clients le certificat racine ou non, extrait du document RFC-5246 "Le protocole TLS (Transport Layer Security Version 1.2)", il dit:
liste_de_certificats
Il s'agit d'une séquence (chaîne) de certificats. Le certificat de l'expéditeur DOIT venir en premier dans la liste. Chaque certificat suivant DOIT certifier directement celui qui le précède. Étant donné que la validation de certificat nécessite que les clés racine soient distribuées indépendamment, le certificat auto-signé qui spécifie l'autorité de certification racine PEUT être omis de la chaîne, sous le
hypothèse que l'extrémité distante doit déjà la posséder pour la valider dans tous les cas.
À propos du terme "MAI", extrait du RFC-2119 "Best Current Practice" dit:
5 MAI
Ce mot, ou l'adjectif "FACULTATIF", signifie qu'un élément est vraiment facultatif. Un fournisseur peut choisir d'inclure l'article car un
un marché particulier l'exige ou parce que le vendeur estime que
il améliore le produit tandis qu'un autre fournisseur peut omettre le même article.
Une implémentation qui n'inclut pas d'option particulière DOIT être
prêt à interagir avec une autre mise en œuvre qui ne
inclut l'option, mais peut-être avec des fonctionnalités réduites. Dans le même esprit, une mise en œuvre qui inclut une option particulière
DOIT être prêt à interagir avec une autre implémentation qui
n'inclut pas l'option (sauf, bien sûr, pour la fonction
L'option fournit.)
En conclusion, la racine peut se trouver sur le chemin de certification fourni par le serveur lors de la prise de contact.
Une utilisation pratique.
Pensez, non pas en termes d'utilisateur de navigateur, mais sur un outil de transfert sur un serveur dans une zone militarisée avec un accès Internet limité.
Le serveur, jouant le rôle client lors du transfert, reçoit tous les chemins d'accès aux certificats du serveur.
Tous les certificats de la chaîne doivent être vérifiés pour être fiables, racine incluse.
La seule façon de vérifier cela est que la racine soit incluse dans le chemin d'accès aux certificats dans le temps de transfert, en étant comparée à une copie locale précédemment déclarée comme "fiable" d'entre eux.
Voici un lien vers le vérificateur d'installation de certificats SSL de VeriSign: https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR11
Entrez votre URL, cliquez sur "Tester ce serveur Web" et il vous dira s'il y a des problèmes avec votre autorité de certification intermédiaire.
Lorsque vous voyez "Verify return code: 19 (self signed certificate in certificate chain)", alors, soit les serveurs essaient vraiment d'utiliser un certificat auto-signé (qu'un client ne pourra jamais vérifier), soit OpenSSL n'a pas accès à la racine nécessaire mais le serveur essaie de le fournir lui-même (ce qu'il ne devrait pas faire car il est inutile - un client ne peut jamais faire confiance à un serveur pour fournir la racine correspondant au propre certificat du serveur).
Encore une fois, l'ajout de -showcerts vous aidera à diagnostiquer lequel.