Cycle de vie et révocation

Cycle de vie et révocation des certificats

Un certificat passe par plusieurs étapes, de sa génération jusqu’à son expiration ou sa révocation. Comprendre ce cycle est indispensable pour éviter les coupures de service et les failles de sécurité.

Vue d’ensemble du cycle de vie

1. GÉNÉRATION          2. SOUMISSION         3. VALIDATION
   ──────────────          ──────────────        ──────────────
   Générer clé privée  →   Créer un CSR      →   CA vérifie
   (RSA/ECDSA)             (Certificate          (domaine / org
                            Signing Request)       / légal)
                                                       │
                                                       ▼
6. EXPIRATION          5. UTILISATION        4. ÉMISSION
   ──────────────          ──────────────        ──────────────
   Le certificat       ←   TLS, mTLS,       ←   CA signe le
   n'est plus valide       API auth…             certificat
   → renouveler
                                ↕
                         RÉVOCATION (anticipée)
                         Si clé compromise,
                         certificat invalide
                         → CRL / OCSP

Étape 1 — Générer la clé privée

# RSA 2048 bits (compatible universel)
openssl genrsa -out monservice.key 2048
 
# ECDSA P-256 (recommandé — plus rapide, plus compact)
openssl ecparam -name prime256v1 -genkey -noout -out monservice.key
 
# ECDSA P-384 (haute sécurité)
openssl ecparam -name secp384r1 -genkey -noout -out monservice.key
 
# Protéger la clé avec un mot de passe (pour stockage long terme)
openssl genrsa -aes256 -out monservice.key 2048
 
# Vérifier la clé générée
openssl pkey -in monservice.key -noout -text

La clé privée ne quitte jamais le serveur. Elle est générée sur place — jamais envoyée à la CA.

Étape 2 — Créer un CSR (Certificate Signing Request)

Le CSR est la “demande de certificat” envoyée à la CA. Il contient la clé publique et les informations d’identité.

# CSR simple
openssl req -new -key monservice.key -out monservice.csr \
  -subj "/CN=api.monentreprise.fr/O=Mon Entreprise/C=FR"
 
# CSR avec SAN (Subject Alternative Names) — recommandé
cat > san.conf << EOF
[req]
default_bits = 2048
prompt = no
distinguished_name = dn
req_extensions = req_ext
 
[dn]
CN = api.monentreprise.fr
O  = Mon Entreprise SAS
C  = FR
 
[req_ext]
subjectAltName = @alt_names
 
[alt_names]
DNS.1 = api.monentreprise.fr
DNS.2 = monentreprise.fr
DNS.3 = www.monentreprise.fr
EOF
 
openssl req -new -key monservice.key -out monservice.csr -config san.conf
 
# Vérifier le contenu du CSR
openssl req -in monservice.csr -noout -text

Étape 3 — Validation par la CA

La CA vérifie que le demandeur contrôle bien le domaine ou l’organisation déclarée. Le niveau de vérification dépend du type de certificat :

Type	Ce que la CA vérifie	Méthode
DV	Contrôle du domaine	Challenge HTTP, DNS ou email
OV	Domaine + existence légale de l’organisation	Documents + appel téléphonique
EV	Domaine + identité légale stricte + adresse physique	Audit approfondi

Pour DV (le cas Let’s Encrypt) → voir Let’s Encrypt et ACME.

Étape 4 — Émission et structure du certificat retourné

La CA retourne généralement :

Le certificat final (votre domaine)
Le certificat de la CA intermédiaire (à inclure dans la chaîne)

# Assembler la chaîne complète pour nginx/apache
cat monservice.crt ca-intermediaire.crt > fullchain.pem
 
# Configuration nginx
ssl_certificate     /etc/ssl/fullchain.pem;   # cert + chaîne
ssl_certificate_key /etc/ssl/monservice.key;  # clé privée
 
# Vérifier que la clé correspond bien au certificat
openssl x509 -noout -modulus -in monservice.crt | md5sum
openssl rsa  -noout -modulus -in monservice.key | md5sum
# → les deux hash doivent être identiques

Étape 5 — Renouvellement

Les certificats expirent. Le renouvellement doit se faire avant l’expiration pour éviter toute interruption de service.

Durée conseillée de renouvellement :
  Let's Encrypt (90j) → renouveler à 60j (30j de marge)
  Cert commercial (1 an) → renouveler à 11 mois
  PKI interne → selon la politique de l'entreprise

# Certbot (Let's Encrypt) — renouvellement automatique
certbot renew --dry-run    # tester sans renouveler
certbot renew              # renouveler tous les certs proches de l'expiration
 
# cert-manager (Kubernetes) — renouvellement automatique
# cert-manager surveille les Certificate objects et renouvelle 30j avant expiration
kubectl get certificates -A
kubectl describe certificate mon-cert -n mon-namespace

Alertes d’expiration :

# Vérifier l'expiration et alerter si < 30 jours
EXPIRY=$(openssl x509 -in cert.pem -noout -enddate | cut -d= -f2)
EXPIRY_TS=$(date -d "$EXPIRY" +%s)
NOW_TS=$(date +%s)
DAYS=$(( ($EXPIRY_TS - $NOW_TS) / 86400 ))
 
if [ $DAYS -lt 30 ]; then
  echo "ALERTE : certificat expire dans $DAYS jours !"
fi

Étape 6 — Révocation

La révocation annule un certificat avant sa date d’expiration. Cas déclencheurs :

Clé privée compromise ou volée
Employé ayant quitté l’entreprise
Mauvaise émission par la CA
Changement d’organisation

CRL — Certificate Revocation List

La CA publie périodiquement une liste signée de tous les numéros de série révoqués.

CA publie une CRL (ex: http://crl.digicert.com/sha2-ha-server-g6.crl)
  ↓
Client télécharge la CRL (mise en cache jusqu'au prochain update)
  ↓
Client cherche le serial number du certificat dans la CRL
  ↓
Trouvé → certificat révoqué ❌ / Non trouvé → valide ✅

Problèmes :
  - CRL peut être volumineuse (plusieurs Mo)
  - Mise à jour périodique → délai entre révocation et CRL mise à jour
  - Mise en cache par le client → fenêtre de compromission

OCSP — Online Certificate Status Protocol

OCSP permet de vérifier en temps réel le statut d’un seul certificat.

Client ──► POST http://ocsp.digicert.com
           { serialNumber: 04:D3:3B:6C:... }

OCSP Responder ──► { status: good | revoked | unknown
                     thisUpdate: 2026-04-05
                     nextUpdate: 2026-04-12 }

# Vérifier le statut OCSP d'un certificat
openssl ocsp \
  -issuer ca-intermediaire.crt \
  -cert monservice.crt \
  -url http://ocsp.digicert.com \
  -resp_text

OCSP Stapling — solution recommandée

Problème d’OCSP : le client fait une requête à la CA à chaque connexion → lent + vie privée.

Solution : OCSP Stapling — le serveur TLS précharge la réponse OCSP et l’inclut dans le handshake.

Sans Stapling :
  Client → Serveur : ClientHello
  Client → CA OCSP : vérification du cert (requête séparée, lente)
  Client → Serveur : données

Avec Stapling :
  Client → Serveur : ClientHello
  Serveur → Client : Certificate + réponse OCSP pré-chargée (stapled)
  [pas de requête CA séparée — plus rapide, plus privé]

# Activer OCSP Stapling dans nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/chain.pem;
resolver 8.8.8.8 1.1.1.1 valid=300s;

Comparatif CRL vs OCSP vs OCSP Stapling

	CRL	OCSP	OCSP Stapling
Fraîcheur	Différée (heures/jours)	Temps réel	Quasi temps réel (cache serveur)
Performance	Lent (gros fichier)	Moyen (requête CA)	Rapide (dans le handshake)
Vie privée	✅ (pas de trace)	❌ (CA sait qui consulte quoi)	✅ (pas de requête client)
Disponibilité	Mise en cache	Dépend de l’OCSP responder	Serveur gère le cache
Support	Universel	Universel	TLS 1.2+

En relation avec

Certificats — Vue d’ensemble — types et usages des certificats
X.509 — Format des certificats — le champ AIA contient l’URL OCSP
PKI — Infrastructure à Clés Publiques — la CA qui gère les CRL/OCSP
Let’s Encrypt et ACME — renouvellement automatique via ACME
cert-manager — automatise le cycle de vie dans Kubernetes

abla.adem

Recent Notes

Agents — Vue d'ensemble

Agents autonomes

Prompt Engineering — Vue d'ensemble

CARE

Explorer