Depuis le 15 mars 2026, un certificat SSL public ne peut plus être émis pour plus de 200 jours, contre 398 auparavant. Pour la maintenance applicative, ce n'est pas un détail de site web : chaque API, portail ou connecteur exposé en HTTPS devra être renouvelé au moins deux fois par an, puis tous les 47 jours en 2029. Voici où se cachent les certificats que personne ne suit, et comment automatiser avant qu'une expiration ne coupe une intégration.

Ce qui a changé et ce qui arrive

Le calendrier vient du CA/Browser Forum, l'instance qui fixe les règles communes aux autorités de certification et aux navigateurs. Son vote SC-081v3, clos le 11 avril 2025, a été adopté sans aucune voix contre : 25 autorités de certification pour, 5 abstentions, et l'unanimité d'Apple, Google, Microsoft et Mozilla. Il fixe trois marches :

  • 15 mars 2026 : durée maximale de 200 jours (c'est le régime actuel) ;
  • 15 mars 2027 : 100 jours ;
  • 15 mars 2029 : 47 jours, avec une réutilisation de la preuve de contrôle du domaine ramenée à 10 jours.

Let's Encrypt, autorité gratuite très utilisée, va plus vite. Son annonce du 2 décembre 2025 prévoit des certificats de 64 jours sur son profil par défaut à partir du 10 février 2027, puis de 45 jours à partir du 16 février 2028, avec une réutilisation de la validation de domaine ramenée de 30 jours à 7 heures. Un profil optionnel émet déjà des certificats de 45 jours depuis le 13 mai 2026, utile pour tester votre chaîne dès maintenant.

Le motif est la sécurité : moins un certificat vit longtemps, moins il risque de rester valide après une fuite de clé ou un changement de propriétaire du domaine. Conséquence : le renouvellement manuel devient intenable, et Let's Encrypt le déconseille explicitement.

Pourquoi c'est un sujet d'application, pas seulement de site

Le certificat du site vitrine est en général bien suivi. Les incidents viennent de certificats installés à la mise en service d'une application métier, puis oubliés :

  • l'API qu'appelle votre application mobile ou votre site marchand ;
  • le point de réception des webhooks d'un prestataire de paiement ou d'un CRM ;
  • le serveur de synchronisation des tablettes de terrain ;
  • le connecteur qui dépose des fichiers chez un partenaire ;
  • l'équipement (pare-feu, boîtier de téléphonie, automate) dont le certificat se charge à la main par une interface d'administration.

Deux cas demandent une attention particulière. D'abord l'épinglage de certificat dans une application mobile : si l'application a été compilée avec l'empreinte exacte du certificat du serveur, chaque renouvellement la rend incapable de se connecter jusqu'à la publication d'une nouvelle version sur les magasins. Ensuite l'authentification par certificat client entre deux systèmes : depuis le 15 juin 2026, la politique du magasin de racines de Chrome refuse les nouveaux certificats serveur publics qui portent aussi l'usage d'authentification client. Les échanges machine à machine qui reposaient sur ce double usage doivent passer par une autorité privée dédiée.

Commencer par l'inventaire, pas par l'outil

On ne peut pas automatiser le renouvellement de certificats dont on ignore l'existence. L'inventaire tient dans un tableau de six colonnes :

  1. le nom de domaine ou l'adresse couverte ;
  2. le service qui l'utilise, décrit en langage métier (« réception des commandes du site ») et non en nom de serveur ;
  3. l'autorité émettrice et le type de validation ;
  4. le mode de renouvellement : automatique, semi-automatique ou manuel ;
  5. la date d'expiration actuelle ;
  6. le responsable nommé, personne et non service.

Trois sources le remplissent : la configuration des serveurs, les journaux publics de transparence des certificats, qui recensent tous ceux émis pour vos domaines, et les équipes métier, qui connaissent les échanges avec les partenaires. La colonne « mode de renouvellement » est la plus instructive : chaque ligne marquée « manuel » est une panne programmée dont la fréquence va doubler en mars 2027.

Automatiser le renouvellement, ligne par ligne

Le protocole ACME, celui de Let's Encrypt, est proposé par la plupart des autorités commerciales. Quatre réglages font la différence :

  • Renouveler aux deux tiers de la durée de vie, et non à intervalle fixe. Un renouvellement programmé tous les 60 jours, courant aujourd'hui, ne fonctionnera plus avec des certificats de 45 jours.
  • Activer ARI (ACME Renewal Information) lorsque votre client le permet : c'est l'autorité qui indique le moment conseillé pour renouveler, y compris de façon anticipée en cas de révocation massive.
  • Choisir la bonne méthode de validation. La validation par enregistrement DNS impose aujourd'hui de modifier le DNS à chaque renouvellement, donc de confier des droits sensibles au robot. Le CA/Browser Forum a adopté en octobre 2025 une méthode à enregistrement DNS persistant (vote SC-088v3), utilisable par les autorités depuis le 11 novembre 2025 et que Let's Encrypt prévoit de proposer : l'enregistrement est posé une fois, puis les renouvellements se font sans toucher au DNS.
  • Recharger le service après renouvellement : un certificat neuf posé sur le disque mais non chargé ne sert à rien.

Pour les équipements qui ne savent pas se renouveler seuls, deux options : placer devant eux un proxy qui porte le certificat public et se renouvelle automatiquement, ou programmer un script qui pousse le certificat par l'interface d'administration de l'équipement. Dans les deux cas, la ligne sort de la colonne « manuel ». Si l'application est ancienne et ne permet ni l'un ni l'autre, c'est souvent le signal qu'une modernisation est à envisager.

Reste à surveiller ce qui a été automatisé, car le risque se déplace de l'oubli vers l'échec silencieux. Let's Encrypt a cessé d'envoyer des courriels d'avertissement avant expiration le 4 juin 2025 ; si votre équipe comptait sur ces messages, le filet a déjà disparu. Il faut une sonde externe, indépendante du robot, qui lit la date d'expiration réellement présentée par chaque adresse de l'inventaire et alerte quand il reste moins d'un tiers de la durée de vie : plus de deux mois avec 200 jours, une quinzaine de jours avec 47.

Ce qu'il faut écrire dans le contrat de maintenance applicative

Les certificats tombent souvent entre l'hébergeur et le prestataire de maintenance. Quatre lignes lèvent l'ambiguïté :

  • la tenue de l'inventaire, avec sa mise à jour à chaque nouveau service ou nouveau partenaire ;
  • le renouvellement, service par service, en désignant qui le fait ;
  • la réception des alertes et le délai d'intervention avant échéance ;
  • la propriété des comptes ouverts auprès des autorités de certification, au nom de votre entreprise et non du prestataire.

Nous ajoutons un test annuel simple : choisir une ligne de l'inventaire et forcer son renouvellement en dehors du calendrier. Si l'opération prend plus d'une heure ou exige une personne précise, l'automatisation n'est pas terminée.

Les erreurs les plus fréquentes

  • Épingler le certificat exact dans une application mobile au lieu de la clé publique ou de l'autorité, ce qui transforme chaque renouvellement en mise à jour obligatoire.
  • Automatiser sans surveiller : le robot échoue sur un changement de DNS ou de pare-feu et personne ne le voit avant la coupure.
  • Attendre 2029 : chaque marche intermédiaire double la fréquence des interventions manuelles restantes.

Questions fréquentes

Mon application est-elle concernée si elle n'est pas un site web ?

Oui, dès qu'elle expose une adresse en HTTPS accessible depuis Internet avec un certificat émis par une autorité publique : API, portail, webhook, serveur de synchronisation mobile. Les certificats d'une autorité interne échappent à ce calendrier mais méritent le même inventaire.

Un certificat acheté en 2025 pour un an reste-t-il valable ?

Oui. Les nouvelles durées s'appliquent aux certificats émis après chaque échéance. Un certificat délivré avant le 15 mars 2026 reste valable jusqu'à sa date d'expiration ; c'est à son renouvellement que la durée maximale passe à 200 jours.

Let's Encrypt suffit-il pour une application métier ?

Pour la plupart des services exposés en HTTPS, oui, à condition que le renouvellement soit automatique, qu'il tolère des durées de 45 jours et qu'une alerte indépendante surveille l'expiration. Il ne convient pas aux usages exigeant un certificat client ou une validation d'organisation.

Qui doit surveiller les certificats : l'hébergeur ou le prestataire de maintenance ?

Le contrat doit trancher, en écrivant nommément qui tient l'inventaire, qui renouvelle chaque certificat et qui reçoit l'alerte, avec un délai d'intervention défini avant l'échéance.

Vous souhaitez savoir combien de certificats vivent réellement dans vos applications et lesquels se renouvellent encore à la main ? Nous réalisons l'inventaire et mettons en place le renouvellement automatique et sa surveillance. Parlons de votre projet.