Automatiser le renouvellement de vos certificats : le TP ACME

Nous vous annoncions en 2025 que la durée de vie des certificats allait tomber à 47 jours. Ce n’est plus une prévision : depuis le 15 mars 2026, le plafond est de 200 jours. Il passera à 100 jours en mars 2027, puis à 47 en mars 2029.

Autrement dit, la question n’est plus de savoir s’il faut automatiser, mais si votre automatisation tiendra. Beaucoup d’infrastructures ont un certbot installé il y a trois ans, jamais vérifié depuis, qui renouvelle correctement jusqu’au jour où il échoue en silence. Avec des certificats de 47 jours, ce silence coûte un site en panne en moins de deux mois.

Ce TP monte une chaîne complète et vérifiable, puis la supervise.

Où on en est vraiment

Une conséquence sous-estimée : la réutilisation de la validation de contrôle de domaine se réduit en parallèle, jusqu’à 10 jours pour les SAN d’ici 2029. Aujourd’hui, une validation faite une fois vaut longtemps. Demain, votre automatisation devra aussi reprouver régulièrement que le domaine est bien à vous. Un script qui dépose un fichier à la main lors de la première émission ne suffira plus.

Étape 1 : choisir son client ACME

ACME est le protocole d’émission automatisée popularisé par Let’s Encrypt. Trois clients couvrent l’essentiel des besoins.

Si votre reverse proxy sait le faire lui-même, c’est encore mieux. Caddy et Traefik gèrent ACME nativement, sans client externe ni tâche planifiée à surveiller.

Étape 2 : HTTP-01 ou DNS-01 ?

C’est le choix structurant du TP. L’autorité de certification doit vérifier que le domaine vous appartient, et deux méthodes dominent.

Notre recommandation : DNS-01 dès que vous gérez plus d’une poignée de certificats. Il vous affranchit de l’accessibilité du serveur sur le port 80, ce qui élimine d’un coup une famille entière de pannes de renouvellement : pare-feu modifié, redirection HTTPS trop zélée, machine placée derrière un filtrage.

Étape 3 : émettre le certificat

# Installation (installe aussi la tache planifiee de renouvellement)
curl https://get.acme.sh | sh -s email=admin@exemple.fr

# Choisir l'autorite de certification par defaut
acme.sh --set-default-ca --server letsencrypt

# --- Option A : HTTP-01, serveur web public ---
acme.sh --issue -d exemple.fr -d www.exemple.fr \
  --webroot /var/www/exemple.fr/public

# --- Option B : DNS-01 avec wildcard (exemple OVH) ---
export OVH_AK="votre_application_key"
export OVH_AS="votre_application_secret"
export OVH_CK="votre_consumer_key"
acme.sh --issue -d exemple.fr -d '*.exemple.fr' --dns dns_ovh

# Installer les fichiers a un emplacement stable et recharger
acme.sh --install-cert -d exemple.fr \
  --key-file       /etc/ssl/exemple.fr/privkey.pem \
  --fullchain-file /etc/ssl/exemple.fr/fullchain.pem \
  --reloadcmd      "systemctl reload nginx"

Ce dernier point est important et souvent mal compris. Le répertoire de travail d’acme.sh est un espace interne dont l’organisation peut changer d’une version à l’autre. L’option --install-cert copie les fichiers à un emplacement que vous maîtrisez et mémorise la commande de rechargement, qui sera rejouée à chaque renouvellement.

Étape 4 : recharger le service

C’est la cause n°1 des incidents de certificat, et elle est particulièrement vicieuse : le renouvellement réussit, les fichiers sur le disque sont à jour, tout semble normal. Mais le service tourne toujours avec l’ancien certificat chargé en mémoire, et continue de le présenter aux visiteurs jusqu’à expiration.

# Serveurs web : rechargement a chaud, sans coupure
systemctl reload nginx
systemctl reload apache2

# Messagerie : Postfix recharge a chaud, Dovecot aussi
systemctl reload postfix dovecot

# HAProxy : rechargement a chaud si le service est bien configure
systemctl reload haproxy

# PostgreSQL : recharge le certificat sans redemarrer
systemctl reload postgresql

# Conteneurs : il faut agir DANS le conteneur, pas sur l'hote
docker exec mon-nginx nginx -s reload

# Verifier la date d'expiration REELLEMENT servie sur le port
echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null \
  | openssl x509 -noout -dates -subject

Retenez cette distinction : vérifier le fichier sur le disque ne prouve rien. Seule l’interrogation du port révèle ce que vos visiteurs reçoivent réellement.

Étape 5 : tester le renouvellement

Une automatisation jamais testée n’est pas une automatisation, c’est un pari. Les deux clients proposent un mode d’essai qui déroule tout le processus sans consommer les quotas de l’autorité.

# certbot : simulation complete, sans emission reelle
certbot renew --dry-run

# acme.sh : forcer un vrai renouvellement pour valider la chaine
acme.sh --renew -d exemple.fr --force

# Verifier que la tache planifiee existe VRAIMENT
acme.sh --list
crontab -l | grep acme
systemctl list-timers | grep -i certbot

# Le test qui compte : la date servie sur le port a-t-elle bouge ?
echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null \
  | openssl x509 -noout -enddate

Étape 6 : superviser l’expiration

Même bien configurée, une automatisation peut tomber : clé d’API DNS révoquée, changement de règle sur le pare-feu, domaine transféré chez un autre registrar, disque plein. La supervision n’est pas une précaution de luxe, c’est le filet.

Le principe : vérifier chaque jour la date d’expiration servie sur le port, et alerter bien avant l’échéance. Avec des certificats de 47 jours, un seuil d’alerte à 30 jours n’a plus de sens : il se déclencherait presque en permanence. Visez plutôt 10 à 14 jours, ce qui laisse le temps d’intervenir sans crier au loup.

#!/usr/bin/env bash
# Alerte si un certificat servi expire dans moins de SEUIL jours.
set -uo pipefail
SEUIL=14
DOMAINES=(exemple.fr www.exemple.fr mail.exemple.fr intranet.exemple.fr)
code_sortie=0

for d in "${DOMAINES[@]}"; do
  fin=$(echo | timeout 10 openssl s_client -connect "$d:443" -servername "$d" 2>/dev/null \
        | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)

  if [ -z "$fin" ]; then
    echo "CRITIQUE  $d : impossible de recuperer le certificat"
    code_sortie=2
    continue
  fi

  # GNU date (Linux). Sur macOS/BSD : date -j -f "%b %d %T %Y %Z"
  reste=$(( ( $(date -d "$fin" +%s) - $(date +%s) ) / 86400 ))

  if   [ "$reste" -lt 0 ];       then echo "EXPIRE    $d : depuis $((-reste)) j"; code_sortie=2
  elif [ "$reste" -lt "$SEUIL" ]; then echo "ALERTE    $d : expire dans $reste j"; code_sortie=2
  else                                echo "OK        $d : $reste j restants"
  fi
done

exit $code_sortie

Supervisez tous les services qui présentent un certificat, pas seulement le site web : la messagerie sur 993 et 465, le VPN, l’intranet, les API internes. Ce sont précisément ceux qu’on oublie, parce que personne ne s’en plaint avant que ça casse.

Les pièges classiques

Et chez Datacampus ?

Sur nos offres infogérées, ACME et Let’s Encrypt sont installés et supervisés par défaut : émission, renouvellement, rechargement des services et alerte sur l’expiration. La réduction à 47 jours ne changera rien pour nos clients infogérés, pour la simple raison que rien n’était manuel au départ.

Si vous gérez vous-même vos serveurs, le script de supervision ci-dessus est un bon point de départ, et il est à vous.

TL;DR, ce qu’il faut retenir

• Le plafond est de 200 jours depuis le 15 mars 2026, puis 100 en 2027 et 47 en 2029.
• La réutilisation de la validation de domaine descend en parallèle, jusqu’à 10 jours pour les SAN.
• DNS-01 dès que vous dépassez quelques certificats : wildcards possibles, aucune exposition du port 80.
• Protégez la clé d’API DNS, elle est plus sensible que le certificat lui-même.
• Le rechargement du service est la panne n°1 : vérifiez sur le port, pas sur le disque.
• Testez avec --dry-run et vérifiez que la tâche planifiée existe réellement.
• Supervisez l’expiration à 10 ou 14 jours, sur tous les services TLS et pas seulement le port 443.

FAQ — Automatiser ses certificats

Pour aller plus loin :
• CA/Browser Forum — ballot SC-081v3 · acme.sh
• Sur datacampus.fr : La durée de vie passe à 47 jours · Qu’est-ce qu’un fichier CSR ? · Erreur de nom de certificat · Protéger son site web · Infogérance