Teaching AD CS New Tricks: ACME, SCEP, and the DevOps Pipeline
If Linux is the largest island in the archipelago, DevOps is the fastest-moving one. Kubernetes clusters, CI/CD pipelines, and cloud workloads don't ask for certificates the way a Windows server does — they expect them to simply appear, renew themselves, and disappear again when a pod is torn down. The protocol most of that tooling already speaks is ACME. The protocol AD CS speaks natively is, in a word, none of the above.
A Gap That Shows Up in Public, Repeatedly
This isn't a niche complaint. Back in 2019, someone opened a feature request on the cert-manager GitHub repository asking, in essence, whether there were any plans to support Microsoft AD CS as an issuer type, noting there was likely a market for it among organisations that "use MS services internally and serve some K8s based services." The issue is still open. Six years on, the demand clearly never went away — it just got solved outside the core project, by individual maintainers building their own connectors.
A DevOps lead we spoke with summed up the friction: "Our Kubernetes clusters expect cert-manager and ACME. Our root of trust is AD CS. Somewhere in between, somebody has to build the bridge — and that somebody was me."
Three Bridges Teams Have Actually Built
- ACME-Server-AD CS. Built by a single maintainer (glatzert), implements a standards-compliant ACME (RFC 8555) server that sits in front of this project ADCS, translating requests from any ACME client — certbot, acme.sh, etc. you name it — into ADCS submissions. It's a genuinely impressive piece of engineering, supporting http-01, dns-01, and tls-alpn-01 challenges. It's also worth noting explicitly: the project's own licensing terms state it is not free for commercial use, which is easy to miss when a team adopts it during a quick proof of concept and only discovers the restriction once it's running in production.
- The cert-manager AD CS issuer. Originally built by an engineer at Nokia and published as nokia/adcs-issuer, this project lets cert-manager request certificates directly from AD CS over HTTP using NTLM authentication, so Kubernetes workloads can get AD CS-signed certificates the same way they'd get any other cert-manager-issued one. As the original repository's activity slowed, the community didn't wait — a maintained fork now lives under djkormo/adcs-issuer, with its own Helm chart and active development, and at least one other fork is maintained independently by a different contributor. That's a healthy outcome for an open-source project. It's also a live, ongoing demonstration of exactly the dependency risk we keep coming back to in this series: the tool your production clusters rely on for certificates can change hands, and you find out by noticing which fork has the recent commits.
- SCEP gateways and translation layers. For appliances and devices that speak SCEP rather than ACME, the pattern is similar — a small service translates SCEP requests into AD CS submissions. These are typically the least standardised of the three approaches, often built in-house for one specific device type, and rarely documented beyond a README and whoever wrote it.
What "Elegant but Fragile" Looks Like in Practice
None of the projects above are poorly built. That's actually what makes the underlying risk easy to miss: when a community-maintained gateway works well, it can run quietly in production for years, which makes it feel like infrastructure rather than what it actually is — a dependency on volunteer effort. A few things tend to surface once that dependency has been running for a while
- Licensing terms can outlast your awareness of them. A project adopted as a free proof of concept can carry commercial-use restrictions that only become a compliance question once legal or procurement notices the gateway in production.
- Maintainer continuity isn't guaranteed, even for good projects. The Nokia-to-community-fork transition for the cert-manager AD CS issuer is a good outcome precisely because someone stepped in. That's not something you can plan around in advance.
- NTLM and legacy auth paths carry their own exposure. Several of these gateways authenticate to AD CS using NTLM, which brings its own well-documented security considerations into a pipeline that's otherwise built on modern, short-lived credentials.
- Each gateway is its own island of visibility. A certificate issued through the ACME gateway, one issued through the cert-manager issuer, and one issued through a SCEP translator for your appliances are three different systems to check when someone asks "which certificates expire this month."
- Debugging crosses a boundary nobody owns. When a renewal fails, the question of whether the fault is in the gateway, the AD CS template, or the underlying CA tends to fall to whoever happens to be on call, regardless of who actually understands the gateway's code.
A Protocol Gap, Not a Product Flaw
To be fair to Microsoft: AD CS predates ACME by well over a decade, so this isn't a case of Microsoft overlooking something obvious — it's a CA built for one enrollment model meeting workloads that now expect another. The gap is real, and the community projects that bridge it are genuinely good engineering. What they can't offer, by their nature as community tools, is a guaranteed maintenance roadmap, formal support, or a unified view across the ACME, SCEP, and Windows auto-enrollment paths your environment is now running simultaneously.
Where This Leaves You
If your Kubernetes clusters or DevOps pipelines are already getting certificates from AD CS through one of these bridges, that's a sign your team solved a real problem well. The question worth revisiting periodically is who's accountable for that bridge today, what happens if its maintainer moves on tomorrow, and whether you can currently answer "what's expiring across ACME, SCEP, and Windows auto-enrollment this week" from a single place.
This is exactly the layer CEMA Certificate Lifecycle Management is designed to provide: native ACME and SCEP endpoints backed by AD CS, with one governed view across every protocol and platform your pipelines actually use — supported, maintained, and accountable in a way a single-maintainer GitHub project, however well built, was never meant to be.