Aller au contenu
Planifier un échange
🇩🇪 Deutsch 🇬🇧 English 🇫🇷 Français
Produits phares
Perstat Supervision de disponibilité, gestion des incidents et pages de statut pour les équipes qui s'engagent sur la disponibilité. NextPKI Trouver, renouveler et gérer les certificats, quelle que soit l'autorité qui les a émis. Databurg Documentation de conformité inaltérable pour les entreprises soumises à des obligations de preuve.
Confiance & crypto
sqlclient Client de base de données natif pour macOS. En local, sans passer par les serveurs d'un tiers. FoldMail Logiciel de messagerie avec un chiffrement pris au sérieux, S/MIME et OpenPGP. Claro Application pour parents séparés : passages de relais, accords et frais au même endroit.
Bundle du mois
Reliability Bundle

Perstat + NextPKI en un seul forfait facturé ensemble. Preuves NIS2 et Certificate Lifecycle depuis un seul cockpit.

En savoir plus
Apprendre
Blog Notes de version, actualités conformité, feuille de route. Carrières
Confiance
Legal & confidentialité DPA, liste des sous-traitants.
Bundle du mois
Reliability Bundle

Perstat + NextPKI en un seul forfait facturé ensemble. Preuves NIS2 et Certificate Lifecycle depuis un seul cockpit.

En savoir plus
Produits Perstat NextPKI Databurg sqlclient FoldMail Claro
Mentions légales
Langue
🇩🇪 Deutsch 🇬🇧 English 🇫🇷 Français
Planifier un échange
Aller au contenu
PKI et certificats

ACME au-delà du serveur web : automatiser les certificats pour les services internes et le mTLS

17.03.2026 · 3 min de lecture

Les durées de vie courtes ne se maîtrisent que par l'automatisation. Pourquoi la PKI interne, le service mesh et le mTLS suivent d'autres schémas que le web public, et comment ACME fonctionne aussi derrière le pare-feu.

La réduction des durées de vie des certificats TLS publics, vers 47 jours à terme, a fait prendre conscience que le renouvellement manuel ne tient plus l’échelle. Ce que l’on néglige souvent : à l’intérieur d’une entreprise se cachent en général bien plus de certificats qu’à la lisière visible de l’extérieur. La communication de service à service, le mTLS dans un service mesh, les API internes et les connexions de bases de données vivent toutes de certificats, et ceux-ci suivent d’autres schémas que le web public.

Pourquoi « interne » ne veut pas dire « plus simple »

Sur le serveur web public, la situation est claire : une poignée de domaines, une autorité de certification publique, un chemin de validation bien défini. À l’intérieur, le rapport s’inverse. On y trouve souvent des centaines ou des milliers de points de terminaison éphémères, qui apparaissent et disparaissent dynamiquement, par exemple lorsqu’un orchestrateur démarre de nouveaux conteneurs. Une autorité de certification interne leur délivre des certificats que personne ne voit publiquement, mais qui expirent tout autant, doivent se renouveler tout autant et, en cas de défaillance, paralysent un service tout autant.

La différence avec le monde public n’est donc pas une moindre importance, mais une fréquence et une dynamique plus élevées. Avec le mTLS, où les deux parties s’authentifient mutuellement à l’aide d’un certificat, le nombre d’identités à gérer double encore.

ACME n’est pas réservé à Let’s Encrypt

ACME (RFC 8555) s’est fait connaître comme le protocole de délivrance et de renouvellement automatiques, surtout à travers Let’s Encrypt sur le web public. Le protocole lui-même est pourtant agnostique vis-à-vis de l’autorité de certification. Une autorité de certification interne peut offrir une interface ACME, et les services internes se renouvellent alors d’eux-mêmes selon le même mécanisme, sans que personne ne commande un certificat à la main.

Pour la validation interne, d’autres types de challenge entrent en jeu que sur le web public. Le challenge HTTP, courant pour les domaines publics, convient rarement aux services internes. On recourt plutôt à des procédés fondés sur le DNS ou, selon l’environnement, à des preuves d’identité liées à la plateforme. Les service meshes résolvent en partie la question en interne, au moyen de leur propre couche d’identité et de certificats éphémères dont la durée de vie se compte en heures plutôt qu’en semaines.

Ce qui fait la différence

Trois capacités déterminent si l’automatisation interne tient.

Une découverte tournée aussi vers l’intérieur. La panne dangereuse est rarement le certificat frontal bien entretenu. C’est le certificat oublié sur un service interne, un équipement ou un cluster que plus personne n’observe activement. Un inventaire doit recenser les points de terminaison internes autant que les publics.

Une vision agnostique des autorités de certification. Dans les environnements qui se sont développés au fil du temps, plusieurs autorités de certification coexistent le plus souvent : une publique pour la lisière externe, une ou plusieurs internes, et peut-être une propre au cloud. Une gestion qui offre, par-delà toutes, une vue unifiée et un renouvellement unifié évite que chaque autorité ne devienne son propre îlot avec ses propres lacunes.

Un renouvellement maîtrisé. L’automatisation complète est l’objectif, mais pas au prix d’une traçabilité perdue. Là où c’est nécessaire, le renouvellement automatique comporte une étape documentée d’approbation et de journalisation, afin que, même à haute fréquence, on puisse retracer ce qui a été délivré et quand.

C’est précisément ce schéma, la découverte d’abord, puis l’automatisation agnostique avec approbation, qui sous-tend notre module NextPKI. L’orientation vaut cependant indépendamment de l’outil : maîtriser les durées de vie courtes de la lisière externe mais négliger l’intérieur, c’est ne pas tenir le véritable volume.

Le débat sur les 47 jours est une bonne occasion d’élargir le regard. La plupart des certificats d’une entreprise ne sont pas en vitrine, mais dans la salle des machines.

Retour au blog

Datargo Datargo

Datargo GmbH, Francfort-sur-le-Main. Nous concevons et exploitons nos propres logiciels sur notre propre infrastructure, dans l'Union européenne.

Hébergement UE Francfort RGPD natif Made in Germany
Produits
  • Perstat
  • NextPKI
  • Databurg
  • sqlclient
  • FoldMail
  • Claro
Entreprise
  • Contact
  • Carrières
  • Blog
  • Page de statut
Mentions légales
  • Mentions légales
  • Confidentialité
© 2026 Datargo GmbH. Tous droits réservés.
Allemagne · Français

Datargo® et Databurg® sont des marques déposées de Datargo GmbH. Tous les autres noms de produits, logos et marques cités appartiennent à leurs propriétaires respectifs.