Cycle de vie d'un certificat

Portail > Cycle de vie

Un certificat n'est pas un objet permanent : il naît, sert pendant une période bornée, puis doit être renouvelé ou disparaître. Maîtriser ce cycle évite la principale panne d'exploitation liée aux certificats : l'expiration non anticipée.

Les phases

1. Génération de la clé : création de la paire de clés du titulaire.
2. Demande : production d'une CSR.
3. Émission : signature par la CA.
4. Déploiement : installation du certificat et de sa chaîne sur le service (et de la clé privée).
5. Utilisation : le certificat sert (TLS, mTLS, signature…).
6. Surveillance : suivi de l'échéance et de l'état de révocation.
7. Renouvellement : émission d'un nouveau certificat avant expiration.
8. Fin de vie : expiration naturelle ou révocation anticipée.

<mermaid> flowchart LR

   G[Génération clé] --> C[CSR]
   C --> E[Émission]
   E --> D[Déploiement]
   D --> U[Utilisation]
   U --> S[Surveillance]
   S -->|approche échéance| R[Renouvellement]
   R --> D
   S -->|compromission| RV[Révocation]
   U -->|notAfter atteint| X[Expiration]

</mermaid>

(Schéma en Mermaid.)

Durées de validité

La tendance est à des durées courtes : les certificats serveurs publics sont passés de plusieurs années à ~1 an, puis vers des durées encore plus brèves (90 jours type ACME, et des projets de réduction supplémentaire). Avantages : fenêtre d'exposition réduite en cas de compromission, dépendance moindre à la révocation. Contrepartie : le renouvellement doit être automatisé.

Renouvellement

• Anticiper : renouveler bien avant notAfter (typiquement à 2/3 de la durée de vie).
• Nouvelle clé recommandée (rekey) à chaque renouvellement pour limiter l'usure d'une clé ; à défaut, au moins périodiquement.
• Redéployer la chaîne : un renouvellement peut changer l'intermédiaire signataire → revérifier le fullchain servi (Construction du chemin de certification).
• Recharger le service : beaucoup de services ne relisent pas le certificat à chaud → prévoir un rechargement/redémarrage.

Surveillance

• Alerter sur l'échéance (J-30, J-7…) de tous les certificats, y compris les intermédiaires et la racine : l'expiration d'une CA invalide d'un coup toute sa descendance.
• Surveiller aussi les certificats internes (mTLS, composants, équipements) souvent oubliés.
• Vérifier la chaîne effectivement présentée après chaque rotation.

# Échéance d'un certificat
openssl x509 -in cert.pem -noout -enddate

# Échéance vue depuis le réseau
echo | openssl s_client -connect clipsy.tech:443 -servername clipsy.tech 2>/dev/null \
  | openssl x509 -noout -enddate

Automatisation (contexte Kubernetes / RKE2)

• cert-manager gère émission et renouvellement automatiques ; un Certificate est renouvelé avant échéance et le Secret mis à jour.
• Penser aux composants qui consomment ces secrets : un service qui ne recharge pas, ou un secret répliqué (ESO), peut continuer à servir un ancien certificat ou échouer si une CA interne a expiré.
• Les PKI internes (RKE2, Vault) ont leurs propres échéances de CA : à inventorier et surveiller au même titre que les certificats applicatifs.

Points clés à retenir

• Le cycle : clé → CSR → émission → déploiement → usage → surveillance → renouvellement / fin de vie.
• Durées courtes = sécurité accrue mais renouvellement à automatiser.
• Renouveler tôt, redéployer la chaîne, recharger le service.
• Surveiller toutes les échéances, intermédiaires et CA internes compris.

Voir aussi

• CSR et émission d'un certificat
• Révocation des certificats
• Construction du chemin de certification
• Dépannage des chaînes de certificats