Certificats TLS de 47 jours : calendrier et automatisation

En bref. Le vote SC-081 du CA/Browser Forum, adopté le 11 avril 2025, réduit en trois étapes la validité maximale des certificats TLS de confiance publique. Les certificats émis à partir du 15 mars 2026 peuvent durer jusqu’à 200 jours, ceux émis à partir du 15 mars 2027 jusqu’à 100 jours, et ceux émis à partir du 15 mars 2029 jusqu’à 47 jours. La durée pendant laquelle une AC peut réutiliser une validation de domaine diminue aux mêmes dates : 200 jours, puis 100, puis 10. En pratique, chaque certificat doit être émis et déployé de façon automatisée (ACME). Le renouvellement devrait suivre la fenêtre ARI de l’AC, et il vous faut une surveillance qui vous alerte tant qu’il reste du temps pour réparer un renouvellement défaillant. Les AC privées ne sont pas concernées.

Le calendrier

Les règles figurent aux sections 6.3.2 et 4.2.1 des Baseline Requirements (version 2.3.1, octobre 2026). Le vote SC-081v3 a été proposé par Apple et soutenu par Sectigo, Google Chrome et Mozilla. Il a été adopté par 25 voix d’AC pour, aucune contre et 5 abstentions, et les quatre éditeurs de navigateurs ont tous voté pour.

Quelques détails qui comptent quand vous planifiez en fonction de ces chiffres :

• Ces limites sont des plafonds que les AC appliquent au moment de l’émission. Un certificat émis le 14 mars 2026 pouvait encore être valide 398 jours. Rien ne vous oblige à le remplacer avant son expiration, mais son remplaçant aura une durée de vie courte.
• La « validité » compte les deux bornes. Les BR la définissent comme la période allant de notBefore à notAfter inclus, et recommandent un jour de marge : les certificats ne devraient pas (« SHOULD NOT ») dépasser 199, 99 et 46 jours.
• La limite de réutilisation de la validation est le changement le plus important. Aujourd’hui, une AC peut réutiliser pendant des mois la preuve que vous contrôlez example.com. À partir de 2029, cette preuve doit dater de 10 jours au plus : presque chaque émission exige donc une nouvelle validation de domaine, et le challenge DNS ou HTTP doit lui aussi être automatisé.
• Les informations sur l’organisation figurant dans les certificats OV et EV (nom de l’entreprise, adresse) peuvent être réutilisées pendant 398 jours au lieu de 825.
• Champ d’application. Les BR régissent les certificats de serveur TLS émis par des AC de confiance publique. Les certificats de votre propre AC interne, les certificats client et les certificats S/MIME relèvent d’autres règles, ou d’aucune.

Ce que les AC émettent aujourd’hui

Le 20 octobre 2026, les certificats servis par quelques grands sites se présentaient ainsi. La sortie provient du script lifetimes.sh de la section sur la surveillance :

letsencrypt.org        Let's Encrypt              2026-09-04  ->  2026-12-03  (90 days)
www.google.com         Google Trust Services      2026-09-28  ->  2026-12-21  (84 days)
github.com             Sectigo Limited            2026-09-01  ->  2026-11-29  (90 days)
www.microsoft.com      Microsoft Corporation      2026-01-22  ->  2027-01-17  (360 days)
www.amazon.com         Amazon                     2026-01-19  ->  2027-01-11  (358 days)
www.digicert.com       DigiCert Inc               2026-10-11  ->  2026-11-26  (47 days)

Deux d’entre eux portent encore des certificats de près d’un an, émis en janvier 2026, juste avant l’entrée en vigueur de la limite de 200 jours. DigiCert sert déjà un certificat de 47 jours sur son propre site. Le calendrier publié par Let’s Encrypt va plus vite que ce qu’exigent les BR :

• 13 mai 2026 : le profil tlsserver, à activer explicitement, émet des certificats de 45 jours.
• 10 février 2027 : le profil par défaut classic émet des certificats de 64 jours avec une période de réutilisation des autorisations de 10 jours.
• 16 février 2028 : classic émet des certificats de 45 jours avec une période de réutilisation des autorisations de 7 heures.

Le répertoire ACME en production liste les profils que vous pouvez demander dès aujourd’hui :

"meta": {
  "profiles": {
    "classic": "https://letsencrypt.org/docs/profiles#classic",
    "shortlived": "https://letsencrypt.org/docs/profiles#shortlived",
    "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
  }
},
"renewalInfo": "https://acme-v02.api.letsencrypt.org/acme/renewal-info"

Ce qu’il faut automatiser

Avec des certificats de 398 jours, un renouvellement manuel par an était pénible mais supportable. Avec des certificats de 47 jours et une réutilisation de la validation limitée à 10 jours, le renouvellement manuel devient une tâche sujette aux erreurs au moins huit fois par an pour chaque nom, et plutôt douze si vous renouvelez aux deux tiers de la durée de vie. Le travail se divise en quatre parties.

1. L’émission via ACME. Utilisez un client ACME (RFC 8555) pour chaque certificat émis par une AC publique. La plupart des AC commerciales proposent elles aussi des points de terminaison ACME, souvent avec liaison de compte externe (external account binding). Si un certificat vous parvient encore par e-mail, par téléchargement sur un portail ou via un ticket, inscrivez-le en tête de liste.

2. Une validation sans intervention. Choisissez un challenge qui fonctionne sans opérateur humain :

• http-01 exige que le port 80 soit joignable sur chaque hôte qui sert le nom.
• dns-01 exige un accès à l’API de votre fournisseur DNS. Limitez la portée du jeton aux enregistrements _acme-challenge lorsque le fournisseur le permet.
• tls-alpn-01 fonctionne entièrement sur le port 443.

Deux méthodes plus récentes ont été conçues précisément pour ce cas. « DNS Labeled with Account ID », le challenge ACME dns-account-01 des BR §3.2.2.4.21, permet à plusieurs comptes ACME de valider le même nom sans se disputer un unique enregistrement _acme-challenge. « DNS TXT Record with Persistent Value » (§3.2.2.4.22, vote SC-088) permet de publier une fois pour toutes un enregistrement permanent :

_validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"

L’AC peut considérer chaque vérification de cet enregistrement comme valable 10 jours au plus. Mais c’est elle-même qui revérifie l’enregistrement, si bien que personne n’a à toucher au DNS à chaque renouvellement. Demandez à votre AC si elle prend en charge cette méthode avant de vous y fier.

3. Un renouvellement piloté par l’AC. Renouvelez tôt et laissez l’AC guider le choix du moment :

• Renouvelez aux deux tiers environ de la durée de vie. Pour un certificat de 45 jours, c’est le 30e jour. Let’s Encrypt prévient que « renouveler à un intervalle fixe de 60 jours ne suffira plus ». Depuis la version 4.0, certbot renouvelle lorsqu’il reste un tiers de la durée de vie, et non plus à 30 jours fixes de l’échéance.
• Utilisez ARI (RFC 9773), présenté dans la section suivante. L’AC indique à chaque client quand renouveler, et elle peut avancer cette fenêtre lorsqu’elle doit révoquer des certificats en masse.
• Demandez explicitement le profil si vous voulez des certificats de 45 jours avant que le profil par défaut de votre AC ne change.

4. Le déploiement sur chaque copie. Renouveler le fichier sur le disque ne suffit pas. Recensez tous les endroits où un certificat est copié :

• répartiteurs de charge et CDN dans lesquels les certificats sont importés,
• secrets Kubernetes,
• keystores Java et fichiers PKCS#12,
• appliances, serveurs de messagerie, bases de données et brokers de messages,
• applications mobiles qui épinglent un certificat feuille.

Chaque copie a besoin soit d’un hook de rechargement, soit d’une intégration qui récupère le nouveau certificat. Épingler un certificat feuille ou sa clé dans une application devient intenable à ce rythme. Épinglez plutôt une clé d’AC ou, mieux, n’épinglez rien.

Ce test exécute certbot 5.8.0 avec un serveur ACME Pebble 2.10.1 local, dont le profil tlsserver émet des certificats de 45 jours. Il montre que la demande de profil et la configuration de renouvellement fonctionnent comme documenté :

$ certbot certonly --standalone --non-interactive --agree-tos --register-unsafely-without-email \
    --server https://localhost:14000/dir -d app.example.test --preferred-profile tlsserver
Account registered.
Requesting a certificate for app.example.test
Successfully received certificate.
This certificate expires on 2026-12-04.
$ openssl x509 -in /etc/letsencrypt/live/app.example.test/cert.pem -noout -startdate -enddate
notBefore=Oct 20 11:47:52 2026 GMT
notAfter=Dec  4 11:47:51 2026 GMT
$ grep -E "preferred_profile|server" /etc/letsencrypt/renewal/app.example.test.conf
preferred_profile = tlsserver
server = https://localhost:14000/dir
$ certbot renew --non-interactive
Processing /etc/letsencrypt/renewal/app.example.test.conf
Certificate not yet due for renewal

certbot enregistre le profil dans la configuration de renouvellement, si bien que chaque renouvellement ultérieur le demande à nouveau. L’option --preferred-profile existe depuis certbot 4.0. Si le répertoire de l’AC ne liste pas le profil indiqué, certbot se rabat sur le profil par défaut de l’AC. Avec --required-profile, l’émission ou le renouvellement échoue dans ce cas. Les profils viennent du draft-ietf-acme-profiles, qui attendait l’examen de l’IESG en octobre 2026. Les clients autres que certbot nomment leurs options à leur façon.

Informations de renouvellement ACME (ARI)

Avec ARI (RFC 9773, juin 2025), le moment du renouvellement n’est plus une estimation côté client, mais une question posée à l’AC. Pour chaque certificat, le client construit un identifiant à partir de l’Authority Key Identifier (identifiant de clé de l’autorité) et du numéro de série du certificat :

url = renewalInfo || '/' || base64url(AKI keyIdentifier) || '.' || base64url(Serial)

Il interroge ensuite cette URL à intervalles réguliers, sans authentification. La réponse contient un champ suggestedWindow (fenêtre suggérée), et un en-tête Retry-After indique quand redemander. Vous pouvez faire la requête vous-même pour n’importe quel certificat Let’s Encrypt :

#!/bin/bash
set -e
host="$1"
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out cert.pem
aki=$(openssl x509 -in cert.pem -noout -ext authorityKeyIdentifier | grep -o -E '([0-9A-F]{2}:){19}[0-9A-F]{2}' | tr -d ':')
serial=$(openssl x509 -in cert.pem -noout -serial | cut -d= -f2)
# The DER INTEGER content keeps a leading 00 byte when the high bit is set.
[ $(( 16#${serial:0:1} )) -ge 8 ] && serial="00$serial"
b64url() { python3 -c 'import sys,base64; print(base64.urlsafe_b64encode(bytes.fromhex(sys.stdin.read().strip())).decode().rstrip("="))'; }
id="$(printf %s "$aki" | b64url).$(printf %s "$serial" | b64url)"
ari=$(curl -s https://acme-v02.api.letsencrypt.org/directory | grep -o '"renewalInfo": *"[^"]*"' | cut -d'"' -f4)
openssl x509 -in cert.pem -noout -issuer -startdate -enddate
echo "GET $ari/$id"
curl -s -D - "$ari/$id" | grep -i -E '^retry-after|^\{|"'

issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
GET https://acme-v02.api.letsencrypt.org/acme/renewal-info/uVnyjs8i8IbTN0j_dhQYuoLYVYc.BUOTO-OGs6KzrdU08hA7yLZf
retry-after: 25769
{
  "suggestedWindow": {
    "start": "2026-11-02T17:18:36Z",
    "end": "2026-11-04T12:29:25Z"

La fenêtre s’ouvre 59 jours après le début de validité de ce certificat de 90 jours, soit environ aux deux tiers de sa durée de vie. Le client devrait choisir un instant aléatoire dans la fenêtre, ce qui étale les renouvellements dans le temps. Si l’AC doit révoquer des certificats en masse, elle déplace la fenêtre dans le passé, et les clients bien conçus renouvellent en quelques heures au lieu d’échouer à l’expiration. Lors du renouvellement, le client indique l’identifiant de l’ancien certificat dans le champ replaces de sa nouvelle commande (order).

Prise en charge d’ARI dans les clients courants, d’après leurs notes de version :

Une surveillance qui repère un renouvellement défaillant

L’automatisation échoue sans bruit : un jeton d’API DNS expiré, une modification du pare-feu qui bloque le port 80, un hook de rechargement qui ne fonctionne plus. Avec un certificat de 47 jours renouvelé au 30e jour, vous disposez d’environ 17 jours entre le premier échec de renouvellement et la panne. Déclenchez l’alerte tôt dans cet intervalle.

Depuis l’extérieur. Sondez chaque nom public, pas seulement ceux dont vous vous souvenez. Le blackbox exporter de Prometheus expose l’expiration de la chaîne servie sous la forme de la métrique probe_ssl_earliest_cert_expiry :

probe_ssl_earliest_cert_expiry 1.795737599e+09
probe_success 1
probe_tls_version_info{version="TLS 1.3"} 1

Ces deux règles d’alerte sont validées par promtool check rules (Prometheus 3.5.0). La première se déclenche quand le renouvellement est en retard, la seconde quand la panne est proche :

groups:
  - name: certificates
    rules:
      - alert: CertificateRenewalOverdue
        # Fires when less than a third of a 47-day lifetime (about 16 days) is left:
        # the renewal job should have replaced the certificate by now.
        expr: probe_ssl_earliest_cert_expiry - time() < 16 * 86400
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"
      - alert: CertificateExpiresSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 7 * 86400
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"

Depuis un script. openssl x509 -checkend N se termine avec le code de sortie 1 si le certificat expire dans les N secondes, ce qui suffit pour une tâche cron ou une étape de CI :

$ openssl x509 -in cert.pem -noout -enddate
notAfter=Nov 26 23:59:59 2026 GMT
$ openssl x509 -in cert.pem -noout -checkend $((30 * 86400)); echo "exit status: $?"
Certificate will not expire
exit status: 0
$ openssl x509 -in cert.pem -noout -checkend $((45 * 86400)); echo "exit status: $?"
Certificate will expire
exit status: 1

Le relevé présenté en haut de cette page provient de ce script :

#!/bin/bash
for host in "$@"; do
  openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out /tmp/c.pem 2>/dev/null || { echo "$host: no certificate"; continue; }
  nb=$(openssl x509 -in /tmp/c.pem -noout -startdate | cut -d= -f2)
  na=$(openssl x509 -in /tmp/c.pem -noout -enddate | cut -d= -f2)
  issuer=$(openssl x509 -in /tmp/c.pem -noout -issuer -nameopt multiline | grep -E "organizationName" | head -1 | cut -d= -f2 | sed 's/^ *//')
  days=$(( ($(date -d "$na" +%s) - $(date -d "$nb" +%s) + 1) / 86400 ))
  printf '%-22s %-26s %s  ->  %s  (%s days)\n' "$host" "$issuer" "$(date -u -d "$nb" +%F)" "$(date -u -d "$na" +%F)" "$days"
done

Du côté de l’AC. Les journaux Certificate Transparency (journaux CT) enregistrent chaque certificat émis pour vos domaines. Un service de surveillance CT montre les renouvellements effectués et les certificats que vous n’attendiez pas. Consultez Certificate Transparency pour les développeurs, ou retrouvez l’historique d’un domaine avec l’outil d’historique CT. Pour savoir dans quelle mesure un ensemble de domaines est prêt, le calculateur de durée de vie des certificats applique le calendrier à chacun de vos certificats.

CAA et liaison au compte

Une réutilisation plus courte des validations implique davantage de validations, et chacune vérifie vos enregistrements CAA. À partir du 15 mars 2027 (vote SC-098), les AC doivent aussi respecter les paramètres accounturi et validationmethods de la RFC 8657. Vous pouvez ainsi limiter l’émission à votre propre compte ACME et au type de challenge de votre choix :

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"

Le générateur d’enregistrements CAA construit ces enregistrements. Gardez à l’esprit qu’un enregistrement CAA obsolète bloquera vos propres renouvellements, qui ont désormais lieu au moins huit fois par an au lieu d’une.

Erreurs fréquentes

• Un intervalle de renouvellement fixe. « Renouveler tous les 60 jours » échoue déjà avec des certificats de 45 jours. Renouvelez en fonction d’une fraction de la durée de vie, ou d’ARI.
• Renouveler sans recharger. Le nouveau fichier reste sur le disque pendant que le serveur continue de servir l’ancien certificat depuis la mémoire, jusqu’à son expiration. Testez le hook de déploiement, pas seulement le renouvellement.
• Oublier les copies. Le serveur d’origine renouvelle son certificat automatiquement, mais le CDN ou le répartiteur de charge conserve un certificat importé à la main.
• Alerter à 7 jours de l’échéance. Avec des certificats de 47 jours, une alerte une semaine avant l’expiration ne laisse pas le temps de déboguer un problème d’API DNS ou de pare-feu. Déclenchez l’alerte quand le renouvellement est en retard.
• Épingler des clés de certificats feuilles dans des applications mobiles ou des clients d’API. Chaque renouvellement avec une nouvelle clé les casse.
• Supposer que la PKI privée doit suivre. Votre AC interne peut garder sa propre politique. Des durées de vie courtes y restent une bonne idée, mais c’est à vous de choisir.

Sources

• CA/Browser Forum, Baseline Requirements v2.3.1 : §1.2.2 (dates applicables), §3.2.2.4.21–22 (nouvelles méthodes DNS), §4.2.1 (durées de réutilisation), §6.3.2 (validité).
• Vote SC-081v3 (adopté le 11 avril 2025, en vigueur depuis le 16 mai 2025).
• RFC 9773 : ACME Renewal Information. RFC 8555 : ACME. draft-ietf-acme-profiles.
• Let’s Encrypt, Réduction de la durée de vie des certificats à 45 jours et profils.
• Notes de version de certbot, Caddy, lego, acme.sh et cert-manager.
• RFC 8659 (CAA) et RFC 8657 (paramètres CAA accounturi et validationmethods).

Les sorties de commandes ont été produites le 20 octobre 2026 dans node:24.22.0-trixie (OpenSSL 3.5.7, curl 8.14.1), certbot/certbot:v5.8.0 avec ghcr.io/letsencrypt/pebble:2.10.1, quay.io/prometheus/blackbox-exporter:v0.25.0 et prom/prometheus:v3.5.0.