Mention ACME to most engineers and they think of Let’s Encrypt. That association is understandable, because Let’s Encrypt made ACME famous by issuing hundreds of millions of free certificates through it, but it has quietly become a problem for enterprise planning. Teams conclude that ACME is a thing for public websites and hobby projects, that it means free domain-validated certificates with ninety-day lifetimes, and that serious internal PKI is a separate world that automates some other way. All three of those conclusions are wrong, and they cause organizations to build custom renewal tooling for problems ACME already solved.
ACME is a standardized protocol for automated certificate issuance and renewal, defined in RFC 8555. It describes how a client proves control of an identity and asks a server to issue a certificate, with no renewal paperwork and no human in the loop. Nothing in the protocol ties it to Let’s Encrypt, to free certificates, to ninety-day lifetimes, or to public domains. Those are properties of one popular ACME server, not of ACME. Once you separate the protocol from that one implementation, a large part of enterprise certificate automation becomes a matter of pointing an ACME client at the right server.
This post is about ACME as enterprise infrastructure: the commercial CAs that speak it, the internal CAs you can run yourself, the external account binding that enterprises need, the challenge types that work inside private networks, and the clear line where ACME’s job ends and a certificate lifecycle platform’s job begins.
Renewal Workload Explosion
300 certificates: annual renewals & engineer hours as lifespans shrink
8×
More renewals at 47 days vs 1 year
1,200 hrs
= 0.6 FTE doing nothing but renewals
ACME Is a Protocol, Not a Vendor
The single most useful thing to internalize is that ACME is a conversation, not a company. The conversation has a fixed shape. A client creates an account with an ACME server, submits an order for a certificate covering one or more identifiers, receives challenges that prove it controls those identifiers, completes the challenges, and then downloads the issued certificate. Renewal is simply the same conversation run again before the certificate expires. The client handles all of it automatically.
Because the protocol is standardized, any ACME client can talk to any ACME server. The same client that renews a public certificate from Let’s Encrypt can renew an internal certificate from your own CA, provided both speak ACME. This is the property enterprises underuse. Instead of one automation mechanism for public certificates and a pile of custom scripts for internal ones, a single protocol can cover both, with the same clients, the same renewal logic, and the same operational model.
The renewal workload is the reason this matters. The chart above shows how manual renewal effort grows with certificate count while automated renewal effort stays nearly flat. An enterprise with thousands of certificates cannot renew them by hand, and writing bespoke renewal automation per CA is its own maintenance burden. ACME lets you adopt one automation standard across many certificate sources, which is the difference between renewal effort that scales with your estate and renewal effort that stays constant.
Commercial CAs That Speak ACME
The assumption that ACME means free certificates falls apart the moment you look at the commercial CA landscape. Major commercial certificate authorities support ACME, which means you can get the automation benefits of ACME together with the things enterprises buy commercial certificates for: organization validation, extended validation, warranty, support, and trust-store ubiquity.
DigiCert, Sectigo, and Entrust, among others, offer ACME endpoints for their certificate products. From the client’s perspective the mechanics are the same as Let’s Encrypt: account, order, challenge, issue, renew. The differences are commercial and governance-related rather than protocol-related. You authenticate to a paid account, you may be issuing organization-validated or EV certificates rather than domain-validated ones, and you are bound by whatever issuance policy the CA and your contract define.
This combination is what enterprise automation actually wants. The reason many organizations historically did not automate their commercial certificates was not that automation was impossible but that each CA had a proprietary API, so automating meant writing and maintaining CA-specific integration code. A commercial CA with an ACME endpoint removes that friction. The same client and renewal logic that handles your public free certificates handles your paid commercial ones, and switching or adding a CA becomes a configuration change rather than a development project.
Why EAB Matters for Commercial ACME
Public ACME from Let’s Encrypt lets anyone create an account anonymously, because domain control is the only thing being proven. A commercial CA cannot work that way. It needs to know the ACME account belongs to a paying, contracted customer before it issues anything. This is what external account binding, or EAB, solves.
EAB links a new ACME account to a pre-existing account at the CA. The CA gives you a key identifier and an HMAC key out of band, through its portal, and your ACME client presents those when it first registers. The CA then binds the ACME account to your commercial account, applies your entitlements and policies, and bills correctly. After that first binding, renewal proceeds like any ACME flow.
For enterprises this is the mechanism that makes governed, paid, automated issuance possible. Without EAB, anyone who could reach the ACME endpoint could request certificates. With it, ACME issuance is tied to an identity the CA recognizes and a policy it enforces, which is exactly the control an enterprise needs before it automates issuance at scale.
Internal ACME: Running Your Own
ACME is not only for public and commercial CAs. You can run an ACME server in front of your own internal CA and automate internal certificate issuance the same way, which is often the larger and messier half of an enterprise certificate estate.
Two tools dominate this space. step-ca is a lightweight open-source CA that speaks ACME natively and is well suited to teams that want a straightforward internal CA with modern automation built in. EJBCA is a heavyweight, feature-rich CA used in large and regulated environments, and it supports ACME alongside the many other enrolment protocols it implements. Microsoft’s Active Directory Certificate Services has historically centered on its own enrolment protocols rather than ACME, which is one reason organizations layer ACME-capable tooling in front of or alongside ADCS.
Running internal ACME changes the economics of internal certificates. Internal certificates have no per-certificate cost, so teams issue them freely, and the result is often a large population of internal TLS certificates renewed by hand or by scattered scripts. Putting an ACME server in front of the internal CA lets all of those certificates renew through the same automated protocol as everything else, which both cuts the manual workload and brings internal certificates into a consistent, observable process instead of a collection of one-off cron jobs.
Challenge Types and the Private Network Problem
ACME proves control of an identifier through a challenge, and the challenge type you can use depends heavily on whether the identifier is reachable from the public internet. This is where enterprise ACME diverges most from the Let’s Encrypt experience, because enterprise identifiers are frequently internal and not publicly reachable at all.
The common challenge types matter for different situations:
| Challenge | How It Proves Control | Enterprise Fit |
|---|---|---|
| HTTP-01 | Client serves a token at a well-known URL over HTTP | Works for publicly reachable web servers; useless for internal-only hosts the ACME server cannot reach |
| DNS-01 | Client places a token in a DNS TXT record | Works for internal hosts as long as the ACME server can resolve the DNS record; supports wildcards; the enterprise workhorse |
| TLS-ALPN-01 | Client proves control during a special TLS handshake on port 443 | Useful where only port 443 is available; still requires reachability |
For internal networks the practical answer is usually DNS-01. It does not require the ACME server to connect inbound to the host being certified, only to resolve a DNS record, which fits the reality that internal hosts sit behind firewalls and are not reachable from a public validation server. DNS-01 is also the only common challenge that supports wildcard certificates. With an internal ACME server and internal DNS, DNS-01 lets you automate issuance for hosts that a public CA could never validate because it could never reach them.
The design consequence is that enterprise ACME planning is largely DNS integration planning. Your ACME automation needs programmatic access to update DNS records, which means integrating with your DNS provider or internal DNS, and that integration becomes the backbone of automated issuance across the internal estate.
Where ACME Stops and a CLM Platform Starts
ACME is excellent at one job and silent on several others, and understanding that boundary is what prevents teams from either underusing ACME or expecting it to be a certificate management platform it was never designed to be.
ACME handles issuance and renewal of certificates for identifiers you already know about, through challenges you can already satisfy. Within that scope it is complete and reliable. It is a protocol for the act of getting and refreshing a certificate.
ACME does not do the things around that act:
- It does not tell you which certificates exist across your estate, including the ones issued outside ACME, by hand, or by shadow processes. Discovery is out of scope.
- It does not maintain an inventory, an owner for each certificate, or a record of where each certificate is deployed. State and ownership are out of scope.
- It does not enforce policy across CAs, report on compliance, or give you a single view of expiry risk across every certificate source. Governance and reporting are out of scope.
- It does not install the renewed certificate onto the device or service and reload it, beyond what a given client plugin happens to support. Deployment is only partially addressed and varies by client.
This is the honest line. ACME is the automation primitive for issuance and renewal. A certificate lifecycle management platform is the system that knows what you have, who owns it, where it lives, whether it complies, and that then uses ACME, and other enrolment protocols, as one of its mechanisms for the issuance and renewal step. ACME answers “refresh this certificate.” The platform answers “what certificates do we have, which are at risk, who owns them, and are they all renewing,” and uses ACME to carry out the refresh.
Teams that understand this use ACME everywhere it fits, across public, commercial, and internal CAs, and layer management on top rather than trying to make ACME itself the management layer. That combination, broad ACME automation under a governing platform, is what enterprise certificate operations look like when they work.
FAQ
Q: Is ACME only for Let’s Encrypt? No. ACME is a standardized protocol defined in RFC 8555, and Let’s Encrypt is one popular server that implements it. Commercial CAs such as DigiCert, Sectigo, and Entrust offer ACME endpoints, and you can run ACME in front of your own internal CA with tools like step-ca or EJBCA. The protocol is independent of any single vendor.
Q: What is external account binding and when do I need it? External account binding, or EAB, links a new ACME account to a pre-existing account at a CA using a key identifier and HMAC key the CA provides out of band. You need it for commercial and governed ACME issuance, where the CA must confirm the account belongs to a contracted customer before issuing. Public domain-validated ACME from Let’s Encrypt does not require it.
Q: Which ACME challenge works for internal hosts that are not publicly reachable? DNS-01 is the enterprise workhorse. It proves control by placing a token in a DNS record rather than requiring the ACME server to connect to the host, so it works for internal hosts behind firewalls as long as the server can resolve the DNS record. It is also the only common challenge that supports wildcard certificates.
Q: Can ACME automate my paid commercial certificates? Yes, if your CA offers an ACME endpoint. You get the automation of ACME together with organization or extended validation, warranty, and support. The main setup difference is EAB, which binds the ACME account to your commercial account so issuance is tied to your entitlements and policy.
Q: If I adopt ACME everywhere, do I still need a certificate management platform? Yes. ACME handles issuance and renewal for certificates you already know about, but it does not discover unmanaged certificates, maintain an inventory and owners, enforce policy across CAs, or report compliance and expiry risk. A lifecycle platform provides those functions and uses ACME as one of its issuance mechanisms.
About QCecuring
QCecuring helps enterprises get the full value of ACME across public, commercial, and internal certificate authorities. Our platform drives ACME issuance and renewal, including EAB-bound commercial accounts and DNS-01 automation for internal hosts, while providing the discovery, inventory, ownership, policy, and reporting that ACME itself leaves out, so automation and governance come from one place.
Automate certificate renewal with ACME under full governance
Tags: Certificate Lifecycle Management, PKI Automation, ACME, RFC 8555, Let’s Encrypt, DigiCert, Sectigo, Entrust, EAB, External Account Binding, DNS-01, HTTP-01, step-ca, EJBCA, Internal CA, Certificate Renewal, Enterprise PKI