Un certificat expiré ne provoque pas une simple erreur discrète : le navigateur affiche un écran d’avertissement en pleine page, et la totalité du trafic s’arrête net. Ce constat, vécu une fois sur un site vitrine un dimanche soir, a suffi à décider qu’une alerte par courriel ne suffisait plus comme filet de sécurité.
Le renouvellement automatique du certificat existait déjà sur l’infrastructure, via un client ACME planifié en tâche cron. Le problème ne venait pas de l’absence de renouvellement, mais des cas où il échouait silencieusement : un pare-feu mal configuré après une migration, un port bloqué temporairement, une validation DNS qui n’aboutissait pas. Dans ces situations, personne ne relisait la boîte mail dédiée avant plusieurs jours.
Le principe retenu : vérifier avant de déployer, pas après
Plutôt que d’ajouter une nouvelle alerte, la décision a été de transformer la vérification de la date d’expiration en une étape bloquante du pipeline de déploiement. Concrètement, avant chaque mise en production, une commande interroge le certificat en place sur le domaine cible et compare sa date d’expiration à la date du jour. Si l’écart descend sous sept jours, le déploiement s’arrête avec un message explicite plutôt que de continuer silencieusement.
Ce choix déplace la responsabilité : ce n’est plus à une personne de surveiller une alerte, c’est au pipeline de refuser d’avancer tant que la situation n’est pas corrigée. Une équipe ne peut pas ignorer un déploiement qui échoue, alors qu’elle peut très bien laisser un courriel non lu.
La commande de vérification
La vérification s’appuie sur openssl s_client pour récupérer le certificat exposé par le serveur, puis sur openssl x509 pour en extraire la date de fin de validité au format epoch, comparée à la date courante.
#!/usr/bin/env bash
set -euo pipefail
DOMAINE="$1"
SEUIL_JOURS=7
DATE_FIN=$(echo | openssl s_client -servername "$DOMAINE" \
-connect "$DOMAINE:443" 2>/dev/null \
| openssl x509 -noout -enddate | cut -d= -f2)
EPOCH_FIN=$(date -d "$DATE_FIN" +%s)
EPOCH_MAINTENANT=$(date +%s)
JOURS_RESTANTS=$(( (EPOCH_FIN - EPOCH_MAINTENANT) / 86400 ))
if [ "$JOURS_RESTANTS" -lt "$SEUIL_JOURS" ]; then
echo "Certificat TLS pour $DOMAINE expire dans $JOURS_RESTANTS jour(s)."
echo "Déploiement bloqué : corrigez le renouvellement avant de continuer."
exit 1
fi
echo "Certificat TLS valide encore $JOURS_RESTANTS jour(s), déploiement autorisé."
Ce script est appelé comme étape préalable dans la configuration de la CI, avant toute connexion SSH vers le serveur de production. Un code de sortie différent de zéro interrompt automatiquement le reste du pipeline, sans action supplémentaire à écrire.
Choisir le bon seuil
Le choix de sept jours n’est pas arbitraire : c’est le délai jugé suffisant pour diagnostiquer et corriger un échec de renouvellement ACME sans urgence excessive, tout en restant assez court pour ne pas bloquer les déploiements ordinaires pendant des semaines. Un seuil trop bas, à un ou deux jours, réduit le temps de réaction disponible en cas de blocage réel. Un seuil trop haut déclenche des refus de déploiement fréquents et non justifiés, ce qui pousse rapidement les équipes à ignorer ou contourner le contrôle.
Le seuil est paramétrable par variable d’environnement selon les projets, certains clients sensibles au temps de disponibilité imposant un seuil de quatorze jours.
Un contrôle bloquant que personne ne peut désactiver d’un clic reste plus fiable qu’une alerte que tout le monde peut laisser non lue.
Ce que ce contrôle ne fait pas
Ce script ne renouvelle rien : il se contente de vérifier un état et de refuser d’avancer si cet état est dégradé. La correction du renouvellement automatique lui-même, quand il échoue, reste un sujet distinct qui touche à la configuration du client ACME et à l’accessibilité du port de validation, pas à ce contrôle de blocage.
Il faut aussi noter une limite pratique : ce contrôle ne s’exécute qu’au moment d’un déploiement. Un site qui ne reçoit aucune mise à jour pendant plusieurs semaines ne bénéficie d’aucune vérification entre-temps, ce qui justifie de le combiner avec un contrôle périodique indépendant du pipeline pour les sites peu actifs.
Notre verdict
Faire du pipeline de déploiement le point de contrôle plutôt qu’une alerte séparée a changé une chose concrète : la vérification n’est plus une tâche que quelqu’un doit penser à faire, elle fait partie du chemin obligatoire vers la production. C’est un déplacement modeste mais qui élimine un oubli humain récurrent, sans ajouter de nouvel outil de supervision à surveiller.
