Vérification de la chaîne de certificats SSL

Question

Après avoir lu de nombreux articles et regardé de nombreux tutoriels, j'ai décidé d'être précis car il y a des choses à propos de Vérification de la chaîne de certificat SSL et Vérification du certificat SSL en général que je ne pouvais pas ne vérifie pas tous les tutoriels que j'ai lus ni ceux que j'ai regardés.

CAS 1:

Permettez-moi de prendre un cas où je possède un certificat de Verisign, après le processus de vérification, ils m'ont donné une paire de clés publique/privée.

Mon serveur envoie la clé publique (mon certificat) au navigateur, le navigateur possède une copie de Verisign clé publique.

Les questions suivantes peuvent sembler stupides, mais il n'y a pas de cohérence entre les didacticiels et chaque fois que j'essaie de comprendre, je me retrouve dans un autre coin.

Comment le navigateur avec Verisign clé publique va identifier que ma clé publique est en effet une clé Verisign valide qui peut être utilisé pour crypter les messages que ma Verisign clé privée peut décrypter ?, je suppose que c'est la Verisign clé publique signature numérique = qui est testé par rapport au serveur signature numérique à clé publique ?, je me trompe peut-être, mais même si j'ai raison, je serai heureux pour un peu de clarification.
Dans le cas où c'est bien la signature numérique qui est testée, je suppose qu'il existe une relation entre toutes les Verisign clés publiques?, Ou peut-être qu'il n'y a qu'une relation entre chacune clé publique Verisign attribuer à un client spécifique (site Web/appareil/etc) et à la clé publique le navigateur/système d'exploitation inclus.

CAS 2:

Certificats intermédiaires.

Je comprends que leur besoin est sécurité , donc la clé privée de l'autorité de certification racine peut rester hors ligne, s'il y a plus de raisons que j'aimerais entendre parler d'eux.
À propos de la vérification de la chaîne, je suppose que la clé publique du serveur signature numérique est testée par rapport au serveur signature numérique du certificat intermédiaire, si elle est maintenant valide, c'est au tour de la signature numérique du certificat intermédiaire à tester par rapport à la signature numérique préinstallée du navigateur/système d'exploitation, et si cela est également valide, le client a valider avec succès le certificat intermédiaire et la clé publique du serveur.

Je sais que j'ai probablement tout raté, si quelqu'un peut m'aider, je vous en serai très reconnaissant.

dave_thompson_085 · Accepted Answer

Ce n'est pas du tout clair pour moi ce que vous ne comprenez pas, alors je vais le prendre très lentement.

Commençons par la terminologie. Il est important de bien comprendre, sinon vous ne pouvez pas savoir correctement ce que vous entendez et dites.

Paire de clés: une clé privée et une clé correspondante clé publique qui sont mathématiquement liées et utilisées pour la cryptographie à clé publique (PKC) également appelée cryptographie asymétrique . Pour RSA, qui est généralement le seul PKC que quelqu'un connaisse quand il ne le spécifie pas, la clé publique se compose d'un module N qui est le produit de deux grands nombres premiers, et d'un exposant public E qui peut être et généralement petit (en fait il est généralement de 3 ou 65537); la clé privée contient au moins N et un exposant privé D tel que E x D = 1 mod phi (N); en pratique, la clé privée contient souvent des valeurs supplémentaires qui permettent un calcul plus rapide, mais il y a pas mal d'autres questions à ce sujet, donc je ne les répéterai pas.

Signature numérique: une valeur calculée, pour un bloc de données spécifié (presque toujours un hachage des données "réelles") à l'aide d'une clé privée, telle que la clé publique correspondante peut être utilisée pour déterminer si la signature donnée est correcte pour les données données et n'a pu être générée que par la clé privée donnée. Cela permet au vérificateur de déterminer que les données n'ont pas été modifiées ou falsifiées, et que les données ont été envoyées ou au moins vues par le détenteur de la clé privée, mais cela ne dit rien sur qui est ce détenteur.

(X.509 aka PKIX) (Identity) Certificate: une structure de données comprenant une clé publique pour une entité et l'identité de cette entité; ainsi que d'autres informations relatives à l'entité et/ou à l'AC; tous signés par une entité (généralement) différente appelée autorité de certification ou [~ # ~] ca [~ # ~] . J'espère que vous ne pensiez à Verisign qu'à titre d'exemple; c'est une AC mais pas la seule; vous pouvez obtenir un certificat Internet tout aussi bon auprès d'autres comme GoDaddy, Comodo, ~~StartCom~~ LetsEncrypt, etc. Si vous faites confiance à une autorité de certification donnée pour émettre des certificats correctement, vous pouvez faire confiance au nombre beaucoup plus important de clés publiques et d'identités dans les certificats qu'elle émet. Mise à jour 2017: StartCom n'est plus bon, car il a été acheté par WoSign qui a ensuite été surpris en train de violer les règles CABforum et maintenant est largement méfiant . OTOH LetsEncrypt est désormais largement reconnu et gratuit. Ce qui souligne encore plus l'importance d'avoir plusieurs CA!

Certificat d'utilisateur (entité finale): un certificat contenant la clé et l'identité de toute autre chose qu'une autorité de certification, comme un serveur SSL, un client SSL, un système de messagerie, etc.

(CA) Certificat racine: un certificat contenant la clé publique d'une autorité de certification racine. Puisqu'il n'y a pas de CA "au-dessus" de la racine, une signature factice utilisant la propre clé privée de la CA est utilisée, mais qui n'a aucune valeur de sécurité. Vous devez décider (ou déléguer) s'il faut faire confiance à cette clé "hors bande", c'est-à-dire pour des raisons autres que les calculs cryptographiques.

Chaîne ou certificat intermédiaire (et CA): (comme votre question l'indique) la plupart des CA fonctionnent maintenant de manière hiérarchique, où la clé racine n'est pas utilisée pour émettre directement des certificats d'utilisateur. Au lieu de cela, l'autorité de certification racine et sa clé racine (privée) sont utilisées pour signer des certificats pour plusieurs autorités de certification intermédiaires ou subordonnées, chacune ayant sa propre paire de clés. Chaque autorité de certification intermédiaire peut alors émettre des certificats d'utilisateur, ou parfois un deuxième niveau de certificats intermédiaires; cela peut être étendu à plusieurs niveaux, mais c'est très rarement nécessaire.

Puisque vous mentionnez un navigateur, vous êtes apparemment concerné (seulement?) Par les certificats (et les clés) pour HTTPS (HTTP sur SSL/TLS). Il s'agit d'une utilisation courante et importante des certificats et PKC, mais pas la seule utilisation.

Maintenant, cas 1. Puisque ce cas ne considère pas la chaîne/intermédiaire, et que Verisign l'utilise, je vais utiliser une hypothétique SimpleCA à la place. Tout d'abord, non CA n'a jamais ou vous envoie votre clé privée. Vous générez votre paire de clés et envoyez votre clé publique à l'autorité de certification une structure de données appelée ( demande de signature de certificat ou [~ # ~] csr [~ # ~] . Le CSR devrait également contenir votre nom; pour un serveur SSL, il s'agit normalement du nom de domaine (FQDN) du serveur. Le CSR contient d'autres données que vous pouvez ignorer pour l'instant. L'AC vérifie votre identité revendiquée (pour le serveur SSL, que vous "contrôlez" le nom de domaine spécifié), perçoit généralement des frais, puis crée un certificat qui contient:

votre nom (ici le nom de domaine complet du serveur SSL) comme Subject et/ou un ou plusieurs nom (s) SubjectAlternativeNames surtout ces dernières années
votre clé publique sous la forme SubjectPublicKey , et généralement un hachage de celle-ci sous la forme SubjectKeyID
a ValidityPeriod spécifiant la durée de validité du certificat, choisi par l'AC en fonction en partie du montant que vous payez
le [~ # ~] ca [~ # ~] nom de émetteur , et généralement un AuthorityKeyID qui identifie également l'autorité de certification
d'autres données que vous pouvez ignorer pour l'instant

et toute cette structure est signée à l'aide de la clé privée de l'autorité de certification (ce qui signifie qu'elle peut être vérifiée à l'aide de la clé publique de l'autorité de certification). L'AC vous renvoie ce certificat pour l'utiliser dans votre serveur avec la clé privée que vous avez déjà.

Auparavant, en supposant que SimpleCA montrait qu'il était possible de faire confiance pour vérifier correctement les candidats et payé des frais, les fournisseurs de navigateur (Microsoft, Mozilla, Google, Apple, etc. ) a accepté d'inclure sa clé publique dans son navigateur, normalement sous la forme du certificat racine de SimpleCA. Maintenant, lorsqu'un navigateur se connecte à votre serveur et que vous envoyez votre certificat qui dit en effet "Aviel-server approuvé par SimpleCA", le navigateur trouve le certificat racine de SimpleCA et donc la clé publique de SimpleCA et l'utilise pour vérifier que votre cert est signé correctement, et que le nom du serveur dans votre certificat correspond au serveur dans l'URL que l'utilisateur souhaite; si les deux réussissent, il accepte la clé publique dans votre certificat comme clé publique correcte pour vous et l'utilise pour terminer la négociation SSL/TLS. Sinon, il affiche une sorte d'avertissement ou d'erreur.

Sauf si , c'est-à-dire que votre certificat a été révoqué . Si votre clé privée est compromise ou si l'autorité de certification détermine que vous ne contrôlez plus l'identité revendiquée (y compris si elle découvre que vous ne l'avez jamais fait mais l'a trompée sur l'application), l'autorité de certification publie que votre certificat est révoqué et que, par conséquent, les navigateurs ne le font pas. faites-lui confiance même si la signature vérifie toujours (car le calcul RSA est un processus mathématique fixe indépendant du temps ou de l'environnement). Mais la révocation, et si et quand et comment cela fonctionne, est un sujet compliqué en soi, et cette réponse est déjà suffisamment large. (modifier) Comment fonctionne l'agrafage OCSP? couvre la révocation (en fait à la fois OCSP et CRL) avec une minutie ursine. Si votre certificat est expiré (après la fin de sa période de validité), il est également invalide; celui-ci est facile à vérifier pour le navigateur. Formellement, un certificat peut également être invalide avant le début de sa période de validité, mais dans la pratique, les autorités de certification n'émettent pas de certificats "postdatés" à moins que quelqu'un ne perturbe le fuseau horaire ou quelque chose.

Cependant, l'ensemble des certificats racine CA fournis dans un navigateur n'est généralement que la valeur par défaut; l'utilisateur du navigateur peut décider d'ajouter de nouvelles racines ou de supprimer celles existantes s'il le souhaite. Et si tel est le cas, cela peut rendre votre serveur fiable alors qu'il ne l'était pas avant, ou non fiable lorsqu'il l'était auparavant.

Cas 2 (chaîne). Une raison pour les autorités de certification intermédiaires et donc les certificats intermédiaires ou en chaîne est de garder la clé racine hors ligne comme vous le dites. Une autre raison est de permettre aux autorités de certification intermédiaires d'être gérées un peu comme les utilisateurs: elles peuvent avoir des périodes de validité limitées et être renouvelées, et si elles sont compromises (ou tout simplement plus souhaitées), elles peuvent être révoquées, et cela se produit automatiquement et presque de manière invisible. D'un autre côté, si vous devez étendre, remplacer ou révoquer une racine, pratiquement tous les navigateurs du monde doivent être mis à jour. Cela représente beaucoup de travail et n'est jamais complètement fait car les utilisateurs refusent ou oublient d'installer une mise à jour et se retrouvent à faire confiance à une autorité de certification qui n'est pas sécurisée et donc probablement à des serveurs qui ne sont pas légitimes. Également pour les révocations qui sont publiées de manière plus ancienne à l'aide d'une liste de révocation de certificats (CRL) divisant les certificats émis sur plusieurs autorités de certification intermédiaires facilite la gestion des CRL.

Avec un seul certificat intermédiaire/chaîne, le processus est modifié comme suit. Disons que VerisignServerB est émis sous VerisignRoot et est utilisé à son tour pour émettre Serveur Aviel . (Les noms réels sont plus longs, mais c'est plus facile à voir.) Ensuite, votre serveur est configuré pour envoyer à la fois Aviel-server et VerisignServerB au navigateur. Le navigateur vérifie que le certificat VerisignServerB est correctement signé sous la clé publique VerisignRoot (comme précédemment, normalement stocké en tant que certificat racine auto-signé), ET que le serveur Aviel cert est signé correctement sous VerisignServerB clé publique de ce certificat, et que le nom du certificat Aviel-server correspond à celui souhaité. Peu importe l'ordre dans lequel les signatures sont vérifiées tant que les deux le sont.

Cadre de certificat SSL 101: Comment le navigateur vérifie-t-il réellement la validité d'un certificat de serveur donné? a un bel exemple graphique de cela qui peut vous aider.

Pour plusieurs certificats intermédiaires/chaîne, lorsqu'ils sont utilisés, l'extension doit maintenant être évidente.

ychaouche · Answer

Comment le navigateur avec la clé publique Verisign va-t-il identifier que ma clé publique est en effet une clé Verisign valide qui peut être utilisée pour crypter les messages que ma clé privée Verisign peut décrypter?

Il suffit de vérifier la signature de Verisign. La signature de Verisign sur votre certificat est la preuve que le certificat provient vraiment de Verisign et n'a pas été fabriqué sur votre ordinateur par exemple. La signature est simplement un message signé avec leur clé privée. Étant donné que ce que la clé privée crypte uniquement les décryptages de clé publique associés (cela fonctionne dans les deux sens), le navigateur peut décrypter cette signature avec leur clé publique (car elle est publique, tout le monde peut en obtenir une copie et elle est incluse dans votre certificat. , donc le navigateur l'obtient à partir de là). S'il peut décrypter ce message, cela signifie qu'il a été crypté avec leur clé privée, ce qui signifie à son tour qu'il provient d'eux.

Maintenant, à quoi le navigateur doit-il faire correspondre ce message déchiffré? Les signatures sont simplement un hachage de l'ensemble du certificat. Donc, ce qu'il doit faire est de calculer le hachage lui-même (par exemple, il obtient 123XYZ) et le compare à la signature déchiffrée. S'il obtient également 123XYZ, cela signifie deux choses:

ce verisign est vraiment l'auteur de ce certificat (sinon le message déchiffré ne correspondrait pas au hachage calculé)
que le certificat n'a pas été modifié (sinon les hachages seraient différents)

Je suppose que c'est la signature numérique de la clé publique Verisign qui est testée par rapport à la signature numérique de la clé publique du serveur ?,

Non, il est testé par rapport au hachage du certificat. Voir précédent.

Dans le cas où c'est bien la signature numérique qui est testée, je suppose qu'il existe une relation entre toutes les clés publiques de Verisign?

Verisign possède une clé publique unique et une clé privée. La question n'a pas de sens.

Ou peut-être qu'il n'y a qu'une relation entre chaque clé publique que Verisign attribue à un client spécifique (site Web/appareil/etc.) et la clé publique que le navigateur/système d'exploitation inclut.

Juste pour être plus précis: ils peuvent créer des clés publiques pour vous mais vous pouvez également leur remettre votre clé publique si vous en avez déjà une et ils la signeront .

Il existe une relation entre le certificat qu'ils signent pour vous et le certificat qui se trouve dans le navigateur: le certificat qui se trouve dans le navigateur est le certificat racine, celui auquel les navigateurs font confiance par défaut. Le certificat que verisign a remis au client n'est pas approuvé par défaut sur tous les navigateurs, donc un navigateur doit vérifier qui a émis ce certificat. Si l'émetteur est digne de confiance, le navigateur fait confiance à votre certificat et continue de vous donner accès au site Web que vous avez demandé. Sinon, il vérifiera l'émetteur de l'émetteur, le cas échéant, et verra s'il est de confiance. Il continuera à rechercher les ancêtres de l'émetteur jusqu'à ce qu'il atteigne une autorité de certification racine de confiance, ou à ne pas faire confiance au certificat s'il n'en trouve pas.

Donc, dans votre cas, il verra que Verisign est l'émetteur (avec un certificat intermédiaire) et l'émetteur de Verisign est Verisign lui-même (mais avec un autre ceriticate appelé certificat racine), et puisque le certificat racine de Verisign est installé sur chaque navigateur, il en est ainsi fiable, ce qui à son tour conduit à faire confiance à votre certificat.

Je comprends que leur besoin est la sécurité, donc la clé privée de l'autorité de certification racine peut rester hors ligne, s'il y a plus de raisons pour lesquelles j'aimerais en entendre parler.

La sécurité est une bonne raison, oui.

À propos de la vérification de la chaîne, je suppose que la signature numérique de la clé publique du serveur est testée par rapport à la signature numérique du certificat intermédiaire du serveur, si elle est valide maintenant, c'est au tour de la signature numérique du certificat intermédiaire d'être testée par rapport au navigateur/système d'exploitation public préinstallé. la signature numérique de la clé, et si cela est également valide, le client a réussi à valider à la fois le certificat intermédiaire et la clé publique du serveur.

Voir précédent

Pendant que j'apprenais comment SSL fonctionne, j'ai fait ce diagramme . Cela pourrait être utile.