← Back to Blog

ACME for the Enterprise: What It Solves and What It Doesn't

By the CertGov team • • 4 min read

ACME made certificate automation mainstream. It's the right foundation for the 47-day era, but on its own it automates issuance, not governance. Here is what ACME solves for an enterprise, what it leaves out, and how to fill the gaps.

What ACME Is

The Automatic Certificate Management Environment (ACME) protocol, standardized as RFC 8555 in 2019, lets software request, validate, and renew certificates from a CA without human involvement. Let's Encrypt popularized it, and most major commercial CAs now offer ACME endpoints as well.

A typical ACME exchange looks like this:

  1. The client registers an account with the CA, identified by its own key pair.
  2. It places an order for one or more domain names.
  3. The CA issues challenges to prove domain control: HTTP-01 (serve a file over HTTP), DNS-01 (publish a DNS TXT record), or TLS-ALPN-01 (answer on port 443).
  4. Once validated, the client finalizes the order with a CSR and downloads the certificate.

Commercial CAs usually add External Account Binding (EAB), which ties an ACME account to your paid CA account, so issuance is billed and attributed correctly. And ACME Renewal Information (RFC 9773) lets the CA tell clients when to renew.

What ACME Solves

  • Hands-free issuance and renewal for any system that can run a client, from certbot on a single server to cert-manager across a Kubernetes fleet.
  • A standard interface, so you can change CAs by changing a URL instead of rewriting automation.
  • Built-in domain validation that scales with shorter lifetimes, as long as the challenges themselves are automated.

For many organizations, adopting ACME is the single biggest step toward surviving 47-day certificates.

What ACME Leaves Out

ACME answers one question: can this client prove control of this domain? An enterprise needs answers to several more.

  • Who may request what. Anyone with an ACME account and the ability to pass a challenge can get a certificate, including a wildcard, from any CA that accepts them. There is no built-in notion of policy per domain or team.
  • Approval. ACME has no step where a person can review a request before it is issued.
  • Inventory. Each client knows only its own certificates. Nothing in ACME tells you about certificates issued by other teams, other clients, or other CAs.
  • Audit. You get logs scattered across every client and CA account, not one record of who requested which certificate and why.
  • Endpoints that can't run a client. Load balancers, session border controllers, and older systems often can't run ACME at all.
  • Credential sprawl. ACME account keys and DNS API tokens end up copied across servers and pipelines, often with far broader access than they need.

Enterprise Patterns That Close the Gaps

Put a governed ACME endpoint in front of your CAs

Instead of every client talking to every CA directly, point clients at a central ACME endpoint you control. It checks each request against policy, routes sensitive ones for approval, records everything, and only then passes the request to the right CA. Clients still use standard ACME, so nothing changes for developers.

Separate accounts and least-privilege credentials

Give each team or environment its own ACME credentials, scoped to the names it is allowed to request, so one leaked key can't issue for the whole company.

Delegate DNS validation

Use CNAME delegation of _acme-challenge records to a dedicated validation zone, so automation never needs write access to your production DNS.

Cover non-ACME endpoints with agents

For devices that can't run a client, use an agent that obtains certificates on their behalf and installs them through the device's management API.

Keep one inventory and one audit trail

Combine what your ACME endpoint issues with what you discover elsewhere, so the inventory includes certificates that never went through ACME. See how to find every certificate you have.

How CertGov fits

CertGov provides a full ACME endpoint (RFC 8555) that works with certbot, acme.sh, Caddy, and Traefik. Every request is evaluated against your Domain Trust Profiles before it reaches a CA, sensitive requests go to an approver, and everything lands in a tamper-evident audit trail. A REST API and CLI cover systems that don't speak ACME, and closed-loop delivery handles network devices.

The Bottom Line

Adopt ACME everywhere you can. Then add the layer ACME was never designed to provide: policy, approvals, inventory, and audit across every client and every CA.