Liste de contrôle des opérations de production des certificats TLS avec exemples pratiques

Introduction

Gérer TLS en production signifie savoir exactement pourquoi un certificat fonctionne aujourd’hui et avoir un plan concret pour le jour où il cessera de fonctionner. Cette liste de contrôle transforme cet objectif en commandes de diagnostic en lecture seule, en changements de configuration délimités et en procédures de récupération sûres à exécuter sous pression. Elle s’adresse aux développeurs, consultants DevOps et équipes techniques de startups qui doivent vérifier les certificats sans introduire de nouveaux risques.

La liste couvre le cycle de vie opérationnel complet : inventorier ce qui est installé, valider un certificat et sa chaîne, détecter les défaillances courantes avant les utilisateurs et récupérer sans longue interruption. Chaque section inclut la commande exacte ou la vérification à effectuer, l’aspect attendu de la sortie, ce que signifie un signal de défaillance et qui doit assurer le suivi.

Le principe fondamental est la sécurité opérationnelle : observer avant de modifier, 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.

Inventaire des versions et de l’environnement

Avant de toucher à quoi que ce soit, identifiez le composant qui termine TLS, la version d’OpenSSL utilisée et le chemin vers chaque certificat et clé impliqués. Cet inventaire évite l’erreur classique de renouveler un certificat sur le mauvais serveur ou de supposer que le terminal utilise la même version que la ligne de commande.

Exécutez d’abord ces vérifications en lecture seule :

# Version d'OpenSSL et configuration par défaut
openssl version -a

# Lister les fichiers de certificat réellement présents
ls -l /etc/ssl/certs/*.pem /etc/ssl/private/*.pem 2>/dev/null

# Identifier le processus qui écoute sur le port 443
sudo ss -tlnp | grep ':443'

La sortie attendue pour un hôte Ubuntu 22.04 typique ressemble à :

OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
-rw-r--r-- 1 root root 1944 Feb 28 11:20 /etc/ssl/certs/example.com.pem
-rw------- 1 root root 3272 Feb 28 11:20 /etc/ssl/private/example.com.key
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

Un fichier de certificat manquant ou une clé avec des permissions lisibles par tous est un signal de défaillance. Le fichier de clé doit être en mode 600 et appartenir à l’utilisateur du service, pas à un compte personnel.

Enregistrez les champs d’inventaire suivants dans un endroit visible par toute l’équipe, comme un runbook ou un wiki interne :

Inspection d’un fichier de certificat

Inspectez un fichier de certificat sans le modifier :

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

Sortie attendue :

subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R11
serial=04A2F08D9B1234C56789ABCDEF0123456789A
notBefore=May 28 11:20:00 2025 GMT
notAfter=Aug 26 11:20:00 2025 GMT
SHA256 Fingerprint=3C:19:6E:...:C5:2A

Enregistrez le sujet attendu, l’émetteur, la fenêtre de validité et l’empreinte SHA-256 avant le déploiement. Après tout renouvellement ou changement, réexécutez cette même commande et comparez l’empreinte. Une empreinte modifiée avec le même chemin de fichier signifie souvent un remplacement de certificat inattendu.

Vérification d’un point de terminaison distant

Testez un point de terminaison distant exactement comme le ferait un client, pas avec une simple vérification TCP générique :

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Un résultat sain se termine par :

Verify return code: 0 (ok)

Une connexion TCP réussie ne prouve pas à elle seule la validité du certificat. Recherchez ces signaux de défaillance spécifiques :

• Verify return code: 10 (certificate has expired) signifie que le certificat a dépassé sa date notAfter.
• Verify return code: 21 (unable to verify the first certificate) signifie que le client ne peut pas construire la chaîne, généralement parce qu’un certificat intermédiaire est absent de la configuration du serveur.
• verify error:num=2:unable to get issuer certificate indique une racine ou un intermédiaire manquant dans le magasin de confiance du client.
• Une non-concordance de nom d’hôte apparaît comme verify error:num=62:Hostname mismatch lorsque la valeur de -servername ne correspond pas au SAN du certificat.

Validation de la chaîne hors ligne

Validez la chaîne complète hors ligne avant de la déployer sur un serveur en direct :

openssl verify -CAfile /etc/ssl/certs/trusted-root-ca.pem \
  -untrusted /etc/ssl/certs/intermediate.pem \
  /etc/ssl/certs/example.com.pem

Sortie de succès attendue :

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

Si la sortie indique unable to get local issuer certificate, l’argument -CAfile ou -untrusted ne contient pas l’émetteur requis. La correction consiste à télécharger le bon intermédiaire auprès de l’autorité de certification et à l’ajouter au bundle de chaîne, pas à désactiver la vérification.

Utilisez des espaces réservés dans la documentation et ne commitez jamais de clés privées dans un dépôt. Testez les procédures de renouvellement et de restauration bien avant que la fenêtre d’expiration devienne urgente.

Chemin de configuration sécurisé

Une fois l’inventaire terminé, n’effectuez qu’un seul changement délimité à la fois et sachez comment le restaurer. Par exemple, lorsqu’un certificat expire et doit être remplacé sur un serveur Nginx, ne modifiez pas directement la configuration en direct sans sauvegarde.

Exemple de changement minimal : remplacer un certificat expiré

1. Créez une sauvegarde de la configuration actuelle et des fichiers de certificat :

sudo cp /etc/nginx/sites-available/example.com.conf \
  /etc/nginx/sites-available/example.com.conf.bak.$(date +%F)
sudo cp /etc/ssl/certs/example.com.pem \
  /etc/ssl/certs/example.com.pem.old.$(date +%F)

1. Placez le nouveau certificat et la clé aux chemins attendus. Pour un renouvellement Let’s Encrypt, certbot le fait généralement automatiquement, mais si vous copiez manuellement, préservez les permissions :

sudo install -o root -g root -m 644 new-cert.pem /etc/ssl/certs/example.com.pem
sudo install -o root -g root -m 600 new-key.pem /etc/ssl/private/example.com.key

1. Testez la configuration Nginx pour les erreurs de syntaxe avant de recharger :

sudo nginx -t

Sortie attendue :

nginx: configuration file /etc/nginx/nginx.conf test is successful

1. Rechargez Nginx pour appliquer le changement sans interrompre les connexions actives :

sudo nginx -s reload

1. Vérifiez que le serveur en cours d’exécution présente désormais le nouveau certificat :

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

Comparez l’empreinte avec celle enregistrée dans l’inventaire. Si elles correspondent, le changement a réussi. Sinon, restaurez en rétablissant les sauvegardes et en rechargeant Nginx à nouveau.

Liste de restauration

Pour tout changement de certificat, notez les commandes de restauration exactes avant de commencer. Exemple :

# Restaurer le certificat et la clé
sudo cp /etc/ssl/certs/example.com.pem.old.2025-06-10 /etc/ssl/certs/example.com.pem
sudo cp /etc/ssl/private/example.com.key.old.2025-06-10 /etc/ssl/private/example.com.key
# Restaurer la configuration Nginx si elle a été modifiée
sudo cp /etc/nginx/sites-available/example.com.conf.bak.2025-06-10 \
  /etc/nginx/sites-available/example.com.conf
# Recharger et vérifier
sudo nginx -s reload

Exemple avec Ingress Kubernetes

Pour un Ingress Kubernetes, le même principe s’applique. Avant de mettre à jour un secret TLS, enregistrez l’actuel :

kubectl get secret example-tls -n production -o yaml > example-tls-backup.yaml

Créez le nouveau secret à partir des fichiers :

kubectl create secret tls example-tls \
  --cert=/path/to/tls.crt \
  --key=/path/to/tls.key \
  -n production --dry-run=client -o yaml | kubectl apply -f -

Vérifiez ensuite que le contrôleur Ingress a pris en compte le changement :

kubectl get ingress example-ingress -n production -o jsonpath='{.spec.tls}' ; echo

Vérifiez le certificat réellement présenté par l’Ingress :

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

Si le nouveau certificat n’est pas servi, consultez les journaux du contrôleur et la ressource Ingress pour vérifier la référence au bon nom de secret. Le propriétaire de ce changement est l’ingénieur d’astreinte, et la restauration consiste à réappliquer le YAML de sauvegarde.

Vérification et diagnostics

La vérification n’est pas un événement ponctuel. Planifiez une vérification hebdomadaire en lecture seule qui confirme que chaque certificat public est toujours valide et servi correctement. Automatisez-la avec un script qui échoue bruyamment lorsque quelque chose ne va pas.

Script automatisé de santé des certificats

Enregistrez ce qui suit sous le nom cert-health-check.sh et exécutez-le depuis cron ou un job CI :

#!/usr/bin/env bash
set -euo pipefail

DOMAINS=("example.com" "api.example.com" "app.example.com")
WARN_DAYS=14

for domain in "${DOMAINS[@]}"; do
  echo "Checking $domain..."
  cert_file="/tmp/${domain}.pem"
  echo | openssl s_client -connect "${domain}:443" -servername "${domain}" 2>/dev/null \
    | openssl x509 -out "${cert_file}"

  enddate=$(openssl x509 -in "${cert_file}" -noout -enddate | cut -d= -f2)
  end_epoch=$(date -d "${enddate}" +%s)
  now_epoch=$(date +%s)
  diff_days=$(( (end_epoch - now_epoch) / 86400 ))

  echo "${domain}: expires in ${diff_days} days (${enddate})"
  if [ "${diff_days}" -lt "${WARN_DAYS}" ]; then
    echo "WARNING: ${domain} certificate expires in ${diff_days} days!" >&2
    exit 1
  fi
done

echo "All certificates are valid."

Lorsqu’un certificat est sain, le script affiche :

Checking example.com...
example.com: expires in 55 days (Aug 26 11:20:00 2025 GMT)
Checking api.example.com...
api.example.com: expires in 55 days (Aug 26 11:20:00 2025 GMT)
Checking app.example.com...
app.example.com: expires in 55 days (Aug 26 11:20:00 2025 GMT)
All certificates are valid.

Si l’un d’eux est sur le point d’expirer, il affiche l’avertissement et se termine avec le statut 1, ce qui peut déclencher une alerte via votre système de surveillance.

Diagnostic des problèmes de chaîne

Lorsqu’un client signale un certificat non fiable mais que openssl verify sur le serveur indique OK, la différence vient généralement du magasin de confiance du client. Diagnostiquez avec l’option -showcerts :

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null

La sortie liste chaque certificat que le serveur envoie. Une chaîne complète montre le certificat feuille, l’intermédiaire et parfois la racine. Si l’intermédiaire est manquant, le client ne peut pas construire la chaîne. Vérifiez la configuration du serveur : pour Nginx, la directive ssl_certificate doit pointer vers un fichier qui concatène le certificat feuille et tous les intermédiaires dans l’ordre :

ssl_certificate /etc/ssl/certs/example.com.chained.pem;

Créez le fichier chaîné avec :

cat example.com.pem intermediate.pem > example.com.chained.pem

Rechargez ensuite Nginx et retestez. Le propriétaire de ce diagnostic est l’ingénieur sécurité d’astreinte, et la correction est examinée lors de la prochaine synchronisation hebdomadaire des opérations.

Vérification de la configuration des protocoles et des suites de chiffrement

Les certificats TLS peuvent être valides alors que le serveur accepte encore des protocoles obsolètes. Vérifiez le protocole minimal et la suite de chiffrement :

echo | openssl s_client -connect example.com:443 -tls1_2 -servername example.com 2>&1 | grep -E 'Protocol|Cipher'

Sortie moderne attendue :

Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384

Si le serveur négocie TLSv1.0 ou une suite de chiffrement export, mettez à jour votre configuration Nginx ou de service pour désactiver les anciens protocoles. Une base sécurisée pour Nginx 1.24 est :

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

Rechargez et retestez. Ce changement a un faible rayon d’impact car seules les nouvelles connexions sont affectées, mais validez avec un navigateur et une suite de test SSL automatisée avant de déclarer le succès.

Modes de défaillance et récupération

Les pannes TLS en production relèvent presque toujours de quatre modes de défaillance : expiration, non-concordance du nom d’hôte, chaîne incomplète ou compromission de la clé privée. Chacun a une signature et un chemin de récupération distincts.

Mode de défaillance 1 : certificat expiré

Signal : openssl s_client renvoie Verify return code: 10 (certificate has expired). Les utilisateurs voient des avertissements de navigateur et les clients API échouent avec CERTIFICATE_VERIFY_FAILED.

Pourquoi cela arrive : l’automatisation du renouvellement a échoué silencieusement, ou le certificat a été renouvelé mais le service n’a jamais été rechargé.

Récupération :

1. Vérifiez le fichier réel sur le disque :

openssl x509 -in /etc/ssl/certs/example.com.pem -noout -enddate

S’il affiche une ancienne date, renouvelez manuellement. Pour certbot :

sudo certbot renew --cert-name example.com --force-renewal

Si le fichier affiche une nouvelle date, rechargez le service :

sudo nginx -s reload

Retestez ensuite. Le propriétaire de cette récupération est l’ingénieur d’astreinte, et la cause profonde est examinée lors du post-mortem de l’incident suivant.

Mode de défaillance 2 : non-concordance du nom d’hôte

Signal : openssl s_client affiche verify error:num=62:Hostname mismatch ou le navigateur indique que le certificat n’est pas valide pour le domaine.

Pourquoi cela arrive : le certificat a été émis pour un domaine différent, ou le service est atteint via une adresse IP ou un nom interne qui ne figure pas dans la liste SAN.

Récupération :

1. Listez les entrées SAN :

openssl x509 -in /etc/ssl/certs/example.com.pem -noout -text | grep -A1 'Subject Alternative Name'

1. Si le nom d’hôte requis est absent, obtenez un nouveau certificat qui l’inclut. Ne contournez pas le problème en désactivant la vérification du nom d’hôte dans les clients.

1. Pour les services internes, assurez-vous que le certificat inclut le FQDN interne (par exemple service.internal.example.com) dans le SAN.

Mode de défaillance 3 : chaîne incomplète

Signal : Verify return code: 21 (unable to verify the first certificate), ou des tests de serveur comme SSL Labs signalent « Chain issues: Incomplete ».

Pourquoi cela arrive : le serveur n’envoie que le certificat feuille, pas l’intermédiaire. Les navigateurs modernes mettent parfois en cache les intermédiaires, mais les clients curl, Python et Node.js échouent.

Récupération :

1. Téléchargez le bon intermédiaire depuis le site de l’autorité de certification (pour Let’s Encrypt, récupérez https://letsencrypt.org/certs/2024/r11.pem).

1. Concaténez le certificat feuille et l’intermédiaire :

cat example.com.pem r11.pem > example.com.chained.pem

1. Mettez à jour la directive ssl_certificate de Nginx pour pointer vers le fichier chaîné et rechargez. Retestez avec openssl s_client -showcerts pour confirmer que les deux certificats sont présentés.

Mode de défaillance 4 : compromission de la clé privée

Signal : utilisation inattendue du certificat, alertes des journaux de transparence des certificats ou rapport d’incident de sécurité.

Pourquoi cela arrive : la clé privée a été exposée dans un dépôt, une sauvegarde ou un serveur compromis.

Récupération :

1. Révoquez immédiatement le certificat auprès de l’autorité de certification. Pour Let’s Encrypt, utilisez certbot revoke --cert-name example.com --reason keycompromise.

1. Générez une nouvelle clé privée et une demande de certificat :

openssl req -new -newkey rsa:2048 -nodes -keyout new.key -out new.csr -subj "/CN=example.com"

1. Obtenez un nouveau certificat auprès de l’autorité de certification avec la CSR.

1. Remplacez la clé et le certificat sur le serveur, rechargez et vérifiez que l’empreinte change.

1. Faites tourner tous les autres secrets stockés sur le même système.

Le propriétaire de la réponse à une compromission de clé est le responsable sécurité, et l’incident est examiné avec une analyse complète des causes profondes dans les 72 heures.

Liste de contrôle des opérations

Cette liste consolidée est formatée pour être utilisée pendant une fenêtre de maintenance ou un incident. Chaque élément indique la commande, le résultat attendu, le propriétaire et la fréquence de révision.

Liste de contrôle pré-déploiement

Liste de contrôle post-déploiement

Exemple de journal d’exécution

Lors d’une série de renouvellements de certificats, une équipe a enregistré le journal suivant :

2025-06-10 09:00 CST - Alex Morgan - Contrôles pré-déploiement réussis pour example.com, api.example.com.
2025-06-10 09:05 CST - Alex Morgan - Certificats renouvelés via certbot. Nouvelles empreintes enregistrées dans l’inventaire.
2025-06-10 09:10 CST - Priya Shah - Nginx rechargé sur web-prod. nginx -t réussi.
2025-06-10 09:12 CST - Priya Shah - Vérification distante a renvoyé le code 0 pour les trois domaines.
2025-06-10 09:15 CST - Équipe - Liste de contrôle post-déploiement terminée. Aucun problème.

Un tel journal permet de reconstituer exactement ce qui a changé et qui a approuvé chaque étape.

Pièges courants et comment les éviter

Même les équipes expérimentées rencontrent à répétition les mêmes problèmes de certificats. Voici les pièges les plus fréquents et ce qu’il faut faire.

Piège 1 : se fier aux alertes d’expiration d’une source unique

Pourquoi cela arrive : les équipes configurent une alerte de surveillance provenant d’une seule autorité de certification ou d’un seul script, et lorsque ce script tombe en panne, l’expiration passe inaperçue.

Comment éviter : exécutez au moins deux vérifications d’expiration indépendantes : un script comme celui de cet article et un outil de surveillance externe comme UptimeRobot, Pingdom ou un job cron sur un autre hôte. Configurez les deux pour alerter 14 jours avant l’expiration.

Récupération si cela arrive : si un avis d’expiration arrive trop tard, ajoutez immédiatement un rappel manuel au calendrier pour tous les certificats, exécutez la commande d’inventaire et renouvelez d’abord les plus urgents.

Piège 2 : utiliser inutilement des certificats génériques

Pourquoi cela arrive : les certificats génériques semblent pratiques car un seul certificat couvre de nombreux sous-domaines.

Pourquoi c’est un problème : une clé privée générique compromise peut être utilisée pour usurper n’importe quel sous-domaine, ce qui élargit considérablement le rayon d’impact. De plus, certaines normes de conformité interdisent les certificats génériques pour les systèmes en contact avec les clients.

Comment éviter : utilisez des certificats génériques uniquement si vous avez plus de cinq sous-domaines sur le même domaine et que vous pouvez contrôler étroitement la clé privée. Sinon, émettez des certificats séparés par sous-domaine ou utilisez une autorité de certification interne avec des certificats à courte durée de vie.

Piège 3 : renouvellement manuel sans environnement de test

Pourquoi cela arrive : les petites équipes renouvellent souvent les certificats de production à la main parce que l’automatisation semble excessive.

Comment éviter : utilisez un client ACME comme certbot, lego ou un service géré qui automatise le renouvellement. Si le renouvellement manuel est inévitable, testez toujours toute la procédure dans un environnement de préproduction en utilisant les mêmes commandes et chemins de fichiers.

Récupération si cela arrive : si un renouvellement manuel échoue, restaurez à l’aide des fichiers de sauvegarde et répétez la procédure. N’itérez pas sur le serveur de production sous pression.

Piège 4 : inclure le certificat racine dans la chaîne du serveur

Pourquoi cela arrive : certaines équipes concatènent le certificat racine avec le certificat feuille et l’intermédiaire, pensant que les clients en ont besoin.

Pourquoi c’est un problème : le certificat racine est déjà dans le magasin de confiance du client. L’envoyer n’ajoute aucune valeur et peut déclencher des avertissements dans certaines bibliothèques TLS.

Comment éviter : n’envoyez que le certificat feuille et les certificats intermédiaires dans la chaîne, jamais la racine. Vérifiez avec openssl s_client -showcerts et assurez-vous que le dernier certificat de la liste n’est pas une racine auto-signée.

Piège 5 : modifier les permissions des fichiers pendant le déploiement

Pourquoi cela arrive : les ingénieurs copient de nouveaux fichiers de certificat avec cp et oublient de définir des permissions restrictives, laissant les clés privées lisibles par d’autres utilisateurs.

Comment éviter : utilisez toujours install -m 600 pour les fichiers de clé et install -m 644 pour les certificats, ou définissez explicitement les permissions après la copie :

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

Conclusion

Une liste de contrôle des opérations de certificats TLS n’est utile que si chaque recommandation est ciblée sur la version, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n’est pas une procédure opérationnelle.

Commencez par une vérification à faible risque : choisissez un seul certificat de production, exécutez les commandes d’inspection en lecture seule de cet article et enregistrez l’état actuel. Exécutez ensuite le script de vérification d’expiration et comparez le résultat avec le signal attendu. Passez en revue la table d’inventaire et attribuez un propriétaire unique pour chaque certificat, avec une cadence de révision hebdomadaire ou mensuelle selon la criticité du certificat.

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 la récupération avant qu’un incident ne force la décision. Documentez chaque changement dans un journal d’exécution, conservez des sauvegardes de chaque fichier touché et répétez les procédures de restauration avant d’en avoir besoin. C’est la différence entre des opérations de certificats prévisibles et une course tardive de dernière minute.