The Protocol Dream
The dream is one ACME client pointed at one free certificate authority (CA), renewing everything on a cron job until the heat death of the universe. It holds right up until you need a cert that CA structurally refuses to issue, and then the tidy picture shatters.
Start with the part that does work, because it works well. The 47-day cadence, covered in our previous article, continues on schedule. The part that makes it survivable at scale is ARI, ACME Renewal Information [2], which lets the issuing CA tell the client when to renew rather than leaving every client to guess and stampede.
ARI is also how a CA signals a mass-revocation event in advance, so the same mechanism that smooths ordinary renewal is the one that saves you when an issuer has to rotate a large batch of certificates on short notice. If your entire estate were public-facing domain-validated TLS, you could very nearly stop reading here.
It isn’t. Your estate has certificates that free public CAs cannot or will not issue, and the protocol layer is the part that will mislead us about that gap, because the protocol layer is actually converging. ACME began in the Web PKI, and it is steadily becoming the way internal issuance gets automated too.
Enterprise CAs now speak ACME on private networks. The device-attest-01 challenge, now an IETF ACME working-group draft [3], folds hardware-attested device enrollment into ACME itself, replacing what mobile-device management used to hand to SCEP. The client proves the certificate key was generated inside a secure crypto-processor it can’t be exported from, using a WebAuthn attestation statement, and external account binding lets the enterprise CA control exactly which devices may enroll.
The legacy protocols aren’t dead evenly:
- EST still owns a large installed base in the federal space
- CMP, with its Lightweight CMP Profile, is a shrinking niche outside a handful of telecom and industrial deployments
- SCEP lingers in network gear, mostly legacy installations [4]
The direction of travel is unmistakable: one protocol, perimeter and internal, services and devices. Which is exactly what makes the dream feel reachable, and exactly why it is about to mislead you.
Where Our Dream Breaks
Because the dream turns to reality and diverges at the CA, not the protocol. Let’s Encrypt is domain-validated (DV) by deliberate design and says so plainly: it does not issue, and has no plans to issue, organization-validated (OV) or extended-validation (EV) certificates. Human vetting those cannot be automated the way DV can [5]. That’s not a gap in their roadmap, it is the roadmap. The moment a service needs an OV or EV certificate, which is to say the moment a compliance regime or a counter-party demands a verified legal identity rather than mere control of a domain, you’re off Let’s Encrypt and onto a commercial CA with its own enrollment, its own profiles, and its own automation story.
That human-in-the-loop step doesn’t go away just because everything around it got automated. Your ACME tooling needs to know which certificate profiles still require manual vetting, route those requests differently, and account for the fact that a human on the CA’s side, working on business hours and business timelines, is now the slowest link in a pipeline built for six-week cadences. Automate the parts that can be automated and design process for the part that can’t (INTERNS FTW).
From there our divergence runs along three paths, each one independently forcing us off the single-CA road.
- Assurance level: DV from one source, OV and EV from another, because no single free-and-automated CA spans the range.
- Jurisdiction and scheme: A regulated European service can need two certificates for one endpoint at the same time. A qualified website authentication certificate satisfies eIDAS and the open-banking obligations under PSD2 [6], while a separate browser-trusted certificate comes from a CA in the root programs, because qualified status and browser trust are not the same trust and are not granted by the same body. You run both, on one service, sourced from two issuers, for reasons that have nothing to do with engineering convenience.
- Timing: As post-quantum issuance arrives, different CAs and different root programs will enable it on different schedules. The transition itself splits your portfolio between the CA that can issue what you need today and the one that can issue what you will need next.
Three different reasons, same conclusion: pick one CA and something on this list eventually tels us no.
Notice what’s not on that list: the protocol. Even with ACME spreading across public and internal issuance alike, a shared protocol unifies the wire format, not the policy above it. Different CAs expose different validation methods, different profiles, different external-account-binding requirements, and different rate limits. “We use ACME everywhere” describes your transport and almost nothing about your actual operational burden.
The burden has a resilience dimension the dream never accounts for. CAs do occasionally lose the trust of the root programs, and when an issuer is distrusted, the shops that can re-issue across a second CA in hours are in a very different position from the shops that built everything on one. Multi-CA stops looking like sprawl and starts looking like a preferred posture that survives a bad week.
This is the point at which everyone reaches for a certificate-lifecycle-management platform, and they are not wrong to. A Certificate Lifecycle Management (CLM) platform can discover, administer, and automate over a lot of this, but the fragmentation isn’t a tooling accident you can buy your way out of. It runs all the way down to the algorithms inside the certificate, and the reason it goes that deep is that the people writing the standards haven’t agreed with each other either.
Hey, that could be the next topic in this series!
References
[1] IETF RFC 8555. Automatic Certificate Management Environment (ACME)
[2] IETF RFC 9773. ACME Renewal Information Extension (ARI)
[3] IETF draft-ietf-acme-device-attest
[4] Older internal-enrollment protocols ACME is now displacing: EST (RFC 7030), CMP (RFC 4210) with the Lightweight CMP Profile (RFC 9483), and legacy SCEP (RFC 8894)
[5] Let’s Encrypt. FAQ: issues domain-validated certificates only, no OV or EV, by design.
[6] Regulation (EU) No 910/2014 (eIDAS), consolidated text as amended by Regulation (EU) 2024/1183. QWACs defined at Art. 3(38)–(39), requirements in Art. 45 and Annex IV; browser recognition obligation in Art. 45a.