Rotation et renouvellement automatisés

Portail > Mise en œuvre et exploitation

L'expiration non anticipée est la première cause de panne liée aux certificats. L'automatisation du renouvellement et le rechargement à chaud des services rendent ces pannes évitables.

Les trois temps

1. Renouveler avant échéance (émission d'un nouveau certificat, idéalement avec nouvelle clé).
2. Propager le nouveau certificat là où il est consommé (Secret, fichier, magasin).
3. Recharger le service pour qu'il serve le nouveau certificat sans interruption.

Un maillon oublié (souvent le rechargement, ou la propagation) fait que l'ancien certificat reste servi jusqu'à l'incident.

Renouveler

• cert-manager : renewBefore déclenche le renouvellement, rotationPolicy: Always change la clé (cert-manager).
• ACME / step-ca : renouvellement périodique automatique.
• Vault PKI : TTL courts, ré-émission à la demande (Vault PKI).
• Règle simple : renouveler à 2/3 de la durée de vie pour absorber les pannes.

Propager

• Kubernetes : le Secret est mis à jour en place par cert-manager.
• External Secrets Operator : attention à la fraîcheur — un secret source renouvelé doit être re-synchronisé en aval ; surveiller l'âge du secret répliqué et la validité de la CA émettrice.
• Distribution de bundles de CA (trust-manager) pour mettre à jour les magasins de confiance des charges.

Recharger à chaud

Mécanisme	Exemple
Signal de rechargement	nginx -s reload, SIGHUP ; recharge le certificat sans couper.
Surveillance de fichier	Le service détecte la modification du certificat (fsnotify) et recharge.
Reloader (Kubernetes)	Redémarre/roule les pods quand le Secret change.
Rechargement applicatif	L'application relit périodiquement son certificat.

Objectif : zéro interruption — recharger sans casser les connexions en cours.

Cas particulier : rotation de CA

Renouveler une CA est plus délicat qu'une feuille : sa nouvelle version doit être déployée dans les magasins avant que les feuilles ne s'y rattachent. Le cross-signing permet de chevaucher ancienne et nouvelle racine pendant la transition.

Surveillance

• Alerter sur l'échéance de tous les certificats, CA internes comprises (RKE2, Vault, mesh).
• Vérifier la chaîne réellement servie après chaque rotation (Dépannage des chaînes de certificats).
• Tableaux de bord d'expiration ; sondes synthétiques sur les endpoints critiques.

# Échéance vue du réseau (à scripter en sonde)
echo | openssl s_client -connect clipsy.tech:443 -servername clipsy.tech 2>/dev/null \
  | openssl x509 -noout -enddate

Points clés à retenir

• Renouveler + propager + recharger : les trois doivent être automatisés.
• Surveiller la fraîcheur des Secrets répliqués (ESO) et la validité des CA internes.
• Recharger à chaud pour zéro interruption.
• Rotation de CA : déployer la nouvelle racine d'abord, chevaucher via cross-signing.

Voir aussi

• cert-manager
• Cycle de vie d'un certificat
• Certification croisée et cross-signing
• Dépannage des chaînes de certificats