Certificats TLS 200 jours : préparer vos serveurs en 2026

La gestion des certificats TLS devient un sujet d’exploitation à part entière. À compter du 15 mars 2026, les certificats TLS publics nouvellement émis ne pourront plus avoir une durée de validité supérieure à 200 jours. Ce plafond, inscrit dans les exigences du CA/Browser Forum, remplace progressivement le maximum de 398 jours longtemps utilisé par les autorités de certification.

Pour un site web simple, la conséquence paraît modérée : il faut renouveler plus souvent. Pour une entreprise qui exploite plusieurs VPS, des serveurs dédiés, des reverse proxies, des environnements Kubernetes, des API et des sous-domaines clients, le changement est bien plus structurant. Un certificat oublié peut interrompre un site, une passerelle VPN, une API de paiement, un outil interne ou un service de messagerie.

Le bon réflexe n’est donc pas de raccourcir une tâche calendaire annuelle : il faut mettre en place un cycle de vie automatisé, observable et testé. Ce guide présente les impacts concrets de la limite de 200 jours et une méthode pragmatique pour fiabiliser les renouvellements TLS sur VPS et serveurs dédiés.

Pourquoi la validité maximale des certificats TLS passe à 200 jours

Les certificats TLS publics permettent à un navigateur, une application ou un client API de vérifier l’identité d’un serveur et de chiffrer les échanges avec lui. Ils sont émis par des autorités de certification (AC), telles que Let’s Encrypt, DigiCert, Sectigo, GlobalSign ou ZeroSSL, dont les certificats racines sont reconnus par les navigateurs et systèmes d’exploitation.

La durée de vie des certificats publics a déjà été raccourcie à plusieurs reprises. Depuis 2020, les certificats TLS publics ont une validité maximale de 398 jours. La nouvelle trajectoire adoptée par le CA/Browser Forum va plus loin :

• à partir du 15 mars 2026, la validité maximale sera de 200 jours ;
• à partir du 15 mars 2027, elle passera à 100 jours ;
• à partir du 15 mars 2029, elle sera limitée à 47 jours.

Ces plafonds s’appliquent aux certificats nouvellement émis, et non aux certificats déjà déployés. Un certificat délivré avant la date concernée conserve sa date d’expiration initiale, mais son prochain renouvellement devra respecter les nouvelles règles.

Le même mouvement concerne la réutilisation de la validation de contrôle de domaine, ou Domain Control Validation (DCV). En pratique, une AC ne pourra pas s’appuyer indéfiniment sur une validation antérieure d’un nom de domaine pour émettre un nouveau certificat. L’automatisation devra donc non seulement demander le certificat, mais aussi réussir régulièrement la preuve de contrôle du domaine.

L’objectif est de réduire la période pendant laquelle un certificat compromis, mal configuré ou associé à un domaine dont le contrôle a changé reste exploitable. Des certificats plus courts limitent cette fenêtre, mais transfèrent aussi une part de l’effort vers les équipes d’infrastructure. Le renouvellement manuel devient une procédure fragile, particulièrement à l’approche du plafond de 100 puis de 47 jours.

Quels certificats et services sont réellement concernés

La règle vise principalement les certificats TLS publics, c’est-à-dire ceux utilisés pour des noms de domaine accessibles et vérifiables sur Internet : www.exemple.fr, api.exemple.fr ou client.exemple.com. Elle concerne les certificats DV, OV et EV émis par des AC publiques.

Les certificats internes ne sont pas automatiquement soumis au même plafond lorsqu’ils sont émis par une autorité de certification privée, par exemple Microsoft Active Directory Certificate Services, HashiCorp Vault PKI, Smallstep ou une PKI interne. Cela ne signifie pas qu’il faut les ignorer : une politique de rotation régulière des certificats internes reste une bonne pratique, notamment pour les API, les clusters Kubernetes et l’authentification mutuelle TLS.

En revanche, il serait risqué de considérer qu’un service est « interne » parce qu’il n’est pas affiché dans le menu d’un site. Beaucoup d’infrastructures utilisent des certificats publics sur :

• les interfaces d’administration de reverse proxies ou de plateformes SaaS ;
• les endpoints d’API, webhooks et passerelles d’intégration ;
• les portails clients, extranets et outils de support ;
• les services VPN publiés sous un nom DNS ;
• les dépôts Git, registries de conteneurs et outils CI/CD ;
• les services de messagerie comme SMTP, IMAP ou les webmails ;
• les load balancers, CDN et pare-feux applicatifs qui terminent TLS.

La difficulté provient souvent de la répartition de la terminaison TLS. Le certificat n’est pas nécessairement installé sur le VPS qui héberge l’application. Il peut être géré par Cloudflare, par un Application Load Balancer, par un contrôleur Ingress Kubernetes, par HAProxy, Nginx, Traefik, Caddy ou par un équipement réseau. Toute stratégie de renouvellement doit donc identifier l’endroit exact où le certificat est présenté au client.

Les risques opérationnels pour un VPS, un dédié et une architecture distribuée

Le premier risque est évident : un certificat expiré provoque une alerte bloquante dans les navigateurs modernes. Selon le client utilisé, une application peut aussi refuser la connexion TLS. Pour un site e-commerce ou une API B2B, quelques minutes d’indisponibilité peuvent suffire à bloquer des commandes, des échanges automatisés ou des opérations métier.

Le raccourcissement à 200 jours augmente la fréquence des opérations. Un certificat annuel renouvelé manuellement une fois par an devient un certificat à traiter au moins deux fois par an, sans compter les réémissions après une modification de noms DNS, une compromission de clé privée ou une migration d’infrastructure. Dès 2029, une validité maximale de 47 jours rend le renouvellement manuel irréaliste en production.

Les incidents ne viennent pas toujours de l’émission elle-même. Une commande de renouvellement peut réussir sur le serveur, tandis que le certificat actif reste l’ancien parce que :

• Nginx, Apache HTTP Server, HAProxy ou un autre service n’a pas été rechargé ;
• le chemin configuré pointe vers un ancien fichier PEM ;
• le certificat a été renouvelé sur un nœud mais pas synchronisé sur les autres ;
• le CDN, le load balancer ou le WAF possède son propre certificat ;
• le challenge ACME échoue à cause d’un pare-feu, d’une redirection, d’un proxy ou d’une zone DNS ;
• un certificat multi-domaines contient un nom désormais impossible à valider.

Les serveurs dédiés administrés à la main sont particulièrement exposés si les secrets et les configurations sont dispersés. À l’inverse, une plateforme Kubernetes peut renouveler correctement un certificat via cert-manager, tout en échouant sur une application historique placée derrière un proxy indépendant. L’inventaire et la supervision transversale restent donc indispensables.

Cette évolution doit aussi être rapprochée des mesures de base de sécurisation d’un serveur Linux. Un compte capable de modifier une zone DNS, de demander un certificat ou de lire une clé privée est sensible. L’automatisation réduit les oublis humains, mais elle doit être protégée par des droits minimaux, une gestion saine des secrets et des journaux exploitables.

ACME : la base d’un renouvellement de certificats sans intervention manuelle

Le protocole ACME standardise les échanges entre un client et une autorité de certification pour créer un compte, prouver le contrôle d’un domaine, demander un certificat et le renouveler. Let’s Encrypt a largement contribué à sa diffusion, mais ACME n’est pas limité à Let’s Encrypt.

Sur un VPS ou un serveur dédié, plusieurs clients ACME sont couramment utilisés :

• Certbot, client largement documenté, notamment adapté à Nginx et Apache ;
• acme.sh, script shell compatible avec de nombreux fournisseurs DNS ;
• lego, client ACME écrit en Go ;
• Caddy, serveur web capable d’automatiser l’obtention et le renouvellement de certificats pour les sites configurés ;
• Traefik, reverse proxy qui prend en charge ACME dans les architectures conteneurisées.

Le mécanisme ne doit pas être réduit à une tâche cron qui exécute une commande. Une automatisation fiable comporte plusieurs étapes : vérifier la nécessité d’un renouvellement, accomplir la validation du domaine, télécharger les nouveaux fichiers, déployer la chaîne et la clé privée au bon emplacement, recharger le service concerné, puis contrôler le certificat réellement exposé sur le réseau.

Pour Nginx ou Apache, Certbot peut gérer l’obtention de certificats et proposer des intégrations avec le serveur web. Dans une architecture plus contrôlée, il peut être préférable de séparer l’émission et le déploiement : le client ACME dépose les fichiers, puis un deploy hook vérifie leur présence et exécute un rechargement gracieux du service. Nginx accepte par exemple un rechargement de configuration sans interrompre les connexions existantes lorsque celle-ci est valide.

Avant de confier un renouvellement à la production, utilisez l’environnement de préproduction de votre AC lorsque celui-ci est disponible. Let’s Encrypt fournit un environnement de test distinct, utile pour valider la configuration sans consommer les limites appliquées par son service de production.

HTTP-01 ou DNS-01 : choisir la validation adaptée à l’infrastructure

ACME propose plusieurs méthodes de validation. Le choix a un impact direct sur la robustesse de l’automatisation.

HTTP-01 pour les services web simples et directement accessibles

Avec le challenge HTTP-01, l’AC demande la publication temporaire d’un fichier sous le chemin /.well-known/acme-challenge/ sur le domaine à certifier. L’AC tente ensuite de le récupérer en HTTP. C’est une solution pratique pour un site ou une API accessible publiquement, à condition que le port 80 soit joignable et que le reverse proxy transmette correctement ce chemin.

Cette méthode convient souvent à un VPS mono-site avec Nginx ou Apache. Elle devient plus délicate quand un CDN, une redirection globale, plusieurs nœuds ou des règles de sécurité interceptent la requête. Une redirection HTTP vers HTTPS est en général compatible si elle est correctement configurée, mais il faut toujours tester le chemin de challenge dans les conditions réelles.

DNS-01 pour les wildcard, les services internes et le multi-site

Le challenge DNS-01 demande la création d’un enregistrement TXT sous _acme-challenge dans la zone DNS. Il est indispensable pour émettre un certificat wildcard, tel que *.exemple.fr. Il est aussi souvent plus approprié lorsque le serveur n’est pas directement exposé sur Internet ou quand la terminaison TLS est répartie sur plusieurs équipements.

Son intérêt majeur est de dissocier la validation DNS de l’accès HTTP au serveur. Par exemple, un certificat destiné à un reverse proxy HAProxy sur un réseau privé peut être validé par DNS-01, puis déployé sur le proxy sans ouvrir un flux HTTP entrant uniquement pour ACME.

DNS-01 exige toutefois une discipline stricte : le jeton API du fournisseur DNS permet parfois de modifier toute une zone, voire tous les domaines d’un compte. Préférez un jeton limité à la zone concernée et, lorsque le fournisseur le permet, limité aux droits nécessaires à la modification des enregistrements DNS. Des services comme Cloudflare, OVHcloud, Gandi ou Amazon Route 53 proposent des interfaces API ; la compatibilité précise dépend ensuite du client ACME retenu.

Pour une délégation propre, il est aussi possible de déléguer uniquement le sous-domaine _acme-challenge.exemple.fr via un enregistrement CNAME vers une zone dédiée. Cette approche évite de déposer des identifiants très puissants sur chaque serveur chargé du renouvellement.

Superviser le certificat déployé, pas seulement la tâche de renouvellement

Un journal systemd indiquant que Certbot s’est exécuté n’est pas une preuve qu’un certificat valide est servi aux utilisateurs. La supervision doit interroger le service exposé et vérifier au minimum le nom présenté, la chaîne de certification et la date d’expiration.

Plusieurs solutions peuvent participer à ce contrôle :

• Uptime Kuma peut surveiller des services HTTPS et alerter en cas de problème ;
• Zabbix propose des mécanismes de supervision adaptés aux infrastructures hétérogènes ;
• Prometheus, associé à un exporteur tel que cert-exporter ou à une sonde adaptée, permet de centraliser des métriques et alertes ;
• Blackbox Exporter de Prometheus peut vérifier un endpoint HTTPS depuis le réseau ;
• OpenSSL reste utile pour un contrôle ponctuel en ligne de commande.

Un contrôle externe avec OpenSSL peut ressembler à ceci :

openssl s_client -connect www.exemple.fr:443 -servername www.exemple.fr < /dev/null 2>/dev/null | openssl x509 -noout -dates -issuer -subject

L’option -servername est importante : elle envoie l’indication SNI et permet de vérifier le bon certificat sur un serveur qui héberge plusieurs domaines. Dans un contexte de monitoring, configurez des alertes graduées. Une alerte plusieurs semaines avant l’échéance laisse le temps de diagnostiquer un problème DNS ou d’autorisation. Une seconde alerte plus proche de l’expiration sert de filet de sécurité.

Surveillez également les erreurs de renouvellement, les changements de droits sur les fichiers de clé, les échecs de rechargement du proxy et les limites de requêtes de l’AC. Une supervision bien conçue doit détecter aussi bien le certificat expirant que la chaîne de déploiement cassée.

Plan de migration TLS : audit, tests et déploiement progressif

La préparation à la limite de 200 jours peut être organisée sans attendre le dernier renouvellement. L’objectif est d’avoir un processus qui fonctionne déjà avec des certificats de courte durée avant que les plafonds futurs ne le rendent obligatoire.

1. Réaliser un inventaire des noms et des points de terminaison

Établissez la liste des domaines, sous-domaines, adresses IP et ports TLS exposés. Ajoutez le propriétaire du service, l’emplacement de terminaison TLS, l’autorité de certification, le type de validation, la date d’expiration et la méthode de renouvellement actuelle. N’oubliez pas les environnements de préproduction, les domaines historiques et les services non web.

Pour les applications modernes, confrontez cet inventaire aux configurations DNS, aux fichiers Nginx ou HAProxy, aux Ingress Kubernetes et aux comptes CDN. Un outil de découverte ne remplace pas la connaissance des équipes : un nom non référencé dans le DNS public peut encore être utilisé par des partenaires ou des clients mobiles.

2. Éliminer les renouvellements dépendants d’une personne

Un tableur avec une date de rappel, une adresse e-mail personnelle et une procédure non documentée constitue un risque opérationnel. Identifiez les certificats renouvelés depuis une console web, un poste de travail ou un compte individuel. Priorisez leur passage vers ACME ou, si l’AC choisie ne propose pas ACME, vers un mécanisme automatisable et documenté.

Les certificats OV ou EV peuvent répondre à des contraintes spécifiques d’organisation ou de conformité. Leur émission implique des vérifications supplémentaires, mais leur déploiement doit tout de même être industrialisé. Vérifiez directement auprès de votre AC les méthodes d’automatisation disponibles et les contraintes de votre produit.

3. Tester le renouvellement avant l’échéance

Un renouvellement non testé est une promesse, pas une garantie. Testez le challenge depuis l’environnement de préproduction de l’AC, le déploiement des fichiers, le rechargement du service et le contrôle HTTPS externe. Documentez les dépendances : ouverture du port 80, droits du compte de service, accès au fournisseur DNS, volume de stockage, configuration du pare-feu et réplication éventuelle entre nœuds.

Dans une configuration haute disponibilité, déterminez clairement où s’exécute le client ACME. Deux nœuds ne doivent pas se concurrencer sans coordination pour demander le même certificat. Vous pouvez centraliser l’émission puis distribuer les fichiers de manière sécurisée, ou déléguer la terminaison TLS à un composant unique comme un load balancer. Le choix dépend de l’architecture, mais il doit être explicite.

4. Prévoir la restauration et la rotation des clés

Sauvegardez les configurations, les comptes ACME et les éléments nécessaires à la reconstruction du service, sans exposer les clés privées. Les clés et certificats déployés doivent avoir des permissions restrictives. Après une compromission présumée de clé, la bonne réponse n’est pas seulement de renouveler : il faut générer une nouvelle clé privée, réémettre le certificat et analyser la cause de l’exposition.

La stratégie de sauvegarde mérite elle aussi une attention particulière. Retrouvez les principes de rétention, d’isolation et de restauration dans notre guide sur la sauvegarde immuable pour VPS et serveurs dédiés.

Bonnes pratiques pour les infrastructures multi-domaines et internes

Un certificat multi-domaines, souvent appelé SAN, peut simplifier une configuration en regroupant plusieurs noms. Mais il accroît aussi le périmètre d’un incident : si un seul domaine ne peut plus être validé lors du renouvellement, le processus peut échouer selon la demande effectuée. Regroupez les noms qui ont le même cycle de vie et le même propriétaire, plutôt que de créer un certificat géant pour toute l’entreprise.

Les certificats wildcard réduisent le nombre de certificats à gérer, mais ils ne couvrent qu’un niveau de sous-domaine. Un certificat pour *.exemple.fr ne couvre pas api.dev.exemple.fr, ni le domaine racine exemple.fr. Il impose par ailleurs DNS-01, donc une gestion rigoureuse des accès à la zone DNS.

Pour les services internes, évitez de contourner le sujet en désactivant la vérification TLS côté client. Utilisez une PKI interne avec une chaîne de confiance correctement distribuée sur les machines et applications. Des outils comme HashiCorp Vault PKI ou Smallstep peuvent aider à émettre des certificats internes à courte durée, mais leur adoption requiert un modèle d’exploitation clair : autorité racine protégée, autorités intermédiaires, révocation si nécessaire, distribution des CA de confiance et renouvellement automatisé.

Enfin, traitez le certificat comme du code d’infrastructure : configuration versionnée, secrets séparés du dépôt, déploiement reproductible et alertes centralisées. Cette approche s’intègre naturellement à une stratégie plus large de supervision ; notre comparatif des outils open source de monitoring serveur peut aider à choisir une base adaptée à votre parc.

Conclusion : transformer une contrainte de 200 jours en procédure fiable

La limite de 200 jours applicable aux certificats TLS publics émis à partir du 15 mars 2026 n’est qu’une étape : les plafonds prévus pour les années suivantes imposent d’abandonner durablement les renouvellements manuels. L’enjeu n’est pas simplement d’obtenir un certificat plus souvent, mais de garantir qu’il est validé, déployé, activé et surveillé sur chaque point de terminaison.

Commencez par inventorier vos certificats et vos domaines, automatisez les cas les plus simples avec ACME, privilégiez DNS-01 lorsque l’architecture le justifie, puis testez le cycle complet avant une expiration réelle. Une fois cette base en place, la réduction de durée devient une routine d’exploitation plutôt qu’une source d’incidents. Pour compléter ce chantier, consultez aussi notre guide de durcissement Linux et intégrez la gestion TLS à vos procédures d’administration courantes.