Liste de vérification de l'infrastructure de redirection pour l'ère des certificats de 45 jours

Les durées de validité des certificats SSL vont bientôt être réduites de moitié. Let's Encrypt — qui alimente 60 % de tous les certificats web — passe de 90 jours à 45 jours maximum. La proposition du Google CA/Browser Forum va dans le même sens. L’ensemble de l’industrie des certificats pousse vers des durées plus courtes comme standard de sécurité, et le calendrier n’est désormais plus théorique.

Pour les équipes qui gèrent une infrastructure de redirection sur des centaines ou des milliers de domaines, ce n’est pas un simple ajustement — c’est un multiplicateur opérationnel. Ce qui nécessitait 4 cycles de renouvellement par domaine et par an en exigera bientôt 8. Les processus manuels qui fonctionnaient à peine à 90 jours échoueront complètement à 45.

Cette checklist est conçue pour aider les équipes d’infrastructure à évaluer leur niveau de préparation sur six domaines critiques : l’automatisation, la supervision, le calendrier de renouvellement, l’alerte, la stratégie wildcard et la reprise après sinistre. Chaque section inclut une question d’auto-évaluation et un état cible. À la fin, vous aurez une vision claire de la position de votre infrastructure — et de ce qui doit changer avant l’arrivée de l’ère des 45 jours.

1. Automatisation : Cycle de vie des certificats sans intervention#

La question la plus importante de votre évaluation de préparation : chaque certificat émis et renouvelé sans intervention humaine ?

Si la réponse n’est pas un « oui » sans réserve, vous avez un problème. À des durées de 45 jours, les opérations manuelles de certificats deviennent intenables à des échelles étonnamment faibles. Un portefeuille de seulement 50 domaines nécessite 400 opérations de certificats par an — plus d’une par jour, tous les jours, y compris les week-ends et les jours fériés.

Auto-évaluation de l’état actuel : comment votre équipe gère-t-elle aujourd’hui l’approvisionnement des certificats ? Si la réponse implique des rappels calendrier, des tableurs, la génération manuelle de CSR, ou « quelqu’un s’en occupe généralement », vous êtes dans la catégorie manuelle. Même si vous avez automatisé des parties du workflow, demandez-vous si le script couvre chaque domaine, gère chaque cas limite et se remet de chaque échec sans escalade humaine.

État cible : chaque nom d’hôte de votre infrastructure de redirection s’approvisionne automatiquement en SSL via ACME dès que le DNS est configuré. L’émission, l’installation et le renouvellement des certificats se font sans aucune action humaine. Le système détecte les nouveaux domaines, valide la propriété via le défi DNS-01, demande le certificat, l’installe sur les nœuds de bord, puis planifie le prochain renouvellement — le tout en quelques secondes après l’ajout du nom d’hôte.

Une plateforme de redirection qui gère le SSL par nom d’hôte — plutôt que de vous obliger à gérer des certificats par serveur — élimine entièrement l’écart d’automatisation. Lorsque le DNS est délégué à la plateforme, le SSL devient une propriété de l’infrastructure, et non une tâche sur la liste de quelqu’un.

2. Supervision : Savoir avant que ça ne casse#

Demandez-vous : disposez-vous d’un suivi actif de l’expiration des certificats pour tous les domaines ?

Le monitoring est le filet de sécurité sous l’automatisation. Même avec un renouvellement basé sur ACME, des problèmes peuvent survenir : un enregistrement DNS change, une limite de débit est atteinte, une autorité de certification (CA) subit une panne. Sans monitoring, vous découvrez les certificats expirés de la même manière que vos utilisateurs — via un avertissement du navigateur.

Mais le monitoring ne consiste pas seulement à vérifier les dates d’expiration. Un monitoring efficace pour l’infrastructure de redirection implique des contrôles de santé depuis plusieurs emplacements mondiaux, car un certificat qui semble valide depuis votre bureau peut échouer depuis la localisation d’un utilisateur en raison de délais de propagation sur le bord ou du cache du CDN.

Auto-évaluation de l’état actuel : disposez-vous d’un tableau de bord ou d’un système d’alertes qui affiche les dates d’expiration des certificats pour chaque domaine ? Est-ce mis à jour en temps réel lorsque les certificats sont renouvelés ? Pouvez-vous voir d’un coup d’œil quels domaines approchent de l’expiration et lesquels ont déjà échoué ?

État cible : monitoring continu de la santé des certificats depuis plusieurs emplacements de bord mondiaux. Le système effectue des vérifications actives de poignée de main TLS — pas seulement des recherches de dates d’expiration — pour s’assurer que chaque certificat est valide, de confiance et correctement servi. Le tableau de bord affiche l’état en temps réel pour tous les domaines. Le monitoring est automatique : lorsqu’un nouveau nom d’hôte est ajouté, le monitoring démarre sans configuration.

3. Calendrier de renouvellement : la zone tampon#

La question : les renouvellements sont-ils tentés suffisamment tôt pour survivre à des pannes de plusieurs jours ?

Avec des certificats de 90 jours, renouveler 7 à 14 jours avant l’expiration offrait une marge confortable. Avec des certificats de 45 jours, la même marge consomme 15 à 30 % de la durée de vie totale exploitable du certificat. Les calculs imposent un compromis : renouveler trop tôt et vous faites tourner les certificats en permanence ; renouveler trop tard et une panne temporaire de la CA devient un incident de production.

Les limites de débit de Let's Encrypt ajoutent une autre dimension. La limite « Duplicate Certificate » permet 5 certificats par semaine pour le même ensemble de noms d’hôtes, et la limite « Certificates per Registered Domain » plafonne à 50 par semaine. Avec des cycles de renouvellement de 45 jours, de grands portefeuilles de domaines peuvent atteindre ces limites plus vite que prévu — surtout si vous provisionnez aussi des certificats pour de nouveaux domaines.

Auto-évaluation de l’état actuel : quelle est votre fenêtre de renouvellement ? Si votre équipe renouvelle les certificats manuellement, les renouvellements commencent-ils au moins 15 jours avant l’expiration ? Pouvez-vous survivre à une panne de 5 jours de la CA sans qu’aucun certificat n’expire ? Avez-vous testé ce qui se passe lorsqu une tentative de renouvellement échoue — le système réessaie-t-il automatiquement ou attend-il une intervention humaine ?

État cible : les renouvellements automatisés commencent 30 jours avant l’expiration, avec une logique de reprise (retry) à backoff exponentiel. Si la première tentative échoue, le système réessaie à des intervalles croissants — 1 heure, 4 heures, 12 heures, 24 heures — jusqu’à ce que le renouvellement réussisse. Les limites de débit sont suivies et respectées automatiquement. Le système peut survivre à une panne CA de plusieurs jours sans qu’aucun domaine n’atteigne sa date d’expiration, car les renouvellements ont démarré suffisamment tôt pour qu’il y ait toujours au moins 15 jours de marge.

4. Alertes : Avant, pas Après#

La question : les bonnes personnes sont-elles averties avant — et non après — l’expiration du certificat ?

L’alerting fait la différence entre un non-événement et un incident. Lorsqu’un renouvellement de certificat échoue, deux choses doivent se produire : le système réessaie automatiquement (voir la section 3) et la bonne personne en est informée. Si votre supervision détecte un certificat expiré sans alerter qui que ce soit, il y a quand même un manque — vous le découvrez simplement plus vite.

L’alerting doit être hiérarchisé selon la sévérité et le public. Un renouvellement échoué qui finit par réussir 30 minutes plus tard n’a pas besoin d’une page à 2 h du matin — mais il doit apparaître dans un récapitulatif quotidien. Un certificat qui approche ses dernières 72 heures sans renouvellement réussi est une alerte critique qui doit atteindre l’ingénieur d’astreinte immédiatement.

Auto-évaluation de l’état actuel : qui est notifié lorsqu’un certificat est sur le point d’expirer ? Existe-t-il un système d’alertes hiérarchisé avec différents niveaux de sévérité ? Les alertes vont-elles aux bons canaux (Slack, email, PagerDuty) selon l’urgence ? Si la personne en astreinte principale n’est pas disponible, l’alerte est-elle escaladée ?

État cible : alerting en trois niveaux : Info (tentative de renouvellement, récapitulatif quotidien), Warning (renouvellement échoué, fenêtre de 7 jours, Slack/email), Critical (renouvellement échoué à répétition, fenêtre de 72 heures, escalade PagerDuty/astreinte). Les alertes incluent le nom de domaine, la date d’expiration du certificat, l’heure de la dernière tentative de renouvellement et la raison de l’échec. Chaque domaine du portefeuille est couvert — aucune exception, pas de « on va surveiller celui-là manuellement ».

5. Certificats Wildcard : commodité vs. risque#

La question : les certificats wildcard sont-ils gérés correctement ou créent-ils des points de défaillance uniques ?

Les certificats wildcard sont tentants : un seul certificat pour *.example.com couvre tous les sous-domaines. Un seul renouvellement. Une seule date d’expiration. Une seule chose à gérer. Mais cette « seule chose à gérer » est aussi une seule chose qui peut échouer — et quand elle échoue, tous les sous-domaines s’éteignent simultanément.

Pour l’infrastructure de redirection spécifiquement, les caractères génériques créent un autre problème : les défis DNS-01 pour les certificats wildcard nécessitent l’accès à la zone DNS du domaine racine (apex). Si vos domaines de redirection sont répartis entre plusieurs registrars et fournisseurs DNS — ce qui est courant dans les grands portefeuilles — gérer les défis DNS-01 pour un seul wildcard devient nettement plus complexe que de gérer des certificats par nom d’hôte.

Auto-évaluation de l’état actuel : Utilisez-vous des certificats wildcard pour les domaines de redirection ? Si le certificat wildcard échoue au renouvellement, combien de domaines sont impactés ? Avez-vous un plan de rollback testé ? Les wildcards sont-ils gérés par la même équipe que celle qui gère les certificats par domaine, ou s’agit-il de processus distincts avec des responsables différents ?

État cible : Les certificats par nom d’hôte sont la valeur par défaut. Chaque domaine reçoit son propre certificat, provisionné et renouvelé de manière indépendante. Cela apporte une isolation : un échec de renouvellement sur un domaine n’affecte aucun autre. Les wildcards ne sont utilisés que lorsque c’est explicitement nécessaire (par ex. des services internes derrière un sous-domaine partagé), avec une supervision et des alertes distinctes — et une procédure de récupération documentée et testée.

6. Plan de reprise après sinistre : Quand l’AC tombe#

La question : Si votre Autorité de certification (CA) est indisponible pendant 5 jours, vos certificats survivent-ils ?

Let’s Encrypt a déjà connu des pannes de plusieurs heures. Avec des durées de vie de certificats de 90 jours, une panne de 2 à 3 jours était gérable : les certificats avaient suffisamment de validité restante pour la traverser. Avec 45 jours, la même panne peut pousser les certificats au-delà de leur fenêtre de renouvellement avant que la CA ne soit de nouveau en ligne.

La reprise après sinistre pour SSL ne se limite pas à la CA. Elle concerne aussi le DNS : si votre fournisseur DNS subit une panne pendant une fenêtre de défi DNS-01, le défi échoue et le renouvellement est bloqué. Elle concerne aussi la propagation sur le edge : si un certificat renouvelé ne se propage pas à tous les nœuds edge avant l’expiration de l’ancien, certains utilisateurs voient des erreurs. Et elle concerne enfin le pipeline de renouvellement lui-même : si votre plateforme d’automatisation subit une panne, les renouvellements sont-ils mis en file d’attente ou abandonnés ?

Auto-évaluation de l’état actuel : Avez-vous modélisé ce qui se passe pendant une panne de CA de 5 jours ? Quelle est votre fenêtre de validité de certificat la plus courte sur l’ensemble du portefeuille ? Avez-vous une CA de repli configurée, ou tous les certificats sont-ils liés à un seul fournisseur ? Votre infrastructure DNS peut-elle survivre à une panne pendant une fenêtre de défi ?

État cible : Les certificats sont renouvelés suffisamment tôt pour que chaque domaine conserve au moins 15 jours de marge — assez pour survivre à une panne réaliste de la CA. Le pipeline de renouvellement est résilient : si un renouvellement échoue en raison de l’indisponibilité de la CA, le système réessaie automatiquement lorsque la CA revient. La supervision couvre l’ensemble de la chaîne de dépendances (DNS, CA, propagation sur le edge), pas seulement les dates d’expiration des certificats. Des CA de repli sont configurées pour les domaines critiques, et l’équipe dispose d’un runbook documenté et testé pour provisionner manuellement des certificats pendant des pannes prolongées de la CA.

Auto-évaluation : Évaluez votre niveau de préparation#

Évaluez votre infrastructure sur chacun des six domaines ci-dessous. Soyez honnête — un score faible n’est pas un échec, c’est une feuille de route.

Barème : 1 = Manuel / Aucune capacité, 2 = Partiellement automatisé / Des lacunes existent, 3 = Majoritairement automatisé / Lacunes mineures, 4 = Entièrement automatisé / Aucune lacune, 5 = Entièrement automatisé + testé / Résilient

Interprétation de votre total :

24-30 : Vous êtes prêt. Votre infrastructure est automatisée, surveillée et résiliente. Conservez cet état et testez régulièrement vos procédures de reprise.

18-23 : Vous avez de solides bases, mais il reste des lacunes. Priorisez d’abord les domaines « Critiques » — l’automatisation et le calendrier de renouvellement sont les améliorations les plus rentables. Un horizon de 45 jours mettra votre configuration actuelle à l’épreuve.

12-17 : Votre infrastructure n’est pas prête pour des certificats valables 45 jours. Les processus manuels qui fonctionnent à 90 jours échoueront à 45. Commencez par l’automatisation (domaine ①) — si vous ne corrigez qu’une seule chose, rendez automatique l’émission et le renouvellement des certificats.

6-11 : Vous êtes à haut risque. Chaque domaine de votre portefeuille est vulnérable à un seul rappel manqué ou à une panne de l’AC. Envisagez de passer à une plateforme de redirection qui gère l’automatisation SSL comme une infrastructure — pas comme une tâche — pour combler rapidement l’écart.

L’écart ne fait que se creuser#

L’ère des certificats sur 45 jours n’est pas une possibilité d’avenir — c’est une trajectoire de l’industrie avec un calendrier défini. Let’s Encrypt, qui émet des certificats pour plus de 360 millions de domaines, mène ce changement. La proposition du Google CA/Browser Forum suit la même direction. La norme évolue, et l’écart entre l’infrastructure automatisée et l’infrastructure manuelle ne fait que s’élargir à mesure que la durée de vie des certificats diminue.

Les équipes qui automatisent dès maintenant ne ressentiront pas le changement. Elles verront leurs tableaux de bord afficher des renouvellements terminés à l’heure — 30 jours en avance, à chaque fois, pour chaque domaine — tandis que d’autres s’agitent pour mettre à jour des tableurs. La checklist ci-dessus n’est pas seulement un outil d’évaluation. C’est une feuille de route vers une infrastructure prête pour toute durée de vie de certificat sur laquelle l’industrie se stabilisera — 45 jours, 30 jours ou moins.

Évaluez votre infrastructure. Comblez les lacunes. L’ère des certificats sur 45 jours arrive — vos domaines de redirection devraient être la dernière de vos préoccupations.