Certificat Révocation

quand un Autorité de certification émets un certificat numérique, il définit une période de validité : une date de début et une date d'expiration. Dans des circonstances normales, le certificat est considéré comme fiable pendant toute cette période et est rejeté par la suite. Mais que se passe-t-il lorsqu'un certificat doit être invalidé avant son expiration ?

C’est ici que la révocation de certificat intervient. La révocation est le processus par lequel une autorité de certification (CA) déclare qu’un certificat précédemment émis ne doit plus être fiable, même s’il n’a pas encore expiré. Sans révocation, un certificat compromis resterait valide jusqu’à son expiration naturelle, donnant potentiellement à un attaquant des jours, des semaines ou des mois pour usurper l’identité d’un serveur légitime, signer du code malveillant ou intercepter des communications chiffrées.

L'écosystème PKI fournit deux mécanismes principaux pour communiquer l'état de révocation aux clients : Listes de révocation de certificats (CRLs) et le Protocole de statut de certificat en ligne (OCSP). Chaque approche présente des forces et des compromis distincts, et les comprendre est essentiel pour quiconque gère des certificats à grande échelle.

Une liste de révocation de certificats est le mécanisme de révocation original défini dans la norme X.509. Une CRL est un fichier signé, publié par une autorité de certification, qui contient une liste des numéros de série de tous les certificats qui ont été révoqués avant leur date d'expiration. Chaque entrée comprend le numéro de série du certificat's, la date de révocation et, éventuellement, un code de raison.

Les CRL sont publiées aux URL spécifiées dans le certificat's Points de distribution des CRL extension. Lorsqu'un client (tel qu'un navigateur ou une application) doit vérifier un certificat, il télécharge la CRL depuis cette URL et vérifie si le numéro de série du certificat's apparaît dans la liste. Si c'est le cas, le certificat est rejeté.

Les CRL sont périodiquement mises à jour et signées par l'Autorité de Certification (CA), généralement selon un planning fixe (toutes les quelques heures ou une fois par jour). nextUpdate horodatage qui indique aux clients quand une version plus récente sera disponible. Entre les mises à jour, les clients mettent en cache la CRL localement pour éviter des téléchargements répétés.

La principale limitation des CRL est l'évolutivité. Pour une CA qui a révoqué des milliers de certificats, le fichier CRL peut atteindre plusieurs mégaoctets. Télécharger et analyser un gros fichier simplement pour vérifier un seul certificat est inefficace, surtout sur les appareils mobiles ou dans des environnements réseau contraints. De plus, l'intervalle entre les publications de CRL crée une fenêtre pendant laquelle un certificat récemment révoqué peut encore être accepté par les clients utilisant une CRL mise en cache et obsolète.

OCSP (défini dans la RFC 6960) a été développé pour répondre aux limitations des CRL. Au lieu de télécharger une liste complète de révocation, le client envoie une requête légère à un répondeur OCSP demandant le statut d'un seul certificat. Le répondeur répond avec l'un des trois statuts : bon, révoqué, ou inconnu.

L'URL du répondeur OCSP est spécifiée dans le certificat Accès à l'information d'autorité (AIA) extension. Le client inclut le numéro de série du certificat et l'identifiant de l'émetteur dans la requête, et le répondeur renvoie une réponse signée que le client peut vérifier. Comme chaque requête cible un seul certificat, la réponse est petite (généralement quelques centaines d'octets) et rapide à traiter.

OCSP offre plusieurs avantages par rapport aux CRL. Les réponses sont en temps réel (ou quasi temps réel), les données transférées sont minimales, et les clients n'ont pas besoin de stocker ou d'analyser de gros fichiers. Cependant, OCSP introduit ses propres défis. Le client doit effectuer une requête réseau vers le répondant OCSP pour chaque certificat qu'il valide, ce qui ajoute de la latence à la poignée de main TLS. Si le répondant est lent ou inaccessible, les clients font face à une décision difficile : échouer en mode ouvert (accepter le certificat sans vérification, ce qui est peu sûr) ou échouer en mode fermé (rejeter le certificat, ce qui provoque une panne

OCSP soulève également des préoccupations de confidentialité. Parce que le client envoie le numéro de série du certificat' à l'interrogateur, l'autorité de certification qui exploite l'interrogateur peut observer quels sites Web ou services un utilisateur tente de rejoindre. Il s'agit d'un problème important pour la confidentialité des utilisateurs, et c'était l'une des motivations derrière le stapling OCSP.