Procédure

Renouveler un certificat TLS sans interruption

Renouveler un certificat TLS en production avec inventaire SAN/chaîne/clé, validation hors ligne, installation parallèle, bascule contrôlée, test SNI et rollback immédiat.

⌚ Environ 6 min de lecture
Voir mes favoris
DomainePKI & CertificatsNiveauAvancéDurée45-120 minRisqueÉlevé

Objectif

Renouveler un certificat serveur TLS avant expiration sans interruption évitable, en validant le nouveau certificat et sa chaîne avant la bascule, en conservant l’ancien certificat pendant la période de sécurité et en testant réellement le certificat présenté pour chaque nom de domaine/SNI.

Prérequis

  • Inventaire des FQDN, VIP/load balancers, reverse proxies et serveurs qui présentent le certificat.
  • Nouveau certificat délivré avec chaîne intermédiaire et clé privée correspondante.
  • Ancien certificat encore valide pendant la fenêtre de migration.
  • Accès pour recharger/rebinder le service sans redémarrage complet lorsque la plateforme le permet.
  • Commande ou outil externe capable d’observer le certificat présenté après bascule.

Procédure pas à pas

1

Inventorier le certificat actuellement présenté

Interrogez le service depuis un client externe et relevez sujet, SAN, issuer, serial, dates et empreinte. Faites la même chose sur chaque nom SNI important. Cette référence permet d’identifier immédiatement si un nœud continue à servir l’ancien certificat après bascule.

openssl s_client -connect example.tld:443 -servername example.tld -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256
Résultat attendu
  • L’ancien certificat et ses dates sont documentés depuis le point de vue client.
2

Valider le nouveau certificat hors production

Inspectez le fichier reçu avant installation. Vérifiez NotBefore/NotAfter, SAN, issuer, fingerprint et usage. Contrôlez la chaîne fournie et assurez-vous que la clé privée correspond au certificat selon l’outil de votre plateforme. Ne corrigez pas un SAN manquant en espérant que le navigateur acceptera le CN.

openssl x509 -in new-cert.pem -noout -subject -issuer -serial -dates -fingerprint -sha256 -ext subjectAltName
openssl x509 -in new-cert.pem -noout -checkhost example.tld
Résultat attendu
  • Chaque FQDN de production prévu est couvert par le nouveau certificat.
3

Contrôler la chaîne de certification

Vérifiez que les certificats intermédiaires nécessaires sont disponibles dans le bon ordre ou le magasin adapté. Le serveur ne doit pas compter sur le client pour retrouver un intermédiaire manquant. Conservez la racine hors du bundle serveur sauf exigence spécifique du produit.

openssl verify -CAfile <CA-BUNDLE> -untrusted <INTERMEDIATE-BUNDLE> new-cert.pem
Résultat attendu
  • La chaîne peut être validée avec les autorités attendues.
4

Installer le nouveau certificat en parallèle

Importez le nouveau certificat et sa clé sans supprimer l’ancien. Sur les plateformes à magasin de certificats, les deux peuvent coexister avec des empreintes différentes ; sur les serveurs fichiers, placez le nouveau bundle avec des permissions strictes. Cette coexistence rend le rollback instantané.

Résultat attendu
  • Ancien et nouveau certificats restent disponibles pendant la fenêtre.
5

Préparer la bascule du binding

Identifiez précisément le virtual host, listener, VIP ou binding qui doit changer. Si un service supporte reload/reconfigure à chaud, utilisez-le plutôt qu’un redémarrage complet. Vérifiez la syntaxe avant reload. Dans un cluster, choisissez un nœud pilote ou retirez temporairement un nœud du load balancer.

Résultat attendu
  • La cible du changement est unique et le rollback consiste à réassocier l’ancienne empreinte/bundle.
6

Basculer un périmètre pilote

Associez le nouveau certificat au listener pilote et rechargez le service. Contrôlez immédiatement les logs de démarrage TLS. Si le service refuse la clé, la chaîne ou le format, revenez au binding précédent plutôt que de transformer simultanément les fichiers.

Résultat attendu
  • Le service reste disponible et présente le nouveau certificat sur le pilote.
7

Valider depuis l’extérieur avec SNI

Interrogez le FQDN depuis un poste qui passe par le même chemin que les utilisateurs. Vérifiez dates, fingerprint et chaîne. Testez une requête HTTP

openssl s_client -connect example.tld:443 -servername example.tld -verify_return_error </dev/null
curl -Iv https://example.tld/
Résultat attendu
  • Le client reçoit le nouveau certificat et l’application répond normalement.
8

Déployer sur les autres nœuds et noms

Répétez la bascule par nœud ou listener. Comparez les empreintes présentées en passant plusieurs fois par le load balancer si nécessaire. Pour plusieurs SNI, testez chaque nom ; un binding par défaut peut masquer une erreur qui ne touche qu’un domaine secondaire.

Résultat attendu
  • Tous les chemins de production présentent le certificat attendu.
9

Conserver l’ancien certificat puis le retirer

Gardez l’ancien certificat pendant une courte période de sécurité tant qu’aucun listener ne le référence. Une fois la supervision stable et tous les nœuds confirmés, retirez-le selon la politique de l’entreprise. Mettez à jour l’alerte d’expiration pour le prochain cycle et documentez l’autorité, le mode de renouvellement et le propriétaire.

Résultat attendu
  • Aucun binding ne dépend de l’ancien certificat et la prochaine expiration est supervisée.

Validation

La procédure est validée lorsque :

  • Le nouveau certificat couvre tous les FQDN/SAN attendus et possède une chaîne valide.
  • Chaque endpoint de production présente la nouvelle empreinte depuis un client externe.
  • L’application reste accessible et les logs TLS ne montrent pas d’erreur nouvelle.
  • L’ancien certificat reste disponible pendant la fenêtre de rollback puis est retiré après validation.

Retour arrière

  • Réassocier immédiatement l’ancien certificat au listener ou restaurer l’ancien bundle.
  • Recharger le service avec la configuration précédente validée.
  • Retirer un nœud défaillant du load balancer plutôt que d’interrompre tous les nœuds.
  • Conserver le nouveau certificat pour analyse de SAN, chaîne, clé ou format au lieu de le supprimer.

Dépannage / erreurs fréquentes

  • Certificat présenté inchangé : vérifier cache/CDN, autre nœud de cluster ou binding SNI non modifié.
  • Erreur private key mismatch : réimporter le certificat avec la clé correspondante et ne pas régénérer au hasard.
  • Chaîne incomplète : fournir les intermédiaires attendus dans le format de la plateforme.
  • Un domaine fonctionne et un autre échoue : contrôler SAN et binding SNI spécifique.
  • Service refuse le reload : valider syntaxe, permissions de clé et format PEM/PFX avant toute nouvelle bascule.

Références officielles

♡ 0