Autorité de certification souveraine pour l'émission et la gestion de certificats à l'échelle de l'entreprise
Gestion du cycle de vie des certificats : découverte, gouvernance et automatisation
Domain Control Validation agnostique des DNS, prêt pour les certificats TLS de 47 jours
OCSP est le protocole de requête en ligne qui permet à une partie de confiance de demander à une autorité de certification, en temps réel, si un certificat est toujours valide. Ce guide explique le fonctionnement d'OCSP, sa comparaison avec les CRL, ce que changent le stapling et Must-Staple, et comment exploiter un responder OCSP à l'échelle imposée par les certificats TLS de 47 jours.
Le protocole OCSP (Online Certificate Status Protocol), défini par la RFC 6960, est l'alternative « par certificat » aux listes de révocation (CRL). Plutôt que de télécharger la liste complète de tous les certificats qu'une CA a un jour révoqués, la partie de confiance envoie une requête minimale — « ce numéro de série est-il toujours bon ? » — et le responder OCSP de la CA renvoie une réponse signée. Cette réponse pèse typiquement environ un kilo-octet, soit deux à trois ordres de grandeur de moins que la CRL d'une CA active.
OCSP a été normalisé en 1999, affiné par la RFC 6960 en 2013, avec un profil pour le service HTTP à haut volume dans la RFC 5019 (Lightweight OCSP). Aujourd'hui, presque tous les certificats TLS publics portent une URL de responder OCSP dans leur extension Authority Information Access (AIA), et presque tous les serveurs TLS sérieusement déployés servent une réponse stapled pour éviter au client tout appel direct à la CA.
OCSP compte davantage en 2026 qu'il y a cinq ans, pas l'inverse. Le CA/Browser Forum a tracé la route vers des certificats TLS de 47 jours, le mTLS est devenu la norme dans les service meshes et les architectures Zero Trust, et la révocation doit toujours fonctionner pendant la brève fenêtre où une clé privée a fuité mais où le certificat n'a pas encore expiré. Ce guide parcourt le protocole, les pièges opérationnels, et la place d'OCSP aux côtés des CRL, du stapling et de Must-Staple.
Quand un navigateur, un client mTLS ou un vérificateur de signature de code veut savoir si un certificat a été révoqué avant son expiration, il a deux options. Il peut télécharger la CRL de la CA émettrice — parfois un fichier de plusieurs mégaoctets contenant tous les certificats révoqués de la hiérarchie — et y chercher un numéro de série. Ou bien il peut poser une question bien plus petite, adressée à un point unique, à propos d'un seul certificat. OCSP est le protocole de cette seconde question.
Le protocole n'est pas neuf. La RFC OCSP d'origine date de 1999, la révision actuelle (RFC 6960) de 2013, et le profil HTTP à haut volume (RFC 5019) de 2007. Ce qui a changé, c'est le contexte opérationnel : les durées de vie TLS convergent vers 47 jours, le mTLS devient la norme à l'intérieur du périmètre, et tout chemin de révocation qui dépend d'une requête en ligne fraîche vers la CA doit absorber des milliards de requêtes par jour. OCSP reste un maillon essentiel — mais seulement s'il est exploité correctement.
Un échange OCSP tient en quatre étapes. Les trois premières sont mécaniques ; la quatrième est l'endroit où vivent la plupart des problèmes de production.
La structure paraît simple. Ce qui la rend intéressante, c'est le cache : chaque partie de confiance le long de la chaîne (le navigateur, le cache de validation de l'OS, un proxy intermédiaire, le CDN devant le responder) peut détenir une réponse signée, et tant que `thisUpdate` et `nextUpdate` encadrent encore le présent, cette copie en cache vaut une copie fraîche. OCSP n'est donc pas « temps réel » au sens courant — il est « aussi frais que le responder publie », ce qui se situe en général entre une heure et quelques jours.
La partie de confiance extrait le nom de l'émetteur, sa clé publique, et le numéro de série du certificat à valider. Elle hache le nom de l'émetteur et sa clé publique (SHA-1 par défaut dans la RFC 6960, SHA-256 largement pris en charge), enveloppe le tout avec le numéro de série dans une structure `CertID`, et encapsule cette structure dans une `OCSPRequest` encodée en ASN.1 DER. La requête fait typiquement quelques dizaines d'octets. L'URL du responder elle-même se lit dans l'extension Authority Information Access du certificat, plus précisément dans la méthode d'accès `id-ad-ocsp`.
La requête voyage en HTTP (et non HTTPS — la réponse étant signée, le chiffrement de transport n'ajouterait que de la latence sans bénéfice de sécurité). La RFC 5019 impose GET pour les requêtes courtes, les octets DER étant encodés en base64 puis URL-encodés dans le chemin ; les requêtes plus longues basculent sur POST. L'URL du responder est en HTTP en clair précisément pour que les caches HTTP agressifs et les CDN placés en amont de la CA puissent servir des réponses mises en cache sans terminer TLS.
Le responder cherche le numéro de série dans sa base de révocation et produit une `OCSPResponse` contenant un statut (`good`, `revoked` ou `unknown`), un horodatage `thisUpdate` (à quand remonte cette réponse), un horodatage `nextUpdate` (quand une nouvelle réponse sera disponible) et, si le certificat est révoqué, une date de révocation et un code de raison optionnel. L'ensemble est signé soit directement par la CA émettrice, soit, plus couramment, par un certificat de signature OCSP délégué portant l'extended key usage `id-kp-OCSPSigning`. Les réponses pèsent typiquement autour d'1 Ko.
Le client vérifie la signature contre l'émetteur (ou la chaîne du signataire délégué), s'assure que `thisUpdate` est récent et que `nextUpdate` n'est pas dépassé, confirme que le `CertID` de la réponse correspond à celui de la requête, et lit le statut. La réponse est ensuite mise en cache localement — par numéro de série, jusqu'à `nextUpdate` — afin qu'une même requête dans la même fenêtre n'engendre pas un nouveau round-trip réseau.
La RFC 6960 définit trois valeurs de statut, et l'écart entre ce qu'elles paraissent dire et ce qu'elles affirment réellement est à l'origine de plus d'un incident en production.
Le responder n'a pas d'enregistrement indiquant que ce certificat est révoqué. Surtout, la RFC 6960 §2.2 prend soin de préciser que « good » n'affirme pas que le certificat a un jour été émis, mais uniquement qu'il ne figure pas dans la liste de révocation. Un responder configuré pour « répondre good à tout numéro de série inconnu » bénira sans broncher des certificats jamais émis. Les responders de production doivent être configurés pour affirmer une émission positive, souvent en basculant les numéros inconnus vers `unknown` plutôt que `good`.
Le certificat a été révoqué. La réponse porte un `revocationTime` et, en option, un `revocationReason` correspondant aux codes de raison CRL de la RFC 5280 (`keyCompromise`, `cACompromise`, `affiliationChanged`, `superseded`, `cessationOfOperation`, `certificateHold`, `privilegeWithdrawn`, `aACompromise`). Pour les raisons permanentes comme `keyCompromise`, le statut ne reviendra jamais en arrière ; pour la suspension transitoire `certificateHold`, un retour ultérieur à `good` est autorisé.
Le responder n'a aucune information sur ce certificat. Ce n'est ni une erreur, ni un soft pass — c'est un « je ne peux pas répondre » explicite. Un client correctement configuré doit traiter `unknown` comme un échec strict pour un certificat censé être émis par une CA dont le responder devrait être au courant. En pratique, beaucoup de clients soft-fail à la place, ce qui est précisément le problème dont parle l'avertissement plus bas.
CRL et OCSP résolvent le même problème avec des compromis opposés. Le couplage est si fréquent que la plupart des PKI modernes exploitent les deux, le responder s'appuyant sur la même base de révocation que celle qui produit la CRL.
Les deux mécanismes échouent aussi différemment. Une CRL périmée échoue en mode fermé (le client le sait, refuse), alors qu'une réponse OCSP manquante échoue en mode ouvert dans la plupart des navigateurs et piles TLS (soft-fail). Cette asymétrie est ce qui rend la discussion sur le stapling ci-dessous structurante plutôt que cosmétique.
| <a href="/fr/guide/crl" class="text-[#5081BD] hover:text-[#001363] no-underline font-medium">CRL</a> | OCSP | |
|---|---|---|
| Mécanisme | Téléchargement de la liste complète des numéros de série révoqués | Requête signée par certificat |
| Fraîcheur | Publication périodique (heures à jours) | Aussi fraîche que `nextUpdate`, typiquement quelques heures ; minutes possibles |
| Bande passante | Liste entière à chaque rafraîchissement, jusqu'à plusieurs Mo | Environ 1 Ko par réponse, mise en cache par les CDN |
| Confidentialité | Le client télécharge la liste ; la CA n'apprend rien sur le certificat vérifié | OCSP direct révèle « je vais consulter le site X » à la CA ; le stapling corrige cela |
| Hors-ligne | Fonctionne avec une CRL en cache dans sa fenêtre de validité | Nécessite un accès réseau, sauf si la réponse est stapled |
| Norme | RFC 5280 | RFC 6960, RFC 5019 (profil Lightweight) |
Avant d'interroger quoi que ce soit, il vous faut l'URL du responder. Elle se trouve dans l'extension Authority Information Access du certificat lui-même.
Avec l'URL du responder en main, vous pouvez émettre une requête OCSP directe. C'est la forme la plus basse du protocole et celle vers laquelle on se tourne pour déboguer un responder ou en tester un nouveau.
Pour un serveur TLS en production, le test le plus utile reste de savoir si le serveur staple bien une réponse dans le handshake. Une seule commande suffit.
Le drapeau `-status` de `s_client` est la commande la plus utile pour diagnostiquer un problème OCSP en production. S'il renvoie `no response sent`, le serveur ne staple pas, et chaque client qui s'y connecte fait soit une requête OCSP directe (lente, indiscrète), soit un soft-fail (non sécurisé).
# Extract the OCSP responder URL from a certificate's AIA extension
openssl x509 -in cert.pem -noout -ocsp_uri
# Or the full AIA, including any CA Issuers URLs used to fetch intermediates
openssl x509 -in cert.pem -noout -text | grep -A 4 "Authority Information Access"
# Sample output:
# Authority Information Access:
# OCSP - URI:http://ocsp.example-ca.com
# CA Issuers - URI:http://crt.example-ca.com/intermediate.crt# Fetch the issuing CA's certificate, then ask the responder about cert.pem
openssl x509 -in cert.pem -noout -issuer_hash
curl -o issuer.pem http://crt.example-ca.com/intermediate.crt
# Send a manual OCSP request via OpenSSL
openssl ocsp \
-issuer issuer.pem \
-cert cert.pem \
-url "$(openssl x509 -in cert.pem -noout -ocsp_uri)" \
-resp_text \
-no_nonce
# A healthy response will print:
# Response verify OK
# cert.pem: good
# This Update: ...
# Next Update: ...# Check whether the server staples an OCSP response in the TLS handshake
echo | openssl s_client -connect example.com:443 -servername example.com -status 2>/dev/null \
| grep -E "OCSP response|Cert Status|This Update|Next Update"
# A server that staples correctly returns something like:
# OCSP Response Status: successful (0x0)
# Cert Status: good
# This Update: <recent timestamp>
# Next Update: <future timestamp, typically hours to days ahead>
# A server that does NOT staple returns:
# OCSP response: no response sentExploiter un responder OCSP n'est pas la même chose que publier des CRL. C'est un service en ligne à haute disponibilité et faible latence, dont l'indisponibilité a déjà été utilisée comme arme par le passé. Quatre contraintes structurent la conception.
Une CA ne vaut que ce que vaut son infrastructure de révocation. Si le responder OCSP est indisponible pendant une heure, chaque partie de confiance qui n'a pas de réponse fraîche en cache soit soft-fail (insécurisé), soit hard-fail (panne). Les responders de production tournent derrière un CDN, sont répliqués sur plusieurs régions, et sont monitorés par des sondes externes — pas seulement des health checks internes. Traitez le responder comme un service tier-zero, avec les mêmes exigences de disponibilité que la CA elle-même. Un SLA à 99,95 % sur la CA combiné à un SLA à 99,5 % sur le responder ne donne pas une PKI à 99,5 % ; il donne une PKI dont la révocation effective est cassée quarante heures par an.
Lorsqu'un navigateur va chercher directement une réponse OCSP, le responder de la CA voit le numéro de série du certificat et l'IP du demandeur. Du numéro de série il peut déduire le site visité ; de l'IP il peut le corréler à un utilisateur. Ce n'est pas théorique — chaque échange OCSP direct est un événement de télémétrie envoyé à la CA. Les deux remèdes corrects sont le stapling côté serveur (le client ne parle jamais à la CA) et la mise en cache agressive du responder via des CDN partagés (la CA ne peut pas remonter facilement des numéros de série aux utilisateurs). La confidentialité est la raison pour laquelle des navigateurs comme Firefox déprécient discrètement OCSP direct depuis plus de dix ans.
La RFC 6960 prévoit une extension `Nonce` qui empêche un responder de rejouer une ancienne réponse « good » — utile en théorie, mais incompatible avec le cache, puisque chaque requête produit alors une réponse unique. Le profil Lightweight (RFC 5019) abandonne les nonces au profit d'un cache HTTP massif, raison pour laquelle les déploiements de production servent des réponses sans nonce avec des fenêtres `thisUpdate`/`nextUpdate` de plusieurs heures. La contrepartie : un certificat compromis peut rester « good » dans les réponses en cache jusqu'à expiration de `nextUpdate`. Choisissez la fenêtre délibérément. Douze heures, c'est courant ; une heure, c'est agressif ; sept jours (la borne haute de certaines CA), c'est irresponsable pour des certificats à fort enjeu.
À mesure que les durées de vie TLS convergent vers 47 jours, le nombre de certificats distincts qu'une CA émet par an est multiplié par environ huit, et le volume de requêtes OCSP grimpe en proportion. Un responder qui servait confortablement des certificats d'un an peut ne pas survivre au même parc en rotation 47 jours. Pré-signez les réponses lorsque c'est possible (la RFC 5019 l'autorise explicitement), servez-les derrière un CDN avec mise en cache HTTP, et mesurez les temps de réponse au p99, pas en moyenne. Un responder dont le p99 est à deux secondes cassera des handshakes TLS bien avant que la moyenne n'ait l'air mauvaise.
OCSP n'est pas un mécanisme hérité en attente d'être remplacé. C'est la colonne vertébrale opérationnelle de la révocation TLS, même dans les environnements où les CRL sont encore publiées — typiquement en repli, comme piste d'audit, et comme entrée à partir de laquelle les réponses OCSP sont générées. L'image qui se dessine dans la plupart des entreprises ressemble à ceci :
- TLS public : OCSP stapling sur chaque serveur exposé, avec la CRL en repli pour les clients qui ne négocient pas le stapling. Le responder est hébergé par la CA publique ; l'entreprise exploite la configuration de stapling sur ses propres répartiteurs de charge. - mTLS interne : CA privée avec un responder OCSP privé, souvent colocalisé avec la CA émettrice sur le même réseau. Le stapling est configuré partout où le proxy ou le sidecar le permet ; à défaut, le responder est exploité comme un service tier-zero à l'intérieur du périmètre. - Certificats à longue durée de vie (signature de code, signature de document, S/MIME) : ils portent presque toujours à la fois une URL OCSP et un point de distribution CRL, parce que les vérificateurs peuvent être hors ligne, fonctionner sur des plateformes dont les magasins de certificats se mettent à jour lentement, ou avoir besoin d'affirmer une validité des années plus tard.
La vraie question de conception n'est plus « OCSP ou CRL ? » mais « où vit chaque réponse, jusqu'à quel point chaque cache peut-il dériver, et que se passe-t-il quand le responder est injoignable ? ». Répondre à cela de manière cohérente sur des milliers de services, c'est précisément ce pour quoi une plateforme CLM existe.
Responder OCSP intégré, adossé à la CA émettrice — Evertrust PKI embarque un responder OCSP natif piloté par la même base de révocation que celle qui produit les CRL. Les réponses sont signées soit directement par la CA, soit par un certificat délégué `id-kp-OCSPSigning`, avec des fenêtres `thisUpdate`/`nextUpdate` configurables pour ajuster le compromis fraîcheur/cache à votre environnement. Le responder repose sur la même architecture non bloquante et entièrement asynchrone que le reste de la PKI, conçue pour absorber le volume de requêtes que vont engendrer des durées de vie plus courtes.
Réponses prêtes pour le stapling et service haute disponibilité — Evertrust PKI prend en charge les réponses OCSP pré-signées lorsque la politique d'émission l'autorise, afin qu'elles soient servies depuis n'importe quel cache HTTP ou CDN. Cela compte quand un seul serveur staple pour des millions de clients, et c'est ainsi qu'Evertrust PKI maintient une latence p99 basse sous des schémas de rafraîchissement de stapling à fort volume.
Visibilité unifiée sur la révocation via le CLM — révoquer un certificat dans Evertrust CLM met à jour le responder OCSP, la CRL et l'inventaire dans un même flux, avec la possibilité d'émettre et de déployer automatiquement un certificat de remplacement, afin que la révocation ne devienne pas une panne. Vous voyez ce qui a été révoqué, quand, pourquoi, et ce qui l'a remplacé — sur l'ensemble des CA que vous exploitez ou que vous consommez.