Qui est responsable de la révocation d'un certificat?
L'AC délivre des certificats aux clients/serveurs. Chaque fois qu'une demande est faite par le client/serveur, le certificat est utilisé pour vérifier l'identité.
Maintenant, si un certificat doit être révoqué, qui le fait et comment? Le client/serveur le "marque" comme révoqué? Ou le CA le fait-il? Si l'AC le fait, comment sait-elle quand révoquer quoi?
De plus, y a-t-il un champ sur le certificat qui indique qu'il est révoqué? Ou existe-t-il une liste noire de certificats qui contient tous les certificats révoqués?
Le réponse de user2320464 est bon, mais j'aimerais développer davantage.
Résumé: Le titulaire du certificat ne gère généralement pas ses propres informations de révocation, car le but de la révocation est d'annoncer que le titulaire de ce certificat n'est pas digne de confiance. Le propriétaire légitime du certificat doit pouvoir déclarer le certificat révoqué, mais de manière à ce qu'un attaquant qui possède également la clé privée ne puisse pas "annuler" la révocation. Si le propriétaire du certificat lui-même n'est plus digne de confiance, vous avez besoin d'un moyen de révoquer le certificat même contre sa volonté.
La meilleure solution que nous ayons trouvée consiste pour un tiers à suivre les informations de révocation, généralement l'autorité de certification qui a émis le certificat. Ils maintiennent des listes noires et peuvent également répondre aux demandes en ligne de "le certificat # 28277392 est-il révoqué?".
Pourquoi la révocation est moche
La révocation est vraiment le vilain petit canard dans le monde des certificats; nous n'avons pas encore trouvé un moyen élégant de le gérer. La raison pour laquelle c'est difficile est qu'il existe des exigences apparemment contradictoires:
Lorsqu'un serveur remet son certificat à un client, le client doit pouvoir dire si le certificat est révoqué.
Le serveur ne devrait pas être responsable de la génération ou de la transmission des informations de révocation pour son propre certificat. C'est comme demander au chien d'aller vérifier si les cookies sont toujours là et de ne pas mentir à ce sujet.
L'Autorité de certification doit donc générer dynamiquement des informations de révocation pour chaque certificat. (ou au moins le suivre et publier la liste noire toutes les heures ou tous les jours).
L'une des beautés des certificats est qu'ils contiennent toutes les données pour valider la signature, ce que vous pouvez faire hors ligne et très rapidement.
Mais la révocation doit être en temps réel, vous ne pouvez pas simplement la mettre dans le certificat initial et l'oublier, car vous ne savez jamais à quel moment elle sera révoquée.
Si le client doit contacter directement l'autorité de certification pour chaque validation de certificat, il est impossible de valider un certificat hors ligne et vous ajoutez un décalage réseau.
Il existe aujourd'hui deux principaux mécanismes de révocation: CRL et OCSP (voir ci-dessous), mais aucun n'est vraiment une solution élégante.
Pourquoi les certificats sont révoqués
Votre commentaire
Le client/serveur le "marque" comme révoqué?
me fait croire que vous ne comprenez pas vraiment pourquoi un certificat serait révoqué. Il existe généralement trois grandes raisons de révoquer un certificat:
Le propriétaire légitime du certificat en abuse. Il s'agit généralement d'une sous-autorité de certification qui émet des certificats qu'ils ne devraient pas. Leur certificat est révoqué pour dire au monde de ne plus leur faire confiance.
Le serveur est hors service ou le certificat n'est plus nécessaire pour une raison quelconque.
Compromis de clé de la clé privée correspondant au certificat. Nous ne pouvons plus faire confiance à quoi que ce soit signé ou chiffré pour ce certificat, car nous ne savons plus si nous parlons au propriétaire légitime ou au pirate.
Dans le cas 2), le propriétaire du certificat pourrait signaler son propre certificat pour révocation de la manière que vous proposez, mais dans les deux autres cas, l'attaquant pourrait simplement utiliser une ancienne version du certificat avant sa révocation. La révocation doit donc vraiment être gérée par un tiers, hors du contrôle du titulaire du certificat. Habituellement, cela est fait par l'autorité de certification qui a émis les certificats.
Pour révoquer un certificat, vous contactez généralement l'autorité de certification, prouvez que vous êtes qui vous dites être et demandez-lui de révoquer le certificat. Je pense que cela dépend de CA à CA du niveau de preuve dont ils ont besoin avant de révoquer un certificat pour vous - c'est pour empêcher un attaquant de demander qu'un certificat soit révoqué en tant que déni de service. Pour les certificats d'utilisateur final comme un certificat de serveur, la révocation est souvent automatisée et la signature du message réseau avec la clé privée du certificat est suffisante (c'est-à-dire qu'un certificat peut se révoquer lui-même). Pour révoquer des certificats de grande valeur comme une sous-autorité de certification, il y a beaucoup de travail informatique et de nettoyage à faire, des certificats d'utilisateur final à migrer et à réémettre, des amendes à payer, etc., donc une révocation sera un incident majeur impliquant de nombreuses personnes des deux sociétés.
Comment les certificats sont révoqués
existe-t-il une liste noire de certificats tenue à jour contenant tous les certificats révoqués?
Oui. Le mécanisme le plus simple est appelé Liste de révocation de certificats (CRL) qui est exactement ce que vous attendez: une liste des numéros de série de tous les certificats révoqués. Chaque autorité de certification est responsable du suivi de l'état de révocation de tous les certificats qu'elle a émis et de la publication d'une nouvelle CRL toutes les heures ou tous les jours. La CRL est signée par la clé CA, elle est donc inviolable. C'est juste un .crl fichier que vous pouvez télécharger, faire circuler, wtv. Cela peut être utilisé semi-hors ligne, tant que vous vous connectez et l'actualisez toutes les 24 heures, vous pouvez l'utiliser hors ligne (mais bien sûr, vous n'avez aucun moyen de savoir si vous parlez à un certificat compromis jusqu'à votre prochaine CRL rafraîchir).
Le mécanisme plus "convivial pour le cloud" est appelé OCSP . Le client ouvre une connexion directement à l'autorité de certification et demande
Client: "Hé, j'ai le certificat # 9388038829188 que vous avez émis, est-ce toujours bon?"
CA: "Ouaip, c'est toujours bon".
Cela résout le problème de retard avec les listes de révocation de certificats, mais nécessite que le client soit en ligne et ajoute un retard de réseau au processus de cryptage.
En 2011, un système appelé OCSP Stapling a été introduit qui permet au serveur de pré-récupérer la réponse OCSP de l'autorité de certification, disons une fois toutes les 5 minutes, et de la regrouper avec le certificat lors de sa remise au client. Cela accélère, entre autres, la cryptographie du client pour valider le certificat, car il a une copie locale de tout ce dont il a besoin, aucune nouvelle connexion réseau requise. Ceci est considéré comme une solution élégante pour TLS (c'est-à-dire https, ftps, ssh, vpn, etc.) où vous ouvrez une connexion à un serveur qui a accès à Internet, mais cela ne résout pas la révocation pour les utilisations non TLS des certificats, comme la journalisation dans Windows avec une carte à puce PKI, en lançant un logiciel signé par code (comme toute application mobile), en ouvrant un document PDF PDF, etc.) auquel j'aimerais continuer à travailler même si je ne suis pas connecté l'Internet.
Comment il est transmis à l'utilisateur final
y a-t-il un champ sur le certificat qui indique qu'il est révoqué?
Oui, dans un certificat X.509 (comme SSL), l'adresse où vous pouvez trouver la CRL va dans le CRL Distribution Point, et l'adresse OCSP va dans le Authority Information Access champ. Par exemple, le certificat pour *.stackexchange.com qui protège cette page contient:
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://crl3.digicert.com/sha2-ha-server-g5.crl
[2]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://crl4.digicert.com/sha2-ha-server-g5.crl
[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.digicert.com
URL=http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt
En règle générale, les certificats sont révoqués par la personne à qui le certificat a été délivré. Donc, si vous achetiez un certificat SSL et que vous découvriez plus tard que la clé privée était compromise, vous révoqueriez le certificat. Cette action serait enregistrée sur l '"autorité de certification émettrice" où le numéro de série du certificat nouvellement révoqué apparaîtrait dans la liste de révocation de certificats (CRL) ou serait envoyé via le protocole OCSP (Online Certificate Status Protocol). Les deux sont gérés par l'autorité de certification émettrice, bien que les deux n'aient pas à être utilisés. Les emplacements CRL et OCSP sont publiés dans le certificat. En théorie, c'est très bien, le problème est que tous les clients ne vérifient pas les listes de révocation aussi diligemment qu'ils le devraient.
Puisqu'il n'y a aucun moyen d'invalider cryptographiquement un certificat, un système doit être utilisé pour annoncer publiquement la révocation d'un certificat. Le protocole OCSP (Online Certificate Status Protocol) est le moyen actuel de procéder. Les navigateurs peuvent vérifier auprès d'un fournisseur OCSP pour confirmer qu'un certificat n'est pas révoqué avant de se connecter à un site Web.
Il est de la responsabilité de la personne qui a acheté les certificats d'assurer la sécurité du certificat.
Il est de la responsabilité de l'AC de révoquer tous les certificats qui ont été aperçus en violation des conditions de service.
Un certificat ressemble beaucoup à un permis de conduire. Si quelqu'un le vole, vous devez le signaler.
L'opérateur du site Web est chargé d'aviser l'AC de révoquer le certificat et réémet généralement un nouveau certificat en même temps.
L'AC est ensuite responsable de la publication de ces informations via CRL et/ou OCSP.
L'application cliente est chargée de récupérer l'état CRL/OCSP d'un certificat auprès de l'autorité de certification.
Dans certains cas rares, l'AC peut révoquer unilatéralement un certificat. Cela peut se produire, par exemple, si l'AC estime que le titulaire du certificat enfreint les conditions d'utilisation du certificat ou si l'AC détecte des violations internes ou si l'AC pense que le certificat a été émis et/ou utilisé frauduleusement. Les circonstances dans lesquelles une autorité de certification peut révoquer des certificats sont divulguées dans l'énoncé de pratique de certification de l'autorité de certification, que l'autorité de certification doit publier publiquement dans le cadre de son exigence d'inclusion dans la liste d'autorité par défaut des navigateurs.