Sauvegarde et restauration de certificats TLS avec exemples pratiques

Introduction

Une défaillance d'un certificat TLS peut mettre un service de production hors ligne en quelques secondes. La cause peut être un certificat feuille expiré, une autorité de certification intermédiaire manquante, une chaîne révoquée, ou un renouvellement raté qui a remplacé un certificat valide par un fichier illisible. La récupération dépend de la disponibilité d'une sauvegarde récente, d'une procédure de restauration testée, et d'un moyen de prouver que le service est sain avant de déclarer l'incident terminé.

Cet article fournit un flux de travail pratique pour sauvegarder, restaurer, valider et revenir en arrière sur des certificats TLS. Il s'adresse aux développeurs, ingénieurs DevOps et équipes techniques de startups qui gèrent des certificats sur des serveurs Linux, Nginx et des Ingress Kubernetes. Chaque étape comprend des commandes concrètes, les sorties attendues et les signaux d'échec. L'objectif est la sécurité opérationnelle : observer avant de changer, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat, et documenter comment récupérer si l'état attendu n'est pas atteint.

Si vous copiez une commande sans vérifier les prérequis et la sortie attendue, vous ne suivez pas une procédure d'exploitation. Chaque commande de cet article est limitée à un composant, et chaque intervention comprend une étape de vérification. Lorsqu'un retour en arrière est possible, la procédure est décrite avant que le changement ne soit effectué.

Inventaire des versions et de l'environnement

Avant de sauvegarder ou restaurer un certificat, vous devez savoir avec quoi vous travaillez. Inventoriez les fichiers de certificats, les services qui les utilisent, le système d'exploitation et la version d'OpenSSL, et la fenêtre de validité actuelle. Cette section montre comment collecter ces informations sans rien modifier.

Commencez par identifier les fichiers de certificats sur le disque. Sur un serveur Debian ou Ubuntu typique, les certificats sont stockés dans /etc/ssl/certs/ et les clés privées dans /etc/ssl/private/. Sur CentOS ou RHEL, les chemins sont /etc/pki/tls/certs/ et /etc/pki/tls/private/. Nginx référence généralement les certificats depuis /etc/nginx/ssl/ ou un répertoire personnalisé similaire. Si vous utilisez Kubernetes, les certificats sont souvent stockés comme des Secrets TLS dans le cluster, pas comme des fichiers sur le nœud.

Pour trouver tous les fichiers de certificats sur un hôte Linux, vous pouvez utiliser la commande find pour lister les fichiers se terminant par .pem ou .crt :

find /etc/ssl /etc/nginx /etc/pki -type f \( -name "*.pem" -o -name "*.crt" \) 2>/dev/null

Cette commande peut renvoyer une longue liste. Affinez en vérifiant quel certificat est réellement utilisé par un service en cours d'exécution. Pour Nginx, inspectez la configuration :

nginx -T 2>/dev/null | grep -E "ssl_certificate|ssl_certificate_key"

Exemple de sortie :

ssl_certificate /etc/nginx/ssl/example.com.pem;
ssl_certificate_key /etc/nginx/ssl/example.com.key;

Vous connaissez maintenant le chemin exact du certificat et de la clé. Enregistrez la version d'OpenSSL pour garantir la compatibilité avec vos commandes :

openssl version

Exemple de sortie :

OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

Ensuite, inspectez le certificat sans rien modifier. La commande suivante affiche le sujet, l'émetteur, le numéro de série, les dates de validité et l'empreinte SHA-256 :

openssl x509 -in /etc/nginx/ssl/example.com.pem -noout -subject -issuer -serial -dates -fingerprint -sha256

Exemple de sortie :

subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R3
serial=04F7E2A1B3C4D5E6F7A8B9C0D1E2F3A4B5C6
notBefore=Mar  1 12:00:00 2025 GMT
notAfter=May 30 12:00:00 2025 GMT
SHA256 Fingerprint=AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23

Enregistrez l'empreinte et les dates de validité dans votre inventaire. Vous en aurez besoin plus tard pour vérifier qu'un certificat restauré est bien celui que vous vouliez.

Si le certificat est servi par un point de terminaison distant, vous pouvez le tester sans toucher le serveur :

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256

La sortie est similaire à l'inspection locale, mais elle reflète le certificat en direct. Comparez les deux empreintes. Si elles correspondent, le fichier local et le certificat servi sont identiques. Si elles ne correspondent pas, le service en cours d'exécution n'utilise pas le fichier que vous avez inspecté, peut-être parce qu'il n'a pas été rechargé ou parce qu'un autre bloc de configuration est actif.

Les utilisateurs de Kubernetes peuvent inspecter un Secret TLS avec kubectl :

kubectl get secret example-tls -n default -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256

Le nom et l'espace de noms du Secret sont des exemples ; remplacez-les par les vôtres. Les données du certificat sont encodées en base64 dans le Secret, vous devez donc les décoder avant de les passer à OpenSSL.

Enfin, validez la chaîne de certificats hors ligne pour vous assurer que le certificat feuille est approuvé par un paquet d'autorités de certification :

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -untrusted /etc/nginx/ssl/intermediate.pem /etc/nginx/ssl/example.com.pem

Sortie attendue si la chaîne est valide :

/etc/nginx/ssl/example.com.pem: OK

Si la sortie affiche une erreur telle que "unable to get local issuer certificate" (impossible d'obtenir le certificat de l'émetteur local) ou "certificate has expired" (certificat expiré), la chaîne est cassée ou le certificat est expiré. Corrigez ces problèmes avant de procéder à la sauvegarde ; une sauvegarde d'un certificat cassé n'est pas utile pour la récupération.

Chemin de configuration sûr

Sauvegarder un certificat TLS ne consiste pas seulement à copier des fichiers. Il s'agit de créer un instantané récupérable qui inclut le certificat, la clé privée et la configuration exacte qui les utilise. La clé privée doit être protégée au repos et en transit. Cette section montre un chemin sûr pour créer et stocker des sauvegardes.

Supposons que vous ayez identifié le certificat à /etc/nginx/ssl/example.com.pem et la clé privée à /etc/nginx/ssl/example.com.key. Avant d'apporter des modifications, créez un répertoire de sauvegarde horodaté :

BACKUP_DIR="/var/backups/tls/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"

Copiez le certificat et la clé dans le répertoire de sauvegarde avec des permissions restrictives :

cp /etc/nginx/ssl/example.com.pem "$BACKUP_DIR/"
cp /etc/nginx/ssl/example.com.key "$BACKUP_DIR/"
chmod 600 "$BACKUP_DIR/example.com.key"
chmod 644 "$BACKUP_DIR/example.com.pem"

La clé privée ne doit jamais être lisible par tous. Le certificat lui-même est une information publique et peut avoir des permissions plus souples.

En outre, sauvegardez la configuration Nginx qui référence ces fichiers, car une restauration peut nécessiter de revenir aussi sur les changements de configuration :

cp /etc/nginx/sites-available/example.com.conf "$BACKUP_DIR/"

Si vous utilisez un outil de gestion de configuration comme Ansible, Puppet ou Chef, la configuration est déjà versionnée dans votre dépôt. Dans ce cas, enregistrez le hachage de commit ou la version.

Créez maintenant un manifeste qui enregistre le contenu de la sauvegarde et les métadonnées du certificat pour une vérification ultérieure :

{
  echo "Sauvegarde créée : $(date)"
  echo "Hôte : $(hostname)"
  echo "Fichier certificat : example.com.pem"
  echo "Fichier clé : example.com.key"
  echo "Fichier config : example.com.conf"
  openssl x509 -in "$BACKUP_DIR/example.com.pem" -noout -subject -issuer -serial -dates -fingerprint -sha256
} > "$BACKUP_DIR/MANIFEST.txt"

Exemple de MANIFEST.txt :

Sauvegarde créée : Mon Mar 10 10:00:00 UTC 2025
Hôte : web1
Fichier certificat : example.com.pem
Fichier clé : example.com.key
Fichier config : example.com.conf
subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R3
serial=04F7E2A1B3C4D5E6F7A8B9C0D1E2F3A4B5C6
notBefore=Mar  1 12:00:00 2025 GMT
notAfter=May 30 12:00:00 2025 GMT
SHA256 Fingerprint=AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23

Stockez la sauvegarde en toute sécurité. Si possible, chiffrez la sauvegarde de la clé privée avec une phrase de passe en utilisant GPG ou OpenSSL. Par exemple, pour chiffrer le fichier de clé avec OpenSSL en utilisant AES-256-CBC :

openssl enc -aes-256-cbc -salt -in "$BACKUP_DIR/example.com.key" -out "$BACKUP_DIR/example.com.key.enc"

Il vous sera demandé une phrase de passe. Stockez le fichier chiffré hors du serveur, par exemple dans un compartiment de stockage d'objets sécurisé ou un gestionnaire de secrets. Le fichier de clé d'origine sur le serveur reste inchangé ; vous pouvez éventuellement supprimer la copie non chiffrée du répertoire de sauvegarde après le chiffrement.

Pour Kubernetes, sauvegardez un Secret TLS avec kubectl dans un fichier YAML :

kubectl get secret example-tls -n default -o yaml > "$BACKUP_DIR/example-tls.yaml"

Ce YAML contient le certificat et la clé encodés en base64. Traitez-le comme sensible. Chiffrez-le avant de le stocker hors cluster.

Testez la sauvegarde en la restaurant dans un emplacement temporaire et en comparant l'empreinte du certificat avec le manifeste :

mkdir -p /tmp/tls-restore-test
cp "$BACKUP_DIR/example.com.pem" /tmp/tls-restore-test/
cp "$BACKUP_DIR/example.com.key" /tmp/tls-restore-test/
openssl x509 -in /tmp/tls-restore-test/example.com.pem -noout -fingerprint -sha256 | diff - <(grep "SHA256 Fingerprint" "$BACKUP_DIR/MANIFEST.txt")

Si diff ne produit aucune sortie, la sauvegarde est intacte. Supprimez le répertoire de test ensuite.

Vérification et diagnostics

Après la restauration d'un certificat, vous devez vérifier que le service sert le bon certificat et que les clients peuvent valider la chaîne. Cette section fournit une séquence de vérifications qui vont de l'inspection locale des fichiers au test du point de terminaison distant, puis à la surveillance automatisée.

Tout d'abord, comparez l'empreinte du certificat restauré avec l'empreinte attendue de votre manifeste de sauvegarde :

openssl x509 -in /etc/nginx/ssl/example.com.pem -noout -fingerprint -sha256

La sortie attendue doit correspondre à l'empreinte enregistrée dans MANIFEST.txt. Si ce n'est pas le cas, vous avez restauré le mauvais fichier ou le fichier est corrompu.

Ensuite, vérifiez les dates de validité :

openssl x509 -in /etc/nginx/ssl/example.com.pem -noout -dates

Assurez-vous que notBefore est dans le passé et notAfter dans le futur. Si le certificat est expiré ou pas encore valide, Nginx échouera à démarrer ou servira des erreurs.

Testez la configuration Nginx pour des erreurs de syntaxe avant de recharger :

nginx -t

Sortie attendue :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

S'il y a une erreur, Nginx ne rechargera pas. Corrigez la configuration avant de continuer.

Rechargez Nginx pour appliquer le certificat restauré :

systemctl reload nginx

Testez maintenant le point de terminaison en direct. Utilisez openssl s_client pour vous connecter et afficher le certificat servi :

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -fingerprint -sha256

Comparez l'empreinte avec celle attendue. Si la poignée de main échoue, s_client affichera une erreur telle que "unable to get local issuer certificate" (impossible d'obtenir le certificat de l'émetteur local) ou "certificate verify failed" (échec de la vérification du certificat).

Pour vérifier la chaîne telle que vue par les clients, utilisez l'option -showcerts et comptez le nombre de certificats renvoyés :

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c "BEGIN CERTIFICATE"

Typiquement, cela renvoie 2 ou 3 : le certificat feuille et un ou plusieurs intermédiaires. Si cela renvoie seulement 1, le serveur n'envoie pas l'intermédiaire, ce qui provoque des erreurs de confiance pour certains clients.

Pour une vérification plus approfondie, utilisez la commande openssl verify avec le paquet d'autorités de certification :

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{print}' > /tmp/chain.pem
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -untrusted /tmp/chain.pem /tmp/chain.pem

Ce n'est pas toujours précis car la sortie de s_client peut inclure des certificats supplémentaires. Une meilleure approche consiste à utiliser un outil dédié comme testssl.sh ou un vérificateur SSL en ligne pour une vue externe.

Mettez en place une surveillance automatisée pour détecter l'expiration du certificat avant qu'elle ne cause une interruption. Un simple travail cron peut vérifier le nombre de jours de validité restants et envoyer une alerte :

#!/bin/bash
CERT=/etc/nginx/ssl/example.com.pem
DAYS_LEFT=$(openssl x509 -in "$CERT" -checkend $((30*24*3600)) -noout && echo yes || echo no)
if [ "$DAYS_LEFT" = "no" ]; then
  echo "Le certificat $CERT expire dans moins de 30 jours" | mail -s "Alerte d'expiration TLS" [email protected]
fi

Enregistrez ce script sous /usr/local/bin/check_cert.sh, rendez-le exécutable, et ajoutez une entrée cron :

0 8 * * * /usr/local/bin/check_cert.sh

Cela s'exécute tous les jours à 8 h, heure du serveur.

Modes de défaillance et récupération

Les défaillances de certificats ont plusieurs modes distincts. Chacun nécessite une procédure de récupération spécifique. Cette section décrit les défaillances les plus courantes, comment les détecter et comment récupérer en utilisant les sauvegardes que vous avez créées précédemment.

Certificat expiré : La date notAfter est passée. Les clients voient "ERR_CERT_DATE_INVALID" dans les navigateurs ou des échecs de connexion dans les applications. Détection : exécutez la vérification de date décrite ci-dessus. Récupération : remplacez le certificat par un certificat valide. Si vous avez une sauvegarde récente encore valide, restaurez-la. Sinon, obtenez un nouveau certificat auprès de votre autorité de certification ou renouvelez avec Let's Encrypt. Après le remplacement, rechargez le service et vérifiez les dates du certificat en direct.

Chaîne de certificats incomplète : Le serveur n'envoie pas le certificat intermédiaire. Les navigateurs peuvent fonctionner s'ils mettent en cache les intermédiaires, mais d'autres clients échouent avec "unable to get local issuer certificate" (impossible d'obtenir le certificat de l'émetteur local). Détection : s_client -showcerts ne renvoie qu'un seul certificat alors que deux ou plus sont attendus. Récupération : obtenez le certificat intermédiaire auprès de votre autorité de certification et configurez le serveur pour l'envoyer. Pour Nginx, concaténez le certificat feuille et l'intermédiaire dans un seul fichier, avec le certificat feuille en premier :

cat example.com.pem intermediate.pem > fullchain.pem

Mettez ensuite à jour la directive ssl_certificate pour pointer vers fullchain.pem et rechargez Nginx. Vérifiez avec s_client -showcerts.

Inadéquation de la clé privée : Le certificat et la clé ne correspondent pas. Nginx échoue à démarrer ou à recharger, en journalisant une erreur comme "SSL_CTX_use_PrivateKey_file: key values mismatch" (inadéquation des valeurs de clé). Détection : comparez le module du certificat et de la clé :

openssl x509 -in example.com.pem -noout -modulus | openssl md5
openssl rsa -in example.com.key -noout -modulus | openssl md5

Si les hachages MD5 diffèrent, la clé ne correspond pas au certificat. Récupération : restaurez la clé correcte depuis la sauvegarde, ou créez une nouvelle clé et obtenez un nouveau certificat.

Fichiers corrompus : Le fichier de certificat ou de clé est illisible ou contient des données invalides. Détection : les commandes openssl échouent avec des erreurs d'analyse. Récupération : restaurez depuis la sauvegarde et vérifiez l'empreinte.

Suppression accidentelle : Le certificat, la clé ou le fichier de configuration est supprimé. Détection : le service échoue à démarrer, ou le fichier est manquant. Récupération : restaurez depuis la sauvegarde.

Permissions mal configurées : La clé privée a des permissions trop permissives (par exemple, lisible par tous). Détection : ls -l affiche des permissions comme -rw-r--r--. Récupération : définissez les permissions à 600 et le propriétaire à root :

chmod 600 /etc/nginx/ssl/example.com.key
chown root:root /etc/nginx/ssl/example.com.key

Certificat révoqué : L'autorité de certification a révoqué le certificat. Les clients voient des erreurs selon la vérification de révocation. Détection : utilisez openssl verify avec une CRL ou OCSP. Récupération : obtenez un nouveau certificat.

Pour chaque défaillance, la procédure de retour en arrière consiste à restaurer le certificat et la clé précédents connus comme bons depuis la sauvegarde, recharger le service et vérifier le point de terminaison en direct. Testez toujours la procédure de retour en arrière dans un environnement de préproduction avant d'en avoir besoin en production.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant, pendant et après tout changement de certificat. Elle résume les étapes clés et attribue un propriétaire unique pour chaque décision ou action. Les propriétaires sont des rôles illustratifs ; remplacez-les par la personne réelle de votre équipe. Chaque élément doit être examiné au moins mensuellement, ou immédiatement après tout incident.

Pour Kubernetes, adaptez la liste de contrôle :

• Sauvegardez les Secrets TLS avec kubectl get secret -o yaml et chiffrez la sortie.
• Avant d'appliquer un nouveau Secret, validez le certificat et la clé localement.
• Après l'application, vérifiez que l'Ingress sert le bon certificat en utilisant openssl s_client contre le point de terminaison de l'Ingress.
• Utilisez cert-manager ou un outil similaire pour automatiser l'émission et le renouvellement, et surveillez l'expiration des certificats avec des alertes Prometheus.

Pièges courants et comment les éviter

De nombreux incidents de certificats sont causés par des erreurs évitables. Voici les pièges les plus courants dans la sauvegarde et la restauration TLS, pourquoi ils surviennent et comment les prévenir ou s'en remettre.

Piège 1 : Sauvegarder uniquement le certificat, pas la clé privée. Un certificat est inutile sans sa clé correspondante. Cela arrive lorsque les opérateurs supposent que la clé est statique ou stockée ailleurs. Comment éviter : sauvegardez toujours la clé avec le certificat, et vérifiez qu'ils correspondent en comparant les hachages MD5 des modules. Récupération : si la clé est perdue, vous devez générer une nouvelle clé et obtenir un nouveau certificat.

Piège 2 : Ne pas tester les sauvegardes. Une sauvegarde qui ne peut pas être restaurée n'est pas une sauvegarde. Les opérateurs créent souvent des sauvegardes mais ne pratiquent jamais la restauration. Comment éviter : planifiez un test de restauration mensuel vers un emplacement temporaire. Récupération : si la sauvegarde s'avère corrompue pendant un incident, il n'y a pas de remède ; vous devez obtenir un nouveau certificat immédiatement.

Piège 3 : Écraser un certificat valide par un certificat invalide. Cela arrive lors d'un renouvellement automatisé lorsqu'un script remplace les fichiers sans vérifier la validité. Comment éviter : validez le nouveau certificat avant de remplacer l'ancien, et gardez l'ancien certificat jusqu'à ce que le nouveau soit confirmé fonctionnel. Récupération : restaurez l'ancien certificat depuis la sauvegarde.

Piège 4 : Ne pas envoyer la chaîne complète. Certains serveurs sont configurés avec seulement le certificat feuille, ce qui provoque des erreurs de confiance pour certains clients. Cela arrive lorsque l'intermédiaire n'est pas concaténé. Comment éviter : utilisez un fichier fullchain.pem qui contient le certificat feuille et les intermédiaires. Récupération : créez la chaîne complète et mettez à jour la configuration.

Piège 5 : Ignorer les permissions des fichiers. Les clés privées avec des permissions trop permissives peuvent être lues par d'autres utilisateurs, menant à une compromission. Cela arrive lors de la copie de fichiers sans définir les permissions. Comment éviter : toujours utiliser chmod 600 sur les clés privées. Récupération : changez immédiatement les permissions et considérez la clé comme compromise ; faites une rotation si nécessaire.

Piège 6 : Ne pas surveiller l'expiration. Le suivi manuel de l'expiration des certificats n'est pas fiable. Cela arrive lorsqu'il n'y a pas d'alerte automatisée. Comment éviter : mettez en place un travail cron ou un système de surveillance pour vérifier l'expiration et alerter à 30, 14 et 7 jours avant l'expiration. Récupération : si elle expire, restaurez depuis la sauvegarde ou obtenez un nouveau certificat de toute urgence.

Piège 7 : Ne pas documenter la procédure de retour en arrière. En cas d'incident, vous n'aurez peut-être pas le temps de déterminer comment revenir en arrière. Cela arrive lorsque les changements sont effectués sans plan de retour écrit. Comment éviter : rédigez une procédure de retour en arrière étape par étape avant tout changement, et testez-la en préproduction. Récupération : si aucune procédure n'existe, utilisez les étapes génériques de cet article : restaurez depuis la sauvegarde, rechargez, vérifiez.

Conclusion

La sauvegarde et la restauration de certificats TLS sont une compétence opérationnelle critique. En suivant les pratiques de cet article, vous pouvez réduire le risque de pannes liées aux certificats et récupérer rapidement lorsqu'elles surviennent. Les points clés sont :

• Inventoriez vos certificats et enregistrez leurs empreintes et dates de validité.
• Sauvegardez le certificat, la clé et la configuration ensemble, et chiffrez la sauvegarde de la clé.
• Testez vos sauvegardes en restaurant vers un emplacement temporaire et en comparant les empreintes.
• Après toute restauration, vérifiez la configuration, rechargez le service et testez le point de terminaison en direct.
• Préparez-vous aux modes de défaillance courants : expiration, problèmes de chaîne, inadéquation de clé, corruption, suppression et permissions.
• Évitez les pièges en testant les sauvegardes, en validant avant les changements et en surveillant l'expiration.
• Attribuez un propriétaire unique pour chaque étape opérationnelle et révisez le processus régulièrement.

Comme prochaine étape, choisissez une vérification à faible risque pour vos certificats TLS. Enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu, et examinez les dépendances telles que Nginx, l'Ingress Kubernetes et Linux. Un flux de travail technique fiable rend la défaillance visible, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision.