Certificats de courte durée

Éditorial

La durée de vie maximale des certificats TLS publics va continuer de baisser, jusqu'à quelques semaines. Pour une petite infrastructure, cela ne change presque rien à la sécurité et tout à l'exploitation : le risque quitte la révocation pour s'installer dans l'automatisation.

Mis à jour le 25 septembre 2026~23 min de lecture12 sections

papy cyber

→ Lire l’explication complète de la marmotte

Une décision prise ailleurs

Il existe, dans le monde de l’exploitation, une catégorie de nouvelles qui tombent comme la grêle sur les jardins ouvriers : elles sont décidées très haut, pour d’excellentes raisons, par des gens qui n’ont pas de jardin. La réduction de la durée de vie des certificats en fait partie.

Rappelons les faits, avec la prudence qu’imposent les faits qui bougent. Il fut un temps, que les plus jeunes lecteurs prendront pour une légende, où l’on achetait un certificat pour plusieurs années, qu’on l’installait un vendredi soir en suivant une procédure imprimée, et qu’on l’oubliait jusqu’à ce qu’un client téléphone pour signaler que « le site dit qu’il n’est pas sûr ». La durée maximale a ensuite été ramenée à un peu plus d’un an, au tournant des années 2020. Puis le CA/Browser Forum, l’assemblée où autorités de certification et éditeurs de navigateurs négocient les règles du web public, a adopté une trajectoire de réduction par paliers successifs, étalés sur plusieurs années, jusqu’à une durée maximale de l’ordre de quarante-sept jours. La même décision raccourcit la durée pendant laquelle une autorité peut réutiliser une validation de domaine déjà faite.

Je ne recopie pas ici les dates de chaque palier : elles sont dans les exigences de base, elles peuvent être amendées, et un éditorial qui prétend les fixer se périme à la première révision. Ce qui compte pour le raisonnement tient en une phrase : à terme, un certificat public vivra environ six semaines, et il faudra le renouveler plus souvent encore, par précaution.

L’éditorial précédent expliquait pourquoi on en est arrivé là : la révocation n’a jamais protégé contre l’attaquant qui compte, et l’écosystème a préféré faire mourir les certificats jeunes plutôt que de continuer à les exécuter mal. Celui-ci pose une question plus terre à terre, celle du jardinier : qu’est-ce que ça change, concrètement, pour une petite infrastructure ?

Ma réponse, que la suite essaiera de justifier : presque rien pour la sécurité, presque tout pour l’exploitation, et c’est l’exploitation qui décidera si la sécurité y gagne.

Ce que la brièveté achète

Commençons par être juste envers la décision, ce qui est toujours plus confortable avant de la critiquer.

Un certificat court borne la durée d’utilisation d’une clé volée. C’est le bénéfice principal, et il est réel : si une clé fuit, le certificat qui l’accompagne expirera en quelques semaines au lieu de traîner une année, révoqué sur le papier et accepté en pratique par tous les clients qui ne vérifient rien. Pour le web public, où la révocation est ce qu’elle est, c’est un gain net.

Il borne aussi la durée de vie d’une erreur. Un certificat émis à tort (mauvais nom, validation défaillante, autorité qui s’est trompée) disparaît de lui-même. Les autorités commettent des erreurs d’émission plus souvent qu’elles ne le racontent dans leurs brochures, et l’expiration rapide les nettoie sans procédure.

Il accélère les transitions. Quand l’écosystème doit changer d’algorithme, de format, de chaîne de confiance ou de règles de validation, un parc de certificats d’un an met un an à se renouveler, et un parc de six semaines, six semaines. La perspective d’une migration vers des algorithmes post-quantiques rend cet argument plus sérieux qu’il n’en a l’air : un écosystème qui renouvelle tout en permanence est un écosystème qui sait changer, ce qui est plus rare qu’un écosystème qui sait parler de changement.

Et il impose l’automatisation, ce qui est à la fois son effet le plus utile et le plus brutal. Personne ne renouvelle à la main un certificat toutes les cinq semaines sur vingt équipements. Ceux qui le tenteront apprendront vite, et c’est peut-être le but.

Voilà pour l’éloge. Il est sincère. Venons-en à ce qu’il oublie.

La petite infrastructure, cette inconnue

Les règles du web public sont écrites par des organisations qui gèrent des millions de certificats avec des équipes dédiées, et qui ont automatisé leur renouvellement depuis longtemps. Pour elles, passer de quatre-vingt-dix à quarante-sept jours est un changement de paramètre. Il est normal qu’elles le décident avec sérénité : on est toujours serein en supprimant un problème qu’on n’a plus.

Supposons maintenant une petite structure, hypothétique mais banale, de vingt postes. Elle a un site vitrine chez un hébergeur, un serveur de messagerie ou un service de messagerie hébergé, un reverse proxy devant deux applications métier, un NAS dont l’interface web est accessible depuis l’extérieur « pour le télétravail », un boîtier VPN, deux imprimantes réseau, une interface d’administration de serveur physique, un Wi-Fi invité avec portail, et un prestataire qui passe une fois par trimestre. Certains de ces éléments portent un certificat public. D’autres portent un certificat auto-signé que tout le monde a pris l’habitude d’accepter d’un clic, ce qui est une forme de révocation à l’envers : on a appris aux utilisateurs à faire confiance à ce qui ne le mérite pas.

Pour cette structure, la question de la durée de vie ne se pose pas en termes de sécurité. Elle se pose en termes d’inventaire, et l’inventaire n’existe pas.

La première conséquence de la réduction des durées n’est pas technique : c’est la révélation de tout ce qu’on ignorait posséder. Un certificat d’un an qui expire, c’est une panne par an, qu’on répare dans la panique et qu’on oublie. Un certificat de six semaines qui expire, c’est huit pannes par an, et au bout de la deuxième, quelqu’un pose enfin la question : « combien en avons-nous, au juste ? ». Personne ne sait répondre. C’est le début de la sagesse, qui commence toujours par une humiliation.

L’inventaire avant l’outil

La tentation, face à ce genre de contrainte, est de commencer par l’outil : installer un client ACME, lancer une commande, se sentir moderne. C’est mettre la charrue avant les bœufs, et même avant de savoir combien on a de champs.

Un inventaire de certificats répond à cinq questions pour chaque certificat : où il est déployé (hôte, service, port, parfois plusieurs endroits pour le même certificat) ; qui l’émet (autorité publique, autorité interne, auto-signé) ; comment il est renouvelé (automatique, manuel, par un prestataire, par personne) ; ce qui doit se passer après le renouvellement (rechargement d’un service, redémarrage, copie vers un autre équipement) ; et qui est prévenu quand quelque chose échoue. La page sur la gouvernance de la cryptographie décrit l’inventaire dans un cadre plus large ; ici, on se contente du strict nécessaire.

Il existe une source d’inventaire que les petites structures ignorent presque toujours, et qui est pourtant gratuite : les journaux de transparence des certificats. Tout certificat public doit y être inscrit, et des moteurs de recherche publics permettent de lister tous les certificats émis pour un domaine. C’est un inventaire involontaire, tenu par d’autres, et il est souvent plus complet que celui de l’intéressé. Il faut en tirer deux leçons. La première est pratique : consultez-le, vous y trouverez des certificats dont personne ne se souvient. La seconde est moins réjouissante : tout le monde peut le consulter, y compris pour découvrir les noms d’hôtes internes que vous avez eu la bonne idée de couvrir par un certificat public. Chaque certificat émis pour vpn., nas. ou compta-test. est une petite annonce publiée dans un registre mondial et ineffaçable. La transparence est une vertu, mais elle ne choisit pas ses spectateurs.

Pour le reste, un inventaire commence par des vérifications en lecture seule, qu’on peut lancer depuis n’importe quel poste :

# Sujet et date d'expiration du certificat présenté par un service
# (remplacer hôte et port ; ne modifie rien)
echo | openssl s_client -connect nas.exemple.org:443 \
  -servername nas.exemple.org 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate

# Pour un fichier local : code retour 0 s'il reste au moins 14 jours
openssl x509 -in certificat.pem -noout -checkend $((14*24*3600)) \
  && echo "ok" || echo "expire dans moins de 14 jours"

Et, sur une machine où un client ACME courant est déjà installé :

# Liste les certificats gérés et leurs dates (lecture seule)
sudo certbot certificates

# Vérifie que le renouvellement est bien planifié
systemctl list-timers | grep -i -E 'certbot|acme'

Rien de tout cela n’est sophistiqué. C’est justement le point : le problème n’est pas l’absence d’outils, c’est l’absence de liste. On peut écrire un script qui boucle sur une liste d’hôtes et alerte à trente jours. On ne peut pas écrire la liste à la place de quelqu’un qui ne sait pas ce qu’il exploite.

Trois tiroirs, pas davantage

Une fois la liste dressée, il faut la trier, et je propose de ne pas raffiner : trois tiroirs suffisent, et la tentation d’en ouvrir un quatrième est généralement le premier symptôme d’un projet qui ne finira jamais.

Le premier tiroir contient ce qui s’automatise directement. Un serveur sous un système courant, sur lequel on peut installer un client ACME, qui sait recharger son service après renouvellement. Le site vitrine, le reverse proxy, le serveur de messagerie auto-hébergé. Pour ceux-là, la réforme est une formalité, à condition d’avoir vérifié une fois, en conditions réelles, que le renouvellement va jusqu’au bout, rechargement compris. Les clients ACME proposent un mode d’essai contre l’environnement de test de l’autorité ; il sert à cela, et il coûte moins cher qu’un lundi matin.

Le deuxième tiroir contient ce qui s’automatise par procuration. L’équipement qui refuse ACME mais peut se cacher derrière un reverse proxy qui, lui, l’accepte. Le proxy porte le certificat public ; l’équipement garde son certificat interne, voire son auto-signé, sur un segment où seul le proxy lui parle. C’est la catégorie la plus nombreuse dans une petite structure, et la plus négligée, parce qu’elle demande de modifier un flux réseau plutôt que d’installer un logiciel, et que modifier un flux réseau, dans une structure de vingt postes, revient souvent à demander au prestataire trimestriel, qui a d’autres chats à fouetter.

Le troisième tiroir contient ce qui n’a rien à faire sur Internet. L’interface d’administration du serveur physique, l’imprimante, la caméra, le NAS dont l’accès distant pourrait passer par le VPN. Ce tiroir-là ne relève pas du tout de la réforme des certificats publics. Il relève d’une question plus ancienne et plus désagréable : pourquoi ces interfaces étaient-elles exposées ? La réduction des durées a au moins ce mérite involontaire : elle rend coûteux ce qui était gratuit et dangereux, et pousse à rentrer à l’intérieur ce qui n’aurait jamais dû sortir.

Ce tri fait, le plan est presque écrit. Il reste à décider qui s’en occupe, ce qui est, comme toujours, la seule question difficile.

ACME, ou l’automatisation et ses clés

Le protocole ACME, normalisé à l’IETF et popularisé par une autorité gratuite, a fait pour les certificats ce que la machine à laver a fait pour le linge : il a rendu la corvée invisible, donc oubliable, donc dangereuse le jour où la machine fuit.

Le principe est simple : un client demande un certificat, l’autorité lui soumet un défi pour prouver qu’il contrôle le domaine, le client le relève, l’autorité émet. Les défis les plus courants consistent à publier un jeton à une adresse HTTP précise sur le domaine, ou à publier un enregistrement DNS. Le choix du défi n’est pas un détail : il détermine ce que l’automatisation doit être autorisée à faire, et donc ce qu’un attaquant pourra faire s’il la compromet.

Le défi HTTP exige que le service soit joignable depuis Internet sur le port 80, au moment du renouvellement. Pour le site vitrine, c’est trivial. Pour le NAS, c’est une porte qu’on ouvre à chaque renouvellement, ou qu’on laisse ouverte en permanence parce que c’est plus simple, ce qui transforme un besoin de certificat en surface d’exposition. Pour un service purement interne, c’est impossible.

Le défi DNS fonctionne pour tout, y compris les services internes et les certificats génériques (wildcard), qui l’exigent. Mais il suppose que le client ACME puisse modifier la zone DNS, donc qu’il détienne une clé d’API chez l’hébergeur DNS. Et c’est là que le problème change de nature, comme un roman policier qui s’avère être un roman de mœurs.

Chez la plupart des hébergeurs grand public, les clés d’API DNS ne sont pas finement cloisonnées : une clé qui peut créer un enregistrement TXT de validation peut souvent modifier toute la zone, parfois toutes les zones du compte. Elle est posée en clair dans un fichier de configuration, sur une machine qui tourne en permanence, pour que le renouvellement puisse se faire sans humain. Quiconque la vole peut rediriger le domaine, intercepter le courrier, et, raffinement suprême, obtenir lui-même des certificats parfaitement valides pour n’importe quel nom de la zone. On a remplacé un secret qui vivait un an (la clé du certificat) par un secret qui vit indéfiniment et vaut davantage (la clé de l’API DNS). Ce n’est pas un argument contre l’automatisation ; c’est un argument pour la traiter comme ce qu’elle est devenue, c’est-à-dire l’endroit le plus précieux de l’infrastructure.

Les parades existent et sont connues : clés d’API restreintes quand l’hébergeur le permet, délégation de l’enregistrement de validation vers une zone dédiée qui ne sert qu’à cela, client ACME isolé sur une machine qui ne fait rien d’autre, secrets gérés comme des secrets et non comme des paramètres. La page sur l’exploitation des clés et la rotation développe le principe général. Aucune de ces parades n’est coûteuse. Toutes demandent quelqu’un qui y pense, ce qui est la ressource la plus chère d’une petite structure.

Ce qui casse

L’expérience collective du métier (je parle ici de ce qui se lit dans la documentation et les forums, pas d’une anecdote de comptoir) permet de dresser une liste assez stable de ce qui casse quand on raccourcit les durées. Elle ne surprendra personne ; c’est précisément pourquoi elle est utile.

Les équipements qui n’acceptent pas l’automatisation. Boîtiers VPN, interfaces d’administration matérielle, imprimantes, NAS anciens, caméras : beaucoup n’offrent qu’une page web où l’on colle un certificat et une clé. Tant que la durée était d’un an, c’était une corvée annuelle. À six semaines, c’est un métier. Il faut alors choisir entre scripter l’interface web (fragile), placer l’équipement derrière un reverse proxy qui porte le certificat public (souvent la meilleure option), ou considérer que cet équipement n’a pas à être exposé et relève d’une autorité interne. Ce dernier choix est le plus sain et le moins pratiqué, parce qu’il oblige à monter une PKI interne, perspective qui provoque chez l’administrateur moyen un léger vertige.

Le certificat copié à plusieurs endroits. Le même certificat est souvent installé sur le reverse proxy, sur le serveur de messagerie et sur une appliance, par copie manuelle. Le client ACME renouvelle le premier exemplaire ; les deux autres expirent, avec la ponctualité des choses qu’on a oubliées. Le renouvellement n’est terminé que lorsque tous les consommateurs ont rechargé la nouvelle version, et c’est ce que les crochets de déploiement (deploy hooks) sont censés faire, à condition que quelqu’un les ait écrits.

Le service qui ne recharge pas. Un certificat renouvelé sur le disque et jamais relu par le processus en mémoire continue de servir l’ancien jusqu’au prochain redémarrage. La supervision voit un fichier neuf ; le client voit un certificat expiré. Il faut vérifier ce que sert le port, pas ce que contient le répertoire.

Les magasins de clés applicatifs. Les applications qui lisent leurs certificats dans un magasin propre (formats Java, conteneurs PKCS#12, magasins système de certains serveurs) exigent une conversion et une réimportation. Chaque étape manuelle de cette chaîne devient une panne programmée.

L’épinglage. Toute application qui épingle un certificat précis, plutôt qu’une clé publique stable ou une autorité, cassera à chaque renouvellement. L’épinglage sur le certificat feuille n’était déjà pas une bonne idée ; à six semaines, il devient une manière originale de se mettre en panne à intervalles réguliers.

Les limites et les pannes de l’autorité. Les autorités appliquent des limites de fréquence et connaissent, comme tout le monde, des incidents. Un renouvellement lancé au dernier moment tombe mécaniquement un jour sur une panne. D’où la règle, que les clients ACME appliquent par défaut : renouveler tôt, typiquement quand il reste environ un tiers de la durée de vie, pour avoir le temps d’échouer plusieurs fois. Certaines autorités proposent désormais une extension ACME qui indique au client la fenêtre de renouvellement recommandée, ce qui leur permet aussi de faire renouveler massivement en cas d’incident. C’est une bonne idée, qui suppose un client à jour.

L’horloge. Un équipement dont l’horloge dérive rejettera des certificats neufs comme « pas encore valides » ou acceptera des certificats expirés. Avec des durées d’un an, une dérive de quelques jours passait inaperçue. Avec des durées de six semaines et des renouvellements fréquents, elle finit par se voir. Le temps, en cryptographie, n’est jamais un détail ; il est simplement le détail que l’on configure en dernier.

La supervision elle-même. Une alerte « expire dans trente jours » qui se déclenchait une fois par an devient, sur un certificat de quarante-sept jours, une alerte presque permanente. Il faut revoir les seuils, sous peine de dresser l’équipe à ignorer l’alarme, ce qui est la manière la plus sûre de ne plus avoir d’alarme.

Ce que ça ne règle pas

La brièveté est une réponse à un problème précis. Il est utile de lister ceux auxquels elle ne répond pas, parce qu’on les verra bientôt figurer dans des argumentaires commerciaux qui prétendront le contraire.

Elle ne protège pas la clé. Entre l’émission et l’expiration, une clé volée reste utilisable. Six semaines, c’est court pour un administrateur ; c’est long pour un attaquant. Et si la machine qui détient la clé est compromise, l’attaquant récupérera aussi la suivante, et celle d’après, puisque le renouvellement automatique se fait sur la même machine. Un certificat court sur un serveur compromis n’est pas une protection, c’est un abonnement.

Elle ne protège pas contre le détournement du domaine. Quiconque contrôle votre DNS ou votre serveur web, même quelques minutes, peut obtenir un certificat valide à votre nom. La durée de vie courte limite la durée de validité de ce certificat frauduleux ; elle ne l’empêche pas d’exister. La surveillance des journaux de transparence (être alerté quand un certificat est émis pour votre domaine) répond mieux à ce risque, et elle est rarement mise en place.

Elle ne concerne pas votre PKI interne. Les règles du CA/Browser Forum s’appliquent aux certificats publiquement reconnus. Les certificats émis par une autorité interne pour du mTLS entre services, des postes de travail ou des équipements, obéissent aux règles que vous vous fixez. Rien ne vous empêche d’appliquer les mêmes principes (et il y a de bonnes raisons de le faire, avec des protocoles d’enrôlement comme EST ou ACME en interne), mais rien ne vous y oblige non plus, et la tentation de garder des certificats internes de dix ans est forte chez ceux qui ont souffert du passage à quarante-sept jours pour les certificats publics.

Elle ne règle pas les auto-signés. Les équipements qui présentent un certificat auto-signé, accepté d’un clic par des utilisateurs dressés à le faire, ne sont pas concernés par la réduction. Ils restent le trou le plus béant de la plupart des petites infrastructures, et la réforme passe au-dessus d’eux comme un avion au-dessus d’un village.

Elle ne remplace pas la compréhension. Un renouvellement automatique qu’on ne comprend pas est une panne différée. Le jour où il échoue (changement d’hébergeur DNS, mise à jour du client, modification d’une règle de pare-feu), quelqu’un doit savoir ce qu’il faisait. Si la personne qui l’a configuré est partie, la connaissance est partie avec elle, et l’automatisation continue de tourner à vide, comme un moulin dans un pays sans blé.

Le meilleur argument contraire

J’ai jusqu’ici regardé la réforme d’un œil de vieil exploitant grincheux, ce qui est ma pente naturelle et pas nécessairement celle de la vérité. Voici l’argument le plus fort en sens inverse.

La principale cause de panne liée aux certificats n’a jamais été le vol de clé, mais l’oubli du renouvellement. Les certificats longs ont fabriqué exactement cela : une opération assez rare pour qu’on oublie comment la faire, assez peu fréquente pour que personne ne l’automatise, et assez critique pour arrêter un service quand on l’oublie. En rendant le renouvellement fréquent, la réforme le rend impossible à faire à la main, donc impossible à oublier une fois automatisé. Une opération quotidienne ou hebdomadaire est testée en permanence ; une opération annuelle ne l’est jamais. De ce point de vue, les certificats courts ne sont pas une contrainte imposée aux petits par les grands : ce sont les petits qui en avaient le plus besoin, parce qu’ils sont ceux qui oubliaient.

L’argument va plus loin. Une infrastructure qui renouvelle ses certificats toutes les cinq semaines sans intervention humaine a nécessairement un inventaire, une supervision, un mécanisme de déploiement et une procédure de rechargement. C’est-à-dire qu’elle a appris, par la contrainte, les gestes d’hygiène qu’on lui recommandait en vain depuis vingt ans. La réforme ne demande pas de nouvelles compétences ; elle rend obligatoires celles dont l’absence était jusque-là tolérable.

Je trouve cet argument très fort, et je le crois juste pour tout ce qui peut être automatisé. Mes réserves portent sur le reste : les équipements qui ne s’automatisent pas, les clés d’API qui deviennent des joyaux, et la tentation de fuir vers des certificats internes de très longue durée ou vers des auto-signés pour échapper à la contrainte. L’argument contraire suppose que la contrainte pousse vers le haut. Elle peut aussi pousser vers le bas, chez ceux qui n’ont pas les moyens de monter. Les deux se produiront, et j’ignore dans quelle proportion.

Ce que je ne sais pas

Je ne sais pas si le calendrier sera tenu tel qu’annoncé. Les exigences de base ont déjà été amendées par le passé, dans les deux sens. Un palier peut être reporté, une exception introduite. Planifiez sur la trajectoire, vérifiez les dates à la source, et ne bâtissez rien sur un jour précis.

Je ne sais pas ce que feront les fabricants d’équipements. La réforme met sous pression tous les appareils qui n’offrent qu’une interface manuelle d’import de certificat. Certains ajouteront un client ACME ; d’autres se contenteront d’une documentation expliquant comment placer l’appareil derrière un proxy ; d’autres ne feront rien. Je n’ai pas de moyen d’anticiper la proportion, et je me garde de toute prédiction sur un marché où la mise à jour logicielle d’une imprimante reste un événement.

Je ne sais pas si les hébergeurs DNS grand public offriront un jour des clés d’API cloisonnées par enregistrement. C’est la parade la plus utile au risque que crée l’automatisation, et elle dépend entièrement d’eux.

Je ne sais pas où est le point d’équilibre. Des certificats de quelques jours existent déjà. À mesure que les durées raccourcissent, la dépendance à la disponibilité de l’autorité au moment du renouvellement augmente. À partir d’une certaine brièveté, une panne prolongée d’une grande autorité deviendrait une panne d’une partie du web. Je ne sais pas où se situe ce seuil, et je doute que quiconque le sache avant de l’avoir franchi.

Ce qui reste

La réduction des durées de vie est une bonne décision prise pour de bonnes raisons par des gens qui n’en supporteront presque pas le coût. Ce n’est pas un reproche : c’est la condition ordinaire des décisions d’infrastructure, et celle-ci est plutôt meilleure que la moyenne.

Trois choses me semblent acquises. Que la brièveté déplace le risque plus qu’elle ne le réduit : de la clé de certificat vers les secrets de l’automatisation, du vol vers la panne. Que l’inventaire précède l’outil, et que les journaux de transparence en fournissent un brouillon gratuit à qui veut bien le lire, avant que d’autres le lisent à sa place. Et que tout ce qui ne peut pas être automatisé doit sortir du périmètre public, derrière un proxy ou sous une autorité interne, plutôt que de devenir une corvée toutes les cinq semaines et une panne tous les deux mois.

Il reste un point que ces deux éditoriaux ont frôlé sans le toucher. On a parlé de révoquer des clés, de les faire expirer, de les renouveler. On a supposé, à chaque page, qu’une clé compromise était une clé volée, recopiée hors de la machine. Il existe une autre manière de compromettre une clé, plus discrète et plus fréquente : ne pas la voler du tout, et simplement s’en servir. C’est contre le vol que l’industrie a inventé le module matériel de sécurité. C’est contre l’usage qu’elle a oublié de le vendre.

C’est le sujet de l’éditorial suivant.

🐝 Ce qui arrive si on s’en passe

Une structure qui aborde la réduction des durées sans inventaire découvre ses certificats par leurs pannes, au rythme de leur expiration, et répare chaque fois dans l’urgence ce qu’elle ne sait pas nommer. La pression pousse alors vers les solutions de facilité : certificats auto-signés que les utilisateurs acceptent d’un clic, ce qui les entraîne à valider aussi bien une interception, ou port 80 laissé ouvert en permanence pour que le renouvellement passe. La clé d’API DNS posée en clair sur une machine qui tourne jour et nuit offre à qui la dérobe le domaine entier, le courrier compris, et des certificats valides à son nom ; sans surveillance des journaux de transparence, leur émission passe inaperçue jusqu’à leur premier usage.

🦫 Explication de la marmotte 🍫

Quand un navigateur se connecte à un site protégé, le site présente un certificat : un document électronique, signé par une autorité reconnue, qui relie le nom du site à une clé secrète que seul le site détient. Chaque certificat a une date d’expiration. Les autorités et les éditeurs de navigateurs ont décidé de réduire sa durée maximale par étapes, jusqu’à environ six semaines. L’intérêt est de limiter le temps pendant lequel une clé volée ou un certificat émis par erreur reste utilisable, et d’accélérer les changements de méthode. Il faut alors renouveler très souvent, ce qui n’est possible qu’avec un programme automatique. Ce programme prouve à l’autorité qu’il contrôle le nom du site, soit en publiant un code sur le site, soit en modifiant l’annuaire des noms de domaine. Dans ce second cas, il détient une clé d’accès à cet annuaire, qui devient le secret le plus précieux, car elle permet de détourner tout le domaine. Pour une petite structure, le premier travail est la liste des certificats : où ils sont, qui les émet, comment ils sont renouvelés, quel service doit les relire, qui est prévenu en cas d’échec. On les range ensuite en trois groupes : automatisables directement, placés derrière un serveur intermédiaire qui porte le certificat, ou retirés d’internet. Les pannes viennent souvent d’une copie oubliée, d’un service qui ne relit pas le nouveau certificat ou d’une horloge déréglée.

Pages voisines

La citent

Certificats de courte durée

Elle cite

: les deux pages se citent l’une l’autre.

Certificats de courte durée

Une décision prise ailleurs

Ce que la brièveté achète

La petite infrastructure, cette inconnue

L’inventaire avant l’outil

Trois tiroirs, pas davantage

ACME, ou l’automatisation et ses clés

Ce qui casse

Ce que ça ne règle pas

Le meilleur argument contraire

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines