Cycle de vie d’une autorité de certification intermédiaire

Dans une PKI (Public Key Infrastructure) à deux niveaux, l’autorité de certification (AC) intermédiaire est la pièce qui travaille : la racine reste hors ligne, l’intermédiaire signe les certificats de feuille au quotidien. Son cycle de vie décide de la disponibilité de tout ce qu’elle a émis, car une intermédiaire qui expire, change de clé ou est révoquée entraîne avec elle chaque certificat qui en dépend.

→ Lire l’explication complète de la marmotte

Émission de l’AC intermédiaire : cérémonie et extensions

L’émission se fait en cérémonie de clés : la paire de l’intermédiaire est générée dans un HSM (Hardware Security Module), la demande de certificat (CSR, Certificate Signing Request) est portée jusqu’à la racine hors ligne, signée sous quorum, et le procès-verbal consigne les empreintes. Générer la clé sur un poste puis « l’importer » annule la cérémonie.

Les extensions font la sécurité réelle du certificat :

basicConstraints=critical,CA:TRUE,pathlen:0 : l’intermédiaire signe des feuilles, jamais une autre AC. Sans pathlen:0, une clé d’intermédiaire volée fabrique des sous-autorités à volonté.
keyUsage=critical,keyCertSign,cRLSign et un extendedKeyUsage restreint (serverAuth, ou clientAuth pour une AC dédiée au mTLS, Transport Layer Security mutuel) : une intermédiaire par usage.
nameConstraints critique pour une PKI privée : l’AC n’émet que sous .exemple.test, seule extension qui borne les dégâts d’une compromission au lieu de les dater.
crlDistributionPoints pointant vers la liste de révocation (CRL, Certificate Revocation List) publiée par la racine, et authorityKeyIdentifier pour que les clients construisent le bon chemin.

La durée de vie se calcule à rebours. Une feuille ne survit pas à son émettrice : quand l’intermédiaire expire, la validation échoue pour toutes les feuilles, même récentes. Il faut donc fixer une date de fin d’émission égale à l’expiration de l’intermédiaire moins la durée maximale des feuilles. Avec des certificats web publics limités à 200 jours depuis mars 2026 (et moins ensuite, selon le calendrier du CA/Browser Forum), une intermédiaire de trois ans cesse d’émettre environ sept mois avant sa fin.

Renouvellement : même clé ou nouvelle clé

Le choix dépend d’une question : la clé actuelle a-t-elle encore une durée de vie et un historique d’exposition acceptables ?

Recertifier la même clé produit un nouveau certificat avec le même sujet et le même identifiant de clé (SKI, Subject Key Identifier). Les feuilles se valident avec l’un ou l’autre : transition indolore, mais la clé et son exposition cumulée vivent indéfiniment.

Changer de clé est la recommandation par défaut. Une nouvelle intermédiaire est émise, avec un nouvel identifiant ; l’ancienne cesse d’émettre mais reste valide et publiée jusqu’à l’expiration de sa dernière feuille. Pendant ce chevauchement, chaque serveur doit livrer l’intermédiaire de sa propre feuille. L’incident classique : un serveur mis à jour avec la nouvelle intermédiaire mais encore porteur d’une feuille signée par l’ancienne. Le client obtient une chaîne cassée et un message d’erreur rédigé pour décourager toute lecture ; la méthode est dans la page diagnostiquer les erreurs de validation TLS.

Avec des feuilles renouvelées automatiquement (ACME, Automatic Certificate Management Environment, ou EST, Enrollment over Secure Transport), basculer d’intermédiaire revient à changer l’émetteur en configuration.

Révocation en cascade : ce qui se propage, et ce qui ne se propage pas

Révoquer une intermédiaire, c’est inscrire son numéro de série dans la CRL de la racine. Pour un client qui vérifie chaque niveau, toutes ses feuilles tombent aussitôt, sans révocation individuelle : c’est la cascade.

Elle ne touche que les clients qui vérifient. Beaucoup de bibliothèques TLS embarquées, de clients mTLS et d’agents internes ne consultent aucune liste : pour eux, une intermédiaire révoquée reste parfaitement valide jusqu’à son expiration. Les navigateurs s’appuient plutôt sur des listes poussées par leur éditeur. Conséquence d’architecture : pour une PKI privée, la révocation d’une intermédiaire s’accompagne du retrait du certificat des magasins de confiance partout où il a été installé comme ancre, et de la réémission de toutes les feuilles sous une nouvelle intermédiaire. Sans inventaire des feuilles, c’est une chasse au trésor.

Deux pièges d’exploitation aggravent le tableau. La racine hors ligne doit signer la CRL : une compromission un vendredi soir exige un quorum de gardiens disponible, donc une procédure d’urgence écrite et répétée. Et la CRL de la racine a une date nextUpdate : si elle expire sans être republiée, chaque client qui vérifie la révocation rejette toute la PKI. Une racine sortie une fois par an produit cette panne avec la ponctualité d’un rappel de calendrier que personne n’a créé.

Exemple reproductible : émettre, vérifier et révoquer en cascade avec OpenSSL

Testé avec OpenSSL 3.x : une racine, une intermédiaire contrainte, une feuille, puis la révocation de l’intermédiaire.

# Racine (hors ligne en production) et intermédiaire contrainte
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-384 -out racine.key
openssl req -x509 -new -key racine.key -subj "/CN=Racine Test" -days 7300 \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" -out racine.crt
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out inter.key
openssl req -new -key inter.key -subj "/CN=Intermediaire TLS 2026" -out inter.csr
cat > inter.ext <<'EOF'
basicConstraints=critical,CA:TRUE,pathlen:0
keyUsage=critical,keyCertSign,cRLSign
extendedKeyUsage=serverAuth
nameConstraints=critical,permitted;DNS:.exemple.test
crlDistributionPoints=URI:http://pki.exemple.test/racine.crl
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid
EOF
openssl x509 -req -in inter.csr -CA racine.crt -CAkey racine.key -CAcreateserial \
  -days 1095 -extfile inter.ext -out inter.crt

# Feuille de 200 jours émise par l'intermédiaire
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out web.key
openssl req -new -key web.key -subj "/CN=www.exemple.test" -out web.csr
printf 'subjectAltName=DNS:www.exemple.test\nextendedKeyUsage=serverAuth\n' > web.ext
openssl x509 -req -in web.csr -CA inter.crt -CAkey inter.key -CAcreateserial \
  -days 200 -extfile web.ext -out web.crt

# Bases minimales pour que chaque AC publie sa CRL
for d in racine inter; do mkdir -p db-$d; : > db-$d/index.txt; echo 1000 > db-$d/crlnumber; done
cat > ca.cnf <<'EOF'
[ racine ]
database = db-racine/index.txt
crlnumber = db-racine/crlnumber
default_md = sha256
default_crl_days = 30
[ inter ]
database = db-inter/index.txt
crlnumber = db-inter/crlnumber
default_md = sha256
default_crl_days = 7
EOF
openssl ca -config ca.cnf -name inter -cert inter.crt -keyfile inter.key -gencrl -out inter.crl

# Révocation de l'intermédiaire par la racine, puis nouvelle CRL racine
openssl ca -config ca.cnf -name racine -cert racine.crt -keyfile racine.key \
  -revoke inter.crt -crl_reason keyCompromise
openssl ca -config ca.cnf -name racine -cert racine.crt -keyfile racine.key -gencrl -out racine.crl

# Client qui vérifie chaque niveau : "certificate revoked" à la profondeur 1
cat racine.crt racine.crl inter.crl > ancre-et-crl.pem
openssl verify -crl_check_all -CAfile ancre-et-crl.pem -untrusted inter.crt web.crt
# Client qui ne vérifie rien : la même feuille est toujours "OK"
openssl verify -CAfile racine.crt -untrusted inter.crt web.crt

Ce que le cycle de vie ne garantit pas, et l’exploitation

Une intermédiaire bien gérée ne garantit ni l’absence d’émission abusive par un opérateur légitime, ni la révocation chez les clients silencieux, ni la sécurité de la racine. Le journal d’émission (et la transparence des certificats pour le web public) couvre le premier point, l’inventaire des comportements de validation le second. La page PKI expliquée situe ces briques les unes par rapport aux autres.

En exploitation : superviser trois échéances (expiration, fin d’émission, nextUpdate de chaque CRL), sauvegarder la clé chiffrée vers le HSM de secours, répéter chaque année restauration et révocation complète en recette, et tenir la liste des magasins de confiance où l’intermédiaire est épinglée.

🐝 Ce qui arrive si on s’en passe

Sans gestion du cycle de vie de l’intermédiaire, sa clé reste en service aussi longtemps que son certificat, souvent plusieurs années, et son exposition s’accumule sans être mesurée. Si cette clé fuit, un attaquant peut émettre des certificats acceptés par tous les clients qui font confiance à la racine, et aucun mécanisme préparé ne permet de les invalider : ni liste de révocation publiée, ni intermédiaire de remplacement, ni liste des feuilles à réémettre. En l’absence de journal d’émission, il devient en outre impossible de distinguer les certificats légitimes de ceux fabriqués par l’attaquant.

🦫 Explication de la marmotte 🍫

Un certificat est une carte d’identité numérique pour un site ou un service. Il est signé par une autorité. L’autorité principale, appelée racine, reste débranchée et signe seulement quelques autorités intermédiaires, qui signent les certificats de tous les jours.

Créer une intermédiaire se fait lors d’une réunion encadrée : sa clé secrète naît dans un boîtier qui la protège, plusieurs personnes doivent être présentes pour que la racine la signe, et on inscrit dans son certificat des limites, comme les noms de sites qu’elle a le droit de signer et l’interdiction de créer d’autres autorités.

Une intermédiaire a une date de fin. Un certificat qu’elle signe cesse de fonctionner quand elle expire, donc elle doit arrêter de signer quelques mois avant. Pour la remplacer, on crée une nouvelle intermédiaire avec une nouvelle clé, et les deux cohabitent le temps que les anciens certificats expirent.

Si la clé est volée, la racine publie une liste qui déclare l’intermédiaire annulée. Les programmes qui lisent cette liste rejettent alors tous les certificats qu’elle a signés. Ceux qui ne la lisent pas continuent à les accepter : il faut donc aussi retirer l’intermédiaire de leur liste de confiance et refaire tous les certificats.

Pages voisines

La citent

Cycle de vie d'une autorité de certification intermédiaire

Elle cite

: les deux pages se citent l’une l’autre.