Les durées de validité des certificats se raccourcissent : ce que TLS de 64 jours et 45 jours signifient pour les domaines personnalisés sur les tunnels

Le 10 février 2027, à environ trois mois à partir de maintenant, Let’s Encrypt fait passer la durée de vie par défaut des certificats de 90 jours à 64 jours. À peu près cinq semaines plus tard, le 15 mars 2027, le maximum industriel pour les certificats TLS publiquement approuvés passe de 200 jours à 100 jours. Aucun des deux changements n’est une surprise, et pourtant peu de développeurs se sont demandé ce que cela implique pour un domaine personnalisé pointé vers un tunnel.

Si vous faites passer app.yourdomain.com par un service de tunneling, un certificat se situe entre vos utilisateurs (ou vos expéditeurs de webhooks) et votre localhost. Quelqu’un doit le renouveler à chaque expiration, et cette horloge va accélérer. Ce guide couvre la chronologie exacte, comment le renouvellement et la vérification DNS fonctionnent derrière un tunnel, la différence entre les certificats gérés par le fournisseur et les certificats BYO (Bring-Your-Own), et les modes d’échec qui apparaissent lorsque le renouvellement s’arrête silencieusement.

La chronologie : Ce qui change réellement et quand

Deux calendriers distincts sont en jeu, et les gens les confondent souvent.

1. Le calendrier du CA/Browser Forum (s’applique à chaque CA publique)

En avril 2025 le CA/Browser Forum a adopté le Ballot SC-081v3. Il réduit à la fois la validité maximale des certificats et la période pendant laquelle une CA peut réutiliser une validation de domaine antérieure (DCV). Le vote a été adopté le 11 avril 2025, sans vote contre.

Date d’effet	Validité maximale du certificat	Réutilisation maximale de DCV
Jusqu’au 14 mars 2026	398 jours	398 jours
15 mars 2026 (déjà en vigueur)	200 jours	200 jours
15 mars 2027	100 jours	100 jours
15 mars 2029	47 jours	10 jours

2. Le calendrier de Let’s Encrypt (la CA la plus utilisée pour tunnel et ACME)

Let’s Encrypt avance plus vite que le mandat. Il atteindra 45 jours en 2028, un an avant le maximum de 47 jours du Forum.

Date	Profil ACME	Validité	Réutilisation d’autorisation
13 mai 2026 (en production)	tlsserver (optionnel)	45 jours	Non spécifié dans l’annonce
10 février 2027	classic (par défaut)	64 jours	10 jours (au lieu de 30)
16 février 2028	classic (par défaut)	45 jours	7 heures

Quelques détails des annonces de Let’s Encrypt :

• Le staging est en ligne maintenant. Les certificats de 64 jours sont disponibles dans l’environnement de staging de Let’s Encrypt depuis le 14 octobre 2026, vous pouvez donc tester votre configuration de renouvellement avant les changements en production.
• Les certificats existants ne sont pas révoqués. Let’s Encrypt prévoit que le dernier certificat de 90 jours expire le 11 mai 2027.
• Les utilisateurs des profils tlsserver (45 jours) ou shortlived (6 jours) ne sont pas affectés par le changement de février.
• La période de réutilisation d’autorisation courte est la partie discrète. À mesure que la fenêtre de réutilisation se rétrécit, vous prouvez le contrôle du domaine à peu près à chaque émission plutôt que de vous appuyer sur une validation mise en cache. Let’s Encrypt indique que cela supprime également le besoin de « vérification CAA » lorsque les données de validation ont plus de sept heures.

Si vous utilisez le profil par défaut et que vous n’avez jamais modifié les paramètres de votre client ACME, le changement de février 2027 s’applique automatiquement. C’est acceptable si votre renouvellement est réellement automatisé. C’est un problème si « automatisé » signifie une tâche cron à laquelle personne n’a plus touché depuis 2023.

Pourquoi les domaines personnalisés sur les tunnels constituent un cas particulier

Sur un serveur normal, vous détenez la clé privée et exécutez vous-même le client ACME. Avec un tunnel, l’entrée publique appartient au fournisseur, et votre domaine est un alias pointant vers lui. Cela répartit la responsabilité en trois volets :

• Le fournisseur termine TLS et (généralement) obtient et renouvelle le certificat.
• Vous contrôlez les enregistrements DNS qui rendent cette émission possible.
• Votre application locale ne voit jamais le certificat.

Des durées de vie plus courtes mettent surtout à rude épreuve la partie DNS de cet arrangement. Le processus de renouvellement du côté du fournisseur peut être sans faille et échouer quand même car un enregistrement de votre côté a dérivé.

Certificats gérés par le fournisseur : pratiques, pas invisibles

La plupart des plateformes de tunnel par défaut optent pour des certificats gérés, et la documentation de ngrok en est un exemple concret. Elle recommande des certificats automatiques sauf si vous avez des exigences particulières. Pour ceux-ci, elle provisionne et renouvelle des certificats à partir d’une CA ACME conforme telle que Let’s Encrypt. Elle utilise un défi HTTP-01 pour la plupart des domaines et passe à DNS-01 pour les domaines wildcard.

Pour un domaine de marque tel que api.your-domain.com, vous créez un enregistrement CNAME, et le provisioning ne commence pas tant que vous ne le faites pas. Pour un wildcard tel que *.app.example.com, vous avez besoin de deux CNAME : le wildcard lui-même et _acme-challenge.app.example.com.

Le provisioning est asynchrone. ngrok indique que cela prend généralement de quelques secondes à plusieurs minutes, et parfois plus longtemps si un défi DNS met du temps à se valider. Pendant son fonctionnement, ngrok sert son propre certificat wildcard par défaut. Ce certificat n’est pas délivré pour votre nom d’hôte, de sorte que les navigateurs et autres clients TLS affichent un avertissement de non-correspondance du nom d’hôte.

Cette documentation décrit un fournisseur, mais le schéma est courant. Elle vous dit ce qu’il faut surveiller sous des lifetimes plus courts :

1. Le CNAME est votre credential d’émission. Si quelqu’un “nettoie” DNS et le supprime, le provisioning ne peut pas poursuivre. À 398 jours vous pourriez ne pas remarquer pendant un an. À 64 jours vous le découvrez en environ deux mois, et à 45 jours en environ six semaines.
2. Les wildcard dépendent d’un second enregistrement. Le CNAME _acme-challenge est facile à oublier, car rien ne paraît brisé tant que le certificat n’a pas besoin d’être renouvelé.
3. Les certificats de secours ressemblent à une panne. Un avertissement d’inadéquation d’hôte est une erreur majeure pour de nombreux clients API et expéditeurs de webhooks, même si un humain peut cliquer pour passer.

Les certificats gérés ne suppriment pas vos obligations. Ils les limitent à une courte liste : garder les enregistrements DNS corrects et suivre le résultat.

BYO : Contrôle avec une taxe de rotation

Certaines équipes téléchargent leur propre certificat : issu d’une CA interne, un certificat EV, ou un certificat épinglé par un partenaire. Cela est légitime, et le compromis se précise à mesure que les lifetimes diminuent.

Avec ngrok, comme exemple, les certificats personnalisés signifient que vous êtes responsable du renouvellement et de la rotation. Vous téléchargez un bundle PEM comprenant d’abord le certificat final, suivi des intermédiaires, plus une clé privée non chiffrée. Puis vous attachez le certificat à un ou plusieurs domaines, car le créer seul ne modifie pas le trafic.

Sur ngrok, les certificats TLS sont disponibles sur tous les plans, mais les certificats BYO nécessitent le plan “pay-as-you-go”. Ils sont facturés à 0,27 $ par heure pour toute heure où au moins un point de terminaison utilisant ce certificat est actif. Un certificat wildcard est facturé une seule fois, et non par sous-domaine correspondant. Les tarifs et les règles de plan varient selon le fournisseur, vérifiez les vôtres.

Faisons maintenant les calculs de rotation pour un seul nom d’hôte :

Durée maximale	Rotations minimales par an
398 jours	1
200 jours	2
100 jours	4
64 jours	6
47 jours	8

Ce sont des minimums si vous remplacez chaque certificat exactement à son expiration. En renouvelant plus tôt, comme vous devriez le faire, le chiffre réel augmente.

Un processus manuel qui était tolérable une fois par an (télécharger, convertir, téléverser, attacher, tester) devient un coût opérationnel récurrent à six à huit fois par an par nom d’hôte, multiplié par chaque environnement. Si vous devez utiliser BYO, automatisez tout le parcours :

1. Votre client ACME obtient le certificat.
2. Un hook de déploiement le téléverse via l’API du fournisseur.
3. Une seconde étape l’attache au domaine.
4. Une vérification confirme l’expiration du certificat actif par la suite.

Traitez toute étape que vous ne pouvez pas automatiser comme celle qui échouera.

Le calendrier du Forum s’applique aux certificats publiquement approuvés. Un certificat émis par une CA privée en laquelle vos propres clients ont confiance échappe à ce cadre, mais cela n’aide pas lorsque des services externes appellent l’URL de votre tunnel.

Ce qui casse lorsque le renouvellement échoue silencieusement

« Silencieusement » est le mot-clé. Plusieurs éléments qui servaient de coussin face aux échecs le sont moins maintenant :

• Plus d’emails de rappel. Let’s Encrypt a mis fin à ses e-mails de notification d’expiration le 4 juin 2025. Il recommande désormais une surveillance tierce, et sa page de surveillance nomme Red Sift Certificates Lite, qui est gratuit jusqu’à 250 certificats. Si vous comptiez sur cet e-mail comme filet de sécurité, il est disparu.
• Des fenêtres plus courtes laissent moins de marge. Let’s Encrypt recommande de renouveler à environ les deux tiers de la durée de vie d’un certificat. Pour un certificat de 45 jours, cela signifie renouveler autour du jour 30, laissant environ 15 jours pour corriger un échec. Pour un certificat de 64 jours, c’est autour du jour 43, laissant environ trois semaines.
• La réutilisation diminue. Avec la réutilisation d’autorisation passant à 10 jours puis à 7 heures pour le profil par défaut de Let’s Encrypt, « ça a fonctionné la dernière fois » n’implique plus « ça fonctionnera cette fois ».

Modes d’échec typiques sur les domaines personnalisés des tunnels :

Échec	Symptôme probable
CNAME supprimé ou redirigé lors d’une migration DNS	Le provisioning ou le renouvellement ne peut pas poursuivre ; l’état du fournisseur affiche une erreur
Requête HTTP-01 bloquée par un pare-feu, WAF, ou une politique d’accès	Émission échouée après un changement de configuration
jeton API DNS expiré ou renouvelé (config DNS-01)	L’automatisation échoue dans les journaux que personne ne lit
Enregistrement CAA exclut la CA utilisée	Émission refusée
Ancien client ACME ou cron job abandonné	Aucune tentative de renouvellement
Certificat BYO téléchargé non remplacé	Le certificat expiré est toujours celui attaché au domaine

Deux détails des documents de Let’s Encrypt sont pertinents ici. Tout d’abord, HTTP-01 ne peut être effectué que sur le port 80. Sa validation peut suivre jusqu’à 10 redirections, mais uniquement vers les ports 80 ou 443. Deuxièmement, Let’s Encrypt vérifie les enregistrements CAA avant l’émission, et son identifiant CAA est letsencrypt.org.

Les fournisseurs de webhooks et les consommateurs d’API sont les moins tolérants. Une personne peut dépasser l’avertissement, mais un expéditeur automatisé échoue généralement dès la poignée de main TLS, et le premier signe est l’absence d’événements plutôt qu’une page d’erreur visible.

Calendrier de renouvellement : stop à l’utilisation de décalages fixes

De nombreux outils étaient configurés pour des certificats de 90 jours avec une règle fixe, telle que « renouveler lorsque 30 jours restent » ou « renouveler tous les 60 jours ». Les conseils de Let’s Encrypt sont sans équivoque. Un intervalle codé en dur de 60 jours n’est plus suffisant pour les certificats de 45 jours. Il suggère de rechercher dans les cron jobs, scripts wrapper et runbooks des chiffres codés comme 83, 80 ou 60. Tout ce qui attend 80 jours manquera complètement un certificat de 64 jours.

La meilleure réponse est ACME Renewal Information (ARI), normalisée comme RFC 9773. La CA indique au client quand renouveler, et les clients doivent renouveler dans la fenêtre suggérée. Let’s Encrypt recommande l’ARI, et dit que si votre client ne le supporte pas, renouveler à environ les deux tiers de la durée de vie du certificat est acceptable.

Certbot a vérifié l’ARI automatiquement lorsque la CA le prend en charge depuis la version 4.1.0 (juin 2025). D’autres clients diffèrent, alors vérifiez votre client et votre version spécifiques plutôt que d’en supposer. Pour les fournisseurs de tunnels, demandez si leur pipeline de renouvellement utilise un minutage basé sur ARI, car vous n’en contrôlez pas le fonctionnement.

Vérification DNS sous des lifetimes plus courts

HTTP-01 vs DNS-01

HTTP-01 est simple pour les noms d’hôtes uniques : la CA récupère un jeton sur votre site. Sur un tunnel, le fournisseur répond généralement pour vous une fois que le CNAME est en place. DNS-01 est requis pour les wildcards et fonctionne là où HTTP-01 ne peut pas, mais il nécessite un accès en écriture DNS à chaque émission. Let’s Encrypt note que placer des identifiants complets de l’API DNS sur un serveur web augmente l’impact d’une compromission. Il recommande des identifiants à portée limitée, ou une validation à partir d’un serveur distinct.

Déléguer le défi plutôt que de partager les clés DNS

Let’s Encrypt suit les recherches DNS standard pour la validation DNS-01, vous pouvez donc utiliser des enregistrements CNAME ou NS pour déléguer le nom _acme-challenge à une autre zone. Cela vous permet de pointer _acme-challenge.yourdomain.com vers une zone réservée à l’automatisation, avec des identifiants limités à cette zone. Le support client pour suivre la délégation varie, confirmez le vôtre et testez avec une exécution à blanc avant de vous y appuyer.

DNS-PERSIST-01 : une nouvelle option à surveiller

Let’s Encrypt décrit un nouveau type de défi, DNS-PERSIST-01, basé sur un brouillon IETF. Au lieu de publier un nouveau jeton à chaque émission, vous publiez un enregistrement TXT permanent à _validation-persist.<domain> qui nomme la CA et votre compte ACME spécifique. Les renouvellements n’ont alors plus besoin de modifications DNS, de sorte que l’accès en écriture DNS peut être verrouillé après la mise en place. La portée et la durée de vie sont contrôlées par des paramètres optionnels. policy=wildcard élargit l’autorisation aux certificats wildcard et aux sous-domaines correspondants. persistUntil définit un horodatage d’expiration. Sans date d’expiration, l’autorisation est valable indéfiniment, alors définissez un rappel de surveillance. Étant donné que l’enregistrement persiste, protéger la clé de votre compte ACME devient la préoccupation centrale. Le CA/Browser Forum a approuvé la méthode de validation sous-jacente dans le ballot SC-088v3 en octobre 2025.

Let’s Encrypt visait un déploiement en production au deuxième trimestre 2026, en commençant par le staging. Je n’ai pas trouvé de confirmation qu’il soit en production. Des discussions communautaires jusqu’en juillet 2026 décrivaient le brouillon IETF comme encore en cours d’affinage et indiquaient qu’aucune CA publique n’avait d’implémentation en production. Considérez-le comme quelque chose à planifier plutôt que sur lequel compter. Cela dépend aussi de si votre fournisseur de tunnel le prend en charge, pas seulement de votre propre client ACME, car sur un domaine géré, le fournisseur détient le compte ACME.

Liste de contrôle pratique pour les domaines personnalisés sur les tunnels

Avant le 10 février 2027

1. Inventorier chaque nom d’hôte personnalisé et noter qui le renouvelle : le fournisseur, votre client ACME, ou une personne.
2. Vérifiez les enregistrements DNS (la cible CNAME, et _acme-challenge pour les wildcard) par rapport aux instructions actuelles de votre fournisseur.
3. Vérifiez les enregistrements CAA pour confirmer qu’ils permettent la CA qui émet effectivement.
4. Testez le renouvellement de bout en bout. Exécutez votre client ACME sur Let’s Encrypt staging, qui a émis des certificats de 64 jours depuis le 14 octobre. Pour les domaines gérés, confirmez que le champ d’état ou le tableau de bord du fournisseur affiche un certificat sain.
5. Mettez à jour les anciens clients. Assurez-vous que le vôtre prend en charge les profils ACME et l’ARI, et supprimez les décalages de renouvellement codés en dur.

En continu

1. Surveillez le certificat actif, pas le travail.
2. Alertez sur le dérive DNS. Une vérification planifiée qui vérifie que vos CNAME continuent de résoudre les cibles attendues permet d’attraper les échecs les plus courants des certificats gérés.
3. Documentez la propriété. Lorsque la personne qui a configuré le domaine part, le processus de renouvellement ne doit pas partir avec elle.
4. Répétez le scénario d’échec. Connaissez les étapes de récupération manuelles (recréer l’enregistrement, déclencher une réémission, ré-téléverser) avant d’en avoir besoin à 2 heures du matin.

Gestion par le fournisseur ou BYO ? Guide rapide de décision

Situation	Meilleur choix
Site public standard, webhooks, API sur un domaine personnalisé	Géré par le fournisseur
Petite équipe, sans opérations dédiées	Géré par le fournisseur
Exigence contractuelle pour une CA ou type de certificat spécifique	BYO, avec téléversement automatisé
Certificat épinglé par un partenaire	BYO, avec un runbook de rotation
Wildcard sur de nombreux tunnels	Géré avec délégation DNS-01, ou BYO avec automatisation

Pour la plupart des développeurs, la voie gérée est adaptée, et des lifetimes plus courts renforcent l’argument. Un fournisseur qui renouvelle en continu fait le travail que vous écririez vous-même via des scripts.

Où les domaines personnalisés Pro s’insèrent

Les domaines personnalisés sont le point où un tunnel cesse d’être une URL jetable et devient partie intégrante de votre infrastructure : un nom d’hôte stable pour les webhooks, les démos, le staging ou l’aperçu client. Cela fait de la gestion des certificats une partie de ce que vous achetez. En évaluer un plan de domaine personnalisé Pro auprès d’un fournisseur de tunnels, posez les questions suivantes :

• Les certificats sont-ils émis et renouvelés automatiquement, et que se passe-t-il pour le nom d’hôte si le renouvellement échoue ?
• Quels types de défis et quels enregistrements DNS sont requis, et puis-je voir l’état et l’expiration du certificat dans un tableau de bord ou une API ?
• La prise en charge du wildcard est-elle disponible, et comment l’enregistrement _acme-challenge est-il géré ?
• Puis-je apporter mon propre certificat, et le rotation via une API est-elle scriptable ? À quel coût ?
• Comment le fournisseur vous avertit-il avant l’expiration, étant donné que les e-mails de rappel de Let’s Encrypt n’existent plus ?

Un plan qui répond clairement à ces questions transforme les changements à 64 et 45 jours en une simple formalité.

Questions fréquemment posées

Le changement à 64 jours est-il une règle du CA/Browser Forum ?
Non. Le défaut à 64 jours est l’étape intermédiaire propre à Let’s Encrypt. Le maximum actuel du CA/Browser Forum est de 200 jours, tombant à 100 le 15 mars 2027.

Dois-je faire quelque chose si mon fournisseur de tunnel gère les certificats ?
Principalement: garder vos enregistrements DNS intacts et surveiller le certificat que votre nom d’hôte sert réellement.

Les certificats Let’s Encrypt deviendront-ils 47 jours ?
Non. Let’s Encrypt prévoit 45 jours à partir du 16 février 2028, légèrement en dessous du maximum éventuel de 47 jours du Forum en 2029.

Que se passe-t-il avec mes certificats de 90 jours existants ?
Ils restent valides jusqu’à leur expiration, et aucun n’est révoqué dans le cadre du changement. Let’s Encrypt prévoit que le dernier certificat de 90 jours expirerait le 11 mai 2027. Tout ce qui est émis ou renouvelé à partir du 10 février 2027 reçoit 64 jours.

Cela s’applique-t-il aux certificats auto-signés ou à ceux d’une private-CA ?
Le calendrier porte sur les certificats TLS publiquement approuvés, donc les PKI privés échappent à ce cadre, bien que des appelants externes n’aient pas confiance en de tels certificats.

Points clés

• Les dates clés sont 10 février 2027 (Let’s Encrypt passe à 64 jours), 15 mars 2027 (maximum industriel à 100 jours), 16 février 2028 (Let’s Encrypt passe à 45 jours), et 15 mars 2029 (maximum à 47 jours, réutilisation DCV à 10 jours).
• Sur les tunnels, le risque est rarement le moteur de renouvellement du fournisseur. Ce sont plutôt la dérive DNS, les identifiants expirés et les certificats BYO que personne n’a tourné.
• Surveiller le certificat servi externement, car les e-mails de rappel de Let’s Encrypt ont pris fin en juin 2025.
• Remplacez les offsets de renouvellement codés en dur par ARI ou un renouvellement à environ les deux tiers de la durée de vie.
• Préférez les certificats gérés sauf si une exigence réelle dit autrement, et automatisez chaque étape si vous apportez votre propre.

Sources

• Calendrier du CA/Browser Forum Ballot SC-081v3 : SSLInsights, Odown, DNSimple
• Let’s Encrypt / ISRG : Decreasing Certificate Lifetimes to 45 Days
• Let’s Encrypt: 64-Day Certificate Lifetimes Coming Feb 2027
• Let’s Encrypt: DNS-PERSIST-01
• Let’s Encrypt community: DNS-PERSIST-01 deployment status et win-acme discussion
• Let’s Encrypt: Expiration Notification Service Has Ended
• Let’s Encrypt: Monitoring Service Options
• Let’s Encrypt: Challenge Types
• Let’s Encrypt: CAA
• ngrok: TLS certificates documentation
• Certbot 4.1.0 release (ARI support)
• IETF: ACME Renewal Information, RFC 9773