Révocation des certificats
Portail > Cycle de vie
La révocation invalide un certificat avant son expiration, par exemple en cas de compromission de la clé privée. Comme un certificat est auto-porteur, il faut un canal externe pour signaler qu'il ne doit plus être accepté : c'est le rôle des CRL et d'OCSP.
Pourquoi révoquer
- Compromission ou suspicion de compromission de la clé privée.
- Erreur d'émission, informations devenues fausses.
- Départ d'un titulaire, déclassement d'un service.
- Compromission d'une CA (révocation de l'intermédiaire → toute sa descendance tombe).
Des codes de raison standard accompagnent la révocation (keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation…).
CRL (Certificate Revocation List)
Une CRL est une liste, signée par la CA, des numéros de série révoqués, avec date et raison. Le certificat indique où la trouver via l'extension CRL Distribution Points (CDP).
- + simple, vérifiable hors ligne une fois téléchargée.
- − peut devenir volumineuse ; fraîcheur limitée par la périodicité de publication.
openssl crl -in ca.crl -noout -text # lire une CRL openssl x509 -in cert.pem -noout -text | grep -A2 "CRL Distribution"
OCSP (Online Certificate Status Protocol)
OCSP interroge en temps réel un répondeur (URL fournie par l'AIA) sur l'état d'un certificat précis ; la réponse (good / revoked / unknown) est signée par la CA ou un répondeur délégué.
- + réponse ciblée et plus fraîche qu'une CRL.
- − dépendance à la disponibilité du répondeur ; questions de performance et de vie privée (le répondeur voit quels sites sont visités).
OCSP Stapling
Avec le stapling, c'est le serveur qui interroge périodiquement le répondeur OCSP et joint (staple) la réponse signée et horodatée directement dans la poignée de main TLS. Le client n'a plus à contacter la CA.
- + meilleures performances, respect de la vie privée du client, robustesse.
- C'est l'approche recommandée pour TLS serveur.
# Voir si un serveur agrafe une réponse OCSP openssl s_client -connect clipsy.tech:443 -servername clipsy.tech -status </dev/null \ | grep -A2 "OCSP Response Status"
Soft-fail vs hard-fail
Que faire quand l'état de révocation est indisponible (répondeur injoignable, CRL non téléchargeable) ?
- Soft-fail : on accepte malgré tout. Évite les pannes mais affaiblit la sécurité (un attaquant peut bloquer la vérification). Comportement par défaut de nombreux navigateurs.
- Hard-fail : on rejette. Plus sûr mais fragile face à une indisponibilité du répondeur.
Ce compromis explique pourquoi la révocation est jugée imparfaite en pratique.
Certificats à durée courte : l'alternative
La tendance est de réduire la dépendance à la révocation en raccourcissant fortement la validité (durées courtes) : un certificat de 90 jours (ou moins) limite intrinsèquement la fenêtre d'exposition, rendant la révocation moins critique. C'est complémentaire, pas un remplacement total.
Points clés à retenir
- La révocation invalide un certificat avant échéance ; le signalement passe par un canal externe.
- CRL = liste signée (via CDP) ; OCSP = interrogation temps réel (via AIA) ; OCSP stapling = le serveur agrafe la réponse (recommandé).
- soft-fail (accepte si indisponible) vs hard-fail (rejette) : compromis disponibilité/sécurité.
- Les durées courtes réduisent la dépendance à la révocation.
Voir aussi
| Chaînes de certificats — Portail | |
|---|---|
| Fondamentaux | Cryptographie asymétrique · Signatures et hachage |
| Certificat X.509 | Structure X.509 · Extensions X.509 · Formats et encodage |
| PKI et autorités | PKI · Autorités de certification · Ancres de confiance |
| Chaîne | Principe · Construction du chemin · Validation · Contraintes de chemin |
| Cycle de vie | CSR et émission · Cycle de vie · Révocation |
| Avancé | Cross-signing · Dépannage |