Depuis le 15 mars 2026, la durée de vie des certificats TLS publics est plafonnée à 200 jours, et elle tombera à 47 jours en 2029. Le modèle du certificat acheté puis réimporté à la main devient intenable pour toutes les infrastructures. Découvrez comment automatiser le renouvellement avec ACM sur AWS, ou ACME partout ailleurs.
Le renouvellement d’un certificat TLS public était jusqu’ici une formalité annuelle, et ce ne sera plus jamais le cas : en avril 2025, le CA/Browser Forum, l’organisme qui réunit les autorités de certification et les éditeurs de navigateurs, a adopté le ballot SC-081v3, qui réduit par paliers la durée de vie maximale des certificats publics. La première marche est en vigueur depuis mars 2026.
Depuis le 15 mars 2026, la durée de vie maximale d’un certificat TLS public est de 200 jours. Elle tombera à 100 jours en mars 2027, puis à 47 jours en mars 2029. Le ballot SC-081v3 s’impose à toutes les autorités de certification, sans dérogation possible.
Nous avons pris la mesure de ce changement lors d’une intervention récente sur l’infrastructure d’un client dont nous assurons le maintien en condition opérationnelle : un certificat wildcard OV Sectigo, hérité de l’organisation mère, arrivait à échéance sous quinze jours. L’infrastructure est entièrement terraformée et l’ARN du certificat est exposé dans un paramètre SSM, mais le certificat lui-même échappait à cette automatisation : acheté auprès d’une autorité externe pour 150 à 400 € par an, importé dans ACM, réimporté manuellement à chaque échéance. La vérification qui précède tout renouvellement a rendu un verdict sans appel : le certificat que nous nous apprêtions à racheter « pour un an » ne pourra plus jamais durer un an.
Le calendrier SC-081v3
| À partir du | Validité max | Réutilisation de la validation de domaine (DCV) |
|---|---|---|
| 15 mars 2026 | 200 jours | 200 jours |
| 15 mars 2027 | 100 jours | 100 jours |
| 15 mars 2029 | 47 jours | 10 jours |
La troisième colonne mérite une attention particulière : à partir de 2029, la preuve de contrôle du domaine ne sera réutilisable que 10 jours et devra donc être refaite à quasiment chaque émission. Aucun processus manuel ne résiste à cette cadence.
Le ballot a été proposé par Apple, co-sponsorisé par Sectigo et adopté par 29 voix contre zéro, avec le vote favorable des quatre éditeurs de navigateurs. Qu’une autorité de certification co-signe la fin de son propre produit d’appel n’a rien d’une ironie : c’est un mouvement stratégique. Les navigateurs poussaient cette réduction depuis des années (Apple avait déjà imposé unilatéralement le plafond de 398 jours en 2020) et la bascule était inévitable ; en co-sponsorisant le calendrier, les autorités de certification en maîtrisent le rythme. Surtout, leur modèle économique s’est déplacé du certificat vendu à l’unité vers les souscriptions et les plateformes de gestion du cycle de vie des certificats, que des renouvellements toutes les six semaines rendent précisément indispensables. L’argument de sécurité est réel (réduire la fenêtre d’exploitation d’une clé de chiffrement compromise, compenser des mécanismes de révocation dont l’efficacité n’a jamais été satisfaisante), mais il converge avec l’intérêt commercial de ceux qui l’ont voté. La conséquence opérationnelle, elle, s’impose à tous : le certificat longue durée n’existe plus.
L’impact opérationnel
Un certificat émis aujourd’hui est plafonné à 200 jours (certaines autorités émettent à 199 jours par précaution). Une gestion manuelle implique donc un renouvellement semestriel dès maintenant, trimestriel à partir de 2027, puis toutes les six semaines en 2029, le tout multiplié par le nombre de certificats et d’environnements d’une stack multi-déployée.
Le modèle commercial des autorités de certification mérite également d’être décodé : elles continueront de vendre des souscriptions de un à trois ans, mais chaque certificat émis dans ce cadre reste soumis au plafond. La réémission et le redéploiement demeurent à votre charge à chaque cycle : vous prépayez en réalité plusieurs années d’une opération manuelle appelée à se multiplier.
Sur AWS : ACM rend la contrainte invisible
Le point décisif dans notre situation : ACM ne renouvelle jamais un certificat importé. Chaque échéance d’un certificat acheté puis importé exige un réimport manuel. À l’inverse, un certificat public émis par ACM est gratuit, se renouvelle automatiquement tant que l’enregistrement DNS de validation reste en place, et conserve le même ARN au fil des renouvellements : le paramètre SSM qui l’expose n’a plus jamais à être modifié. Amazon Trust Services est soumis au même calendrier SC-081v3 que Sectigo ; la différence est que ces renouvellements deviennent invisibles pour vos équipes.
resource "aws_acm_certificate" "wildcard" {
domain_name = "client.fr"
subject_alternative_names = ["*.client.fr"]
validation_method = "DNS"
lifecycle {
create_before_destroy = true
}
}
resource "aws_route53_record" "acm_validation" {
for_each = {
for dvo in aws_acm_certificate.wildcard.domain_validation_options : dvo.domain_name => {
name = dvo.resource_record_name
type = dvo.resource_record_type
record = dvo.resource_record_value
}
}
allow_overwrite = true
zone_id = data.aws_route53_zone.main.zone_id
name = each.value.name
type = each.value.type
ttl = 60
records = [each.value.record]
}
resource "aws_acm_certificate_validation" "wildcard" {
certificate_arn = aws_acm_certificate.wildcard.arn
validation_record_fqdns = [for r in aws_route53_record.acm_validation : r.fqdn]
}
resource "aws_ssm_parameter" "certificate_arn" {
name = "/infra/acm/wildcard_arn"
type = "String"
value = aws_acm_certificate.wildcard.arn
}Ce que ça fait :
- la validation DNS est posée dans Route 53 et n’est jamais supprimée, c’est elle qui permet à ACM de renouveler sans intervention
create_before_destroyévite toute interruption de service si le certificat doit être recréé- l’ARN publié dans SSM est stable, les ALB, CloudFront et API Gateway qui le consomment ne changent pas
Deux limites à connaître : les certificats ACM sont DV uniquement, et ils ne s’utilisent que sur les services managés AWS (ALB/NLB, CloudFront, API Gateway…), avec un certificat en us-east-1 pour CloudFront. Pour une terminaison TLS sur une instance EC2, placez un ALB en amont, utilisez l’option payante d’export d’ACM, ou revenez à un client ACME classique.
Hors AWS : ACME
Let’s Encrypt émet des certificats de 90 jours depuis 2015 sans que cela pose de difficulté à ses utilisateurs, précisément parce que le renouvellement y est automatisé de bout en bout. Pour un certificat wildcard, le challenge DNS-01 est requis, ce qui suppose un accès API à votre hébergeur DNS :
# Certbot + plugin DNS (exemple Cloudflare)
sudo apt install certbot python3-certbot-dns-cloudflare
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
-d "client.fr" -d "*.client.fr"Côté fournisseurs DNS français, acme.sh offre une couverture plus large (OVH, Gandi, Scaleway…) :
# Alternative acme.sh avec l'API OVH
curl https://get.acme.sh | sh -s email=ops@client.fr
export OVH_AK="app_key" OVH_AS="app_secret" OVH_CK="consumer_key"
acme.sh --issue -d client.fr -d '*.client.fr' --dns dns_ovhLe renouvellement s’exécute ensuite automatiquement (timer systemd pour certbot, tâche cron pour acme.sh), il ne reste qu’à recharger le service concerné via un hook de déploiement.
Le cas des certificats OV
Les navigateurs affichent les certificats DV et OV de manière strictement identique : l’OV ne se justifie plus que par une exigence contractuelle ou de conformité. Si c’est votre situation, les autorités commerciales exposent des endpoints ACME avec External Account Binding (chez Sectigo : --server https://acme.sectigo.com/v2/OV, complété des identifiants EAB fournis par le portail client). Vous conservez le niveau de validation OV et la facture qui l’accompagne, mais l’import manuel disparaît, ce qui est précisément l’objectif.
Les équipements sans support ACME
Certains équipements ne prennent pas en charge ACME : load balancer ancien, appliance VPN, logiciel métier qui n’accepte qu’un fichier PKCS#12 déposé dans une interface web. Deux approches sont possibles : sortir la terminaison TLS de l’équipement en plaçant devant lui un reverse proxy nginx ou HAProxy, qui s’automatise sans difficulté, ou scripter l’import via l’API de l’équipement dans un hook de déploiement. Avec une validité de 47 jours, l’import manuel dans une interface web cesse d’être un processus acceptable.
La PKI interne n’est pas concernée
SC-081v3 ne s’applique qu’aux certificats publiquement de confiance. Une CA privée pour du mTLS ou des services internes n’y est pas soumise, et c’est l’occasion de basculer ce qui n’a pas besoin d’être public vers une PKI privée (step-ca prend en charge ACME nativement) afin de sortir du périmètre.
Avant : un wildcard OV à 150-400 € par an, réimporté à la main dans ACM, valable 365 jours Après : un wildcard ACM gratuit, renouvelé sans intervention, ARN stable dans SSM
Le calendrier SC-081v3 s’appliquera quoi qu’il arrive : la seule décision qui vous appartient est d’automatiser maintenant, dans de bonnes conditions, plutôt qu’en 2029 au rythme d’un renouvellement toutes les six semaines.
Références
- Ballot SC-081v3 : le texte officiel du CA/Browser Forum
- Renouvellement géré ACM : pourquoi les certificats importés ne se renouvellent pas
- Documentation acme.sh DNS API : la liste des fournisseurs DNS supportés
