Faire de l'ACME en interne sans supplier l'équipe AD CS

Il arrive un moment, dans toute infrastructure un peu sérieuse, où l’on aimerait émettre ses certificats internes comme Let’s Encrypt émet les siens, c’est-à-dire automatiquement, par ACME, sans ticket, sans formulaire, sans avoir à négocier chaque renouvellement avec la personne qui détient les clés de l’autorité de certification maison. Le problème n’est pas technique au premier abord, il est politique, parce que dans neuf entreprises sur dix la PKI vit à l’intérieur d’une AD CS que l’équipe Windows garde jalousement et qu’on ne va pas déployer une seconde racine de confiance sur tout le parc juste pour se simplifier la vie. Trois familles d’outils répondent à ce besoin et si l’on croit souvent devoir choisir entre deux d’entre elles, la troisième a discrètement changé la donne pour quiconque exploite déjà un coffre à secrets.

step-ca, la PKI dédiée qu’on assume

step-ca, de Smallstep, sous Apache 2.0, est une autorité de certification autonome qui parle ACME nativement et qu’on met debout en quelques minutes. On lui confie une racine, on définit des provisioners, on active le challenge qui convient au réseau interne et l’on obtient une expérience Let’s Encrypt entièrement sous son contrôle, y compris ces certificats à durée de vie très courte que l’AD CS traditionnelle ne saurait servir sans grincer. Sa vertu est sa légèreté, c’est l’option la plus rapide à dresser quand on veut une PKI dédiée et rien d’autre. Sa contrepartie est évidente et assumée, c’est une nouvelle racine, qu’il faudra distribuer et faire adopter par tous les clients.

acme2certifier, le traducteur qui préserve l’émetteur

acme2certifier, libre lui aussi, ne prétend pas être une autorité de certification. C’est un proxy ACME, un traducteur qui présente une interface ACME propre du côté client et qui, du côté serveur, s’adosse à une CA déjà en place via une série de handlers, dont un pour les interfaces d’enrôlement web de Microsoft. Point crucial, c’est l’AD CS qui émet réellement les certificats, avec ses politiques, ses templates et sa piste d’audit, acme2certifier se contentant de lui poser une porte d’entrée moderne. C’est précisément ce qui en fait le seul bon choix quand l’équipe sécurité exige que l’autorité émettrice reste l’AD CS et refuse toute CA déléguée.

OpenBao, la consolidation

Et puis il y a le cas, de plus en plus fréquent, où l’on fait déjà tourner un coffre à secrets. OpenBao , le fork libre de Vault sous MPL 2.0, embarque un moteur PKI qui est une CA complète, doté d’un serveur ACME natif sur lequel certbot, Traefik ou cert-manager se branchent directement. Pour peu que le coffre soit déjà là, on obtient secrets, PKI et ACME dans un seul système à authentification par identité, ce qui est difficile à battre en cohérence opérationnelle. Mieux, OpenBao sait jouer sur les deux tableaux, soit en racine autonome à la manière de step-ca, soit en intermédiaire dont on fait signer le CSR par la racine de l’AD CS, auquel cas les certificats qu’il émet chaînent proprement vers le trust store que le parc reconnaît déjà.

C’est cette souplesse qui fait dire, à juste titre, qu’OpenBao supplante à peu près tout le reste, mais tenons la nuance. OpenBao supplante step-ca, car les deux sont des CA autonomes et OpenBao en fait davantage. Il ne supplante pas tout à fait acme2certifier, parce que même en intermédiaire c’est OpenBao qui émet et non l’AD CS, distinction qui paraît byzantine jusqu’au jour où un auditeur veut que l’émetteur reste l’autorité corporate et ce jour-là acme2certifier redevient irremplaçable. Deux limites méritent par ailleurs d’être connues, que step-ca n’impose pas. Le serveur ACME d’OpenBao plafonne la validité des certificats à quatre-vingt-dix jours, quelle que soit la configuration du rôle et comme ACME suppose des certificats stockés, il faut automatiser le tidy sous peine de voir le cluster enfler avec le temps.

L’arbre de décision

Ramené à l’essentiel, cela se décide vite. Si vous exploitez déjà OpenBao ou Vault, prenez le moteur PKI et son ACME, presque toujours et faites signer l’intermédiaire par l’AD CS si vous devez chaîner au trust existant. Si vous ne faites pas tourner de coffre et que l’AD CS doit impérativement rester l’émetteur, c’est acme2certifier. Et si vous partez d’un périmètre isolé, un lab, un cluster qui n’a aucune raison d’hériter de la PKI corporate, alors step-ca reste le plus léger, sauf à prévoir de vouloir des secrets sous la main, auquel cas OpenBao vous coûtera un peu plus cher à dresser mais vous rendra dix fois plus de services.

Un mot enfin sur les pièges qui ne dépendent d’aucun de ces trois. ACME suppose une validation de challenge et en interne on bascule le plus souvent sur DNS-01 servi par le DNS interne, ce qui règle élégamment le cas des noms non exposés. Pensez aussi la durée de vie des certificats et l’automatisation du renouvellement dès le premier jour, faute de quoi vous aurez simplement remplacé la corvée manuelle d’hier par une corvée manuelle plus rapide, ce qui n’était pas exactement le but.

[edit: 2026] L’implémentation Ansible de tout ceci: le rôle openbao .