Comment un client sait-il qu'un certificat SSL a été signé par une autorité de certification si le client n'a pas la clé publique de l'autorité de certification?
J'apprends toujours comment SSL/TSL fonctionne, donc excuses si cette question est très basique.
Je comprends que le serveur offre au client son certificat SSL, qui contient la signature d'une autorité de certification. Je comprends également que le client aura généralement une liste des autorités de certification auxquelles il fait confiance. Mais que faire si le certificat SSL est signé par une autorité de certification dont le client n'a pas connaissance? Comment le client validera-t-il alors le certificat?
Lorsque le client vérifie un certificat, il y a trois possibilités:
- Le certificat est signé par une autorité de certification à laquelle le client fait déjà confiance (et dont il connaît la clé publique). Dans ce cas, le client considère le certificat comme valide.
- Le certificat est signé par une autorité de certification dont le client n'a aucune connaissance. Dans ce cas, le client traite le certificat comme non valide (et le navigateur affichera probablement un message d'avertissement au lieu de charger la page).
- Le certificat est signé par une autorité de certification que le client ne connaît pas, mais qui possède un certificat signé par une autorité de certification que le client connaît connaît. (Dans ce cas, le serveur doit généralement envoyer à la fois son propre certificat et le certificat de l'autorité de certification - appelée "autorité de certification intermédiaire" - qui a signé son certificat). Étant donné que le certificat de l'autorité de certification intermédiaire est signé par une autorité de certification à laquelle le client fait déjà confiance, il sait qu'il peut y faire confiance, et puisque le certificat du serveur est signé par l'autorité de certification intermédiaire, le client sait qu'il peut également y faire confiance.
Notez que les certificats d'autorité de certification sont "spéciaux" - simplement parce que vous avez un certificat signé par une autorité de certification de confiance, cela ne signifie pas que vous pouvez ensuite signer d'autres certificats et que les clients leur font confiance - sauf si votre certificat est marqué comme étant valide pour la signature d'autres certificats .
Ce n'est pas le cas. Il sera traité comme s'il s'agissait d'un certificat non valide.
Par exemple, n'importe qui peut auto-signer un certificat, agissant essentiellement comme une autorité de certification pour vous-même - mais ceux-ci ne sont pas approuvés par les navigateurs, de sorte que les utilisateurs reçoivent des avertissements à cet effet.
Il y a déjà quelques bonnes réponses à celle-ci, mais je pense que je devrais ajouter, juste pour être complet, que la chaîne complète n'a pas toujours besoin d'être présentée au client.
Pour notre exemple de fonctionnement, voici une chaîne de certificats avec QUATRE (!) Certificats, y compris la racine et l'entité finale (notez que je ne recommande pas une telle conception):
Comme note, vous pouvez obtenir cette page de propriétés sur n'importe quelle machine Windows en double-cliquant sur un fichier de certificat au format .cer dans l'Explorateur de fichiers et en sélectionnant 'chemin de certification'
Lorsqu'un client visite le site Web, cette chaîne peut être vérifiée de deux manières. Le site Web peut présenter le site Web, l'émetteur et les certificats de politique * directement au client. Alternativement, certains clients peuvent rechercher des propriétés étendues sur les certificats qui fournissent une adresse pour télécharger le prochain certificat de la chaîne.
Au moins pour les clients de certificats Microsoft, cette extension de certificat est appelée "Accès aux informations d'autorité" (AIA), est formatée de manière similaire au champ CDP (point de distribution CRL) et peut être utilisée pour déterminer où se trouve le prochain certificat de la chaîne. Vous pouvez le voir sur l'onglet 'détails' de la même fenêtre qui a le chemin de certification, comme ci-dessous:
Plus d'informations sur les CDP et les AIA ici .
Donc, dans cet exemple, voici comment fonctionne la vérification client pour un scénario où toute la chaîne n'est pas présentée à l'avance:
- Un client visite website.com via https et se voit présenter le certificat 'Website'.
- Le client vérifie qu'il ne s'agit pas d'une racine approuvée et n'est pas auto-signé. Trouver un AIA pour le certificat "Émetteur", il télécharge ce certificat et vérifie la clé publique de ce certificat signé le certificat "Site Web".
- Le client vérifie que le certificat "Émetteur" n'est pas une racine approuvée et n'est pas auto-signé. Trouver un AIA pour le certificat "Policy", il télécharge ce certificat et vérifie la clé publique de ce certificat signé le certificat "Issuer".
- Le client vérifie que le certificat "Policy" n'est pas une racine approuvée et n'est pas auto-signé. Cependant, il constate que l'émetteur de ce certificat est l'une des racines de confiance et vérifie la clé publique du certificat racine signé le certificat "Policy".
Pour chaque certificat de la chaîne, les CDP sont vérifiés pour les listes de révocation de certificats (CRL), afin de s'assurer qu'il n'y a pas de révocation.
Si le client à un moment donné avait trouvé un certificat approuvé, le certificat "Site Web" a été vérifié comme émis par une racine approuvée et non révoqué. D'autres contrôles (comme la période de validité) peuvent toujours entraîner la nullité du certificat.
Si, à un moment donné, le client a trouvé un certificat auto-signé et non approuvé, le certificat "Site Web" n'a pas été vérifié comme émis par une racine de confiance. Normalement, le client affiche un avertissement à ce stade.
Oui, cela signifie que vous pourriez potentiellement avoir un certificat approuvé qui n'était pas auto-signé, mais ce n'est pas un scénario courant.
* Si le client fait confiance à la racine, il doit déjà avoir une copie du certificat racine - il doit avoir été ajouté manuellement à la liste des autorités racine de confiance! ( c'est aussi pourquoi certaines autorités de certification racine sont toujours SHA1 et ce n'est pas un problème ). CEPENDANT, certains sites Web présenteront toujours le certificat racine, car certains logiciels attendra une chaîne complète comprenant la racine redondante. Attendez-vous à ce genre de non-sens souvent lorsque vous avez affaire à un logiciel qui s'interface avec des certificats.
Addendum - Comment faire confiance à Roots
Bien que j'aie mentionné que les racines étaient approuvées manuellement, la plupart du temps, vos certificats racine approuvés seront distribués sur votre machine par des mécanismes non manuels, souvent intégrés dans chaque version du logiciel et/ou distribués avec des mises à jour automatiques. Voici une liste de méthodes et de politiques courantes pour les principaux logiciels utilisant des certificats d'interface de sites Web:
Mises à jour du programme de certificat racine de confiance Microsoft
Vous pouvez obtenir le dernier package de certificat ici .
- distribution basée sur le domaine Active Directory (notez que l'article lié couvre également la méthode pour ajouter manuellement une racine approuvée à un ordinateur Windows local.)
Les méthodes ci-dessus mettent à jour le magasin de certificats du système d'exploitation Windows qui est utilisé par plusieurs applications, notamment IE et Edge.
- Politique du magasin racine de Mozilla
- Politique de certificat racine - Les projets Chromium (y compris google chrome)
Mozilla et Chrome sont capables de faire confiance aux certificats indépendamment du système d'exploitation (en maintenant efficacement leurs propres magasins racine de confiance), et également de s'abonner au magasin racine de confiance du système d'exploitation, en fonction des paramètres configurés dans l'application et le système d'exploitation spécifique.
Les autorités de certification approuvées dans les magasins racine spécifiques à l'application seront ajoutées et supprimées en fonction des auspices de leur programme racine de confiance.