Cycle de vie et révocation des certificats

Chaque certificat numérique suit un cycle de vie défini, de sa création à son retrait. Les étapes sont les suivantes : demande et inscription (générer une paire de clés, créer une CSR), émission (la CA valide et signe), déploiement (installer sur un serveur ou un appareil), utilisation (période opérationnelle active), renouvellement (avant l’expiration) et révocation ou expiration (fin de vie). La gestion de ce cycle à grande échelle — notamment dans les entreprises qui possèdent des milliers de certificats — nécessite des outils d’automatisation et de gestion du cycle de vie des certificats (CLM), car un suivi manuel entraîne inévitablement l’expiration de certificats et les interruptions de service qui en résultent.

Le cycle de vie du certificat commence par une Certificate Signing Request (CSR). Le demandeur génère une paire de clés, puis crée une CSR qui contient le public key, les informations du Subject (CN, O, C) et qui est signée avec la clé privée (ce qui prouve la possession de la clé privée sans la révéler). La CSR est envoyée à la CA, qui valide l’identité du demandeur et, si elle l’approuve, signe le certificat. La clé privée ne quitte jamais la possession du demandeur. La génération de la CSR est l’étape essentielle où la robustesse de la clé est déterminée : utilisez au minimum RSA 2048 bits ou ECC 256 bits.

Les certificats doivent être renouvelés avant l’expiration de leur date notAfter. La bonne pratique consiste à commencer le processus de renouvellement au moins 30 jours avant l’expiration (de nombreuses organisations visent 60 à 90 jours). Le renouvellement consiste généralement à générer une nouvelle CSR et une nouvelle clé privée, à les soumettre à la CA, puis à remplacer l’ancien certificat et l’ancienne clé sur tous les serveurs où le certificat est déployé. Let’s Encrypt automatise ce processus à l’aide du protocole ACME : l’outil certbot renouvelle automatiquement les certificats lorsqu’il leur reste moins de 30 jours. Les certificats expirés provoquent des erreurs dans les navigateurs qui empêchent les utilisateurs d’accéder aux services.

La révocation d’un certificat est le processus qui consiste à invalider un certificat avant sa date d’expiration prévue. Les raisons de révoquer un certificat comprennent : la clé privée a été compromise (cas le plus urgent — une révocation immédiate est nécessaire), le certificat a été émis par erreur (mauvais domaine, mauvaise organisation), les informations du Subject ont changé (changement de nom de l’entreprise, départ d’un employé) ou la CA elle-même a été compromise. La révocation est essentielle, car les navigateurs et les systèmes qui ignorent qu’un certificat a été révoqué continuent de lui faire confiance, ce qui permet à un attaquant possédant la clé privée volée de mener une attaque MITM jusqu’à l’expiration du certificat ou jusqu’à ce que sa révocation soit connue.

Une Certificate Revocation List (CRL) est une liste signée publiée par une CA qui contient les numéros de série de tous les certificats qu’elle a révoqués et qui n’ont pas encore expiré. Les clients téléchargent la CRL, la mettent en cache et vérifient si le numéro de série d’un certificat présenté figure dans la liste. Les CRL présentent des limites importantes : elles peuvent être très volumineuses (les grandes CA comptent des millions de certificats révoqués), les clients les mettent souvent en cache pendant plusieurs heures ou plusieurs jours, ce qui crée un décalage, et télécharger la CRL complète pour chaque connexion est inefficace. Les CRL sont toujours utilisées, mais elles sont de plus en plus complétées ou remplacées par OCSP.

OCSP (Online Certificate Status Protocol) permet de vérifier en temps réel la révocation d’un certificat sans obliger les clients à télécharger les CRL entières. Le client envoie une requête au répondeur OCSP de la CA avec le numéro de série du certificat. Le répondeur renvoie une réponse signée indiquant que le certificat est valide, révoqué (avec la date et le motif de révocation) ou inconnu. OCSP est plus rapide et plus à jour qu’une CRL, mais chaque connexion TLS nécessite un aller-retour HTTP supplémentaire vers le répondeur OCSP, ce qui augmente la latence. Les réponses OCSP sont signées par la CA afin d’empêcher toute falsification.

OCSP Stapling résout le problème de latence lié à la vérification OCSP en temps réel. Au lieu d'interroger le répondeur OCSP de la CA lors de chaque négociation TLS, le serveur récupère à l'avance sa propre réponse OCSP auprès de la CA et l'« agrafe » (la joint) à la négociation TLS. Le client reçoit directement du serveur une réponse OCSP récente, signée par la CA — aucun aller-retour supplémentaire n'est nécessaire. Le serveur actualise périodiquement sa réponse OCSP agrafée (généralement toutes les heures). OCSP Stapling accélère les connexions et réduit la charge des répondeurs OCSP des CA, tout en maintenant la vérification de révocation.

OCSP Must-Staple est une extension X.509 qui indique aux navigateurs que le serveur doit fournir une réponse OCSP agrafée. En son absence, les navigateurs appliquent un « échec tolérant » si la vérification OCSP échoue — ils autorisent malgré tout la connexion (pour éviter qu'une panne du répondeur OCSP ne bloque toutes les connexions TLS). Un attaquant peut exploiter ce comportement en bloquant la requête OCSP du client, donnant ainsi l'impression que le certificat est toujours valide même après sa révocation. OCSP Must-Staple empêche cela en exigeant une réponse agrafée valide ; sans celle-ci, le navigateur refuse la connexion. Son adoption reste limitée en raison de la complexité du déploiement.

La révocation des certificats et l'agrafage des certificats répondent au même problème — faire confiance à des certificats frauduleux — mais sous des angles différents. La révocation (CRL/OCSP) est un mécanisme réactif : la CA invalide un certificat après la découverte d'un problème. L'agrafage est un mécanisme proactif : l'application refuse tout certificat autre que celui approuvé à l'avance. L'agrafage offre de meilleures garanties que la révocation, car il reste efficace même si la CA tarde à révoquer le certificat, mais il rend le déploiement plus rigide. Pour l'examen Security+, vous devez connaître les deux mécanismes et comprendre que la révocation est le mécanisme PKI standard, tandis que l'agrafage est une mesure facultative de défense en profondeur.

Lorsqu'un certificat est révoqué, la CA lui attribue un code de motif de révocation qui aide les clients et les administrateurs à comprendre pourquoi. Les codes de motif courants définis dans la RFC 5280 comprennent : keyCompromise (la clé privée a été compromise), cACompromise (la CA émettrice a été compromise), affiliationChanged (l'organisation du sujet a changé), superseded (un nouveau certificat a été émis pour le remplacer), cessationOfOperation (le domaine n'est plus actif) et privilegeWithdrawn (le droit a été révoqué). Le code de motif apparaît à la fois dans les entrées de la CRL et dans les réponses OCSP, fournissant un contexte aux équipes chargées de la réponse aux incidents qui enquêtent sur les événements de révocation.

Le protocole ACME (Automatic Certificate Management Environment), utilisé par Let's Encrypt, automatise tout le cycle de vie des certificats. Les clients ACME (comme certbot) demandent, renouvellent et déploient automatiquement les certificats, sans intervention humaine. La CA utilise des défis de validation de domaine pour confirmer la propriété du domaine : le défi HTTP-01 exige de placer un fichier spécifique à une URL connue ; le défi DNS-01 exige de créer un enregistrement DNS TXT. ACME a transformé la gestion des certificats : les certificats valables 90 jours de Let's Encrypt alimentent désormais une grande partie du trafic HTTPS sur Internet, et sont tous renouvelés automatiquement.

Testez votre compréhension des notions de CompTIA Security+ (SY0-701) abordées dans cette leçon.

Dans cette leçon, vous avez appris que le cycle de vie d'un certificat va de la génération de la CSR à l'émission, au déploiement, puis au renouvellement ou à la révocation ; la CRL fournit des listes de révocation groupées, tandis qu'OCSP fournit l'état de chaque certificat en temps réel ; OCSP Stapling élimine la latence de l'OCSP en temps réel ; et ACME (Let's Encrypt) automatise tout le cycle de renouvellement. Nous allons maintenant étudier les cas d'utilisation de la PKI.