Doing internal ACME without begging the AD CS team

At some point, in any slightly serious infrastructure, one wants to issue internal certificates the way Let’s Encrypt issues its own: automatically, through ACME, no ticket, no form, no negotiating every renewal with the person holding the keys of the in-house certificate authority. The problem is not technical at first glance; it is political, because in nine out of ten companies the PKI lives inside an AD CS that the Windows team guards jealously and nobody deploys a second trust root across the whole fleet just to make life easier. Three families of tools answer this need and while people usually believe they must choose between two of them, the third has quietly changed the game for anyone already running a secrets vault.

step-ca: the dedicated PKI you own

step-ca, by Smallstep, Apache 2.0, is a self-contained certificate authority speaking ACME natively, standing up in minutes. You give it a root, define provisioners, enable the challenge that suits your internal network and you get an entirely self-controlled Let’s Encrypt experience, including the very short certificate lifetimes traditional AD CS could not serve without grinding. Its virtue is lightness: the fastest option to stand up when you want a dedicated PKI and nothing else. Its price is obvious and owned: a new root, which must be distributed and adopted by every client.

acme2certifier: the translator that preserves the issuer

acme2certifier, free software as well, does not pretend to be a certificate authority. It is an ACME proxy, a translator presenting a clean ACME interface on the client side while, on the server side, leaning on an existing CA through a series of handlers, including one for Microsoft’s web enrollment interfaces. The crucial point: AD CS actually issues the certificates, with its policies, templates and audit trail, acme2certifier merely installing a modern front door for it. That is exactly what makes it the only right choice when the security team demands the issuing authority remain AD CS and refuses any delegated CA.

OpenBao: the consolidation

And then there is the case, increasingly common, where you already run a secrets vault. OpenBao , the free fork of Vault under MPL 2.0, embeds a PKI engine that is a full CA, with a native ACME server that certbot, Traefik or cert-manager plug into directly. Given the vault is already there, you get secrets, PKI and ACME in one identity-authenticated system, which is hard to beat for operational coherence. Better, OpenBao plays both roles: either as a standalone root in the step-ca style, or as an intermediate whose CSR is signed by the AD CS root, in which case its certificates chain properly into the trust store the fleet already recognizes.

That flexibility is why people rightly say OpenBao supplants nearly everything else, but let us keep the nuance. OpenBao supplants step-ca, since both are standalone CAs and OpenBao does more. It does not quite supplant acme2certifier, because even as an intermediate it is OpenBao that issues, not AD CS, a distinction that looks byzantine until the day an auditor wants the issuer to remain the corporate authority and on that day acme2certifier becomes irreplaceable again. Two limits are worth knowing, which step-ca does not impose: OpenBao’s ACME server caps certificate validity at ninety days regardless of role configuration and since ACME assumes stored certificates, the tidy operation must be automated or the cluster will swell over time.

The decision tree

Reduced to essentials, the choice is quick. If you already run OpenBao or Vault, take the PKI engine and its ACME, almost always and have the intermediate signed by AD CS if you must chain to the existing trust. If you run no vault and AD CS must imperatively remain the issuer, that is acme2certifier. And if you start from an isolated perimeter, a lab, a cluster with no reason to inherit the corporate PKI, then step-ca stays the lightest, unless you foresee wanting secrets at hand, in which case OpenBao costs a little more to stand up but repays it tenfold.

One last word on the traps independent of all three. ACME assumes challenge validation and internally one usually falls back to DNS-01 served by the internal DNS, which elegantly handles non-exposed names. Think about certificate lifetimes and renewal automation from day one, otherwise you will simply have replaced yesterday’s manual chore with a faster manual chore, which was not exactly the point.

[edit: 2026] The Ansible implementation of all this: the openbao role .