What Is the ACME Protocol?

ACME Protocol Explained

Certificates are machine identities that authenticate systems, establish trust, and encrypt traffic between services, users, and devices. When certificate counts climb into the hundreds or thousands, manual renewal breaks first, then outages hit at the worst possible time, during releases, peak traffic, or incident response.

ACME standardizes certificate lifecycle actions, enabling systems to request, validate, renew, and revoke certificates on schedule without manual intervention. That reliability is a core Identity security outcome because it protects authentication flows from sudden failures and reduces the need for risky workarounds, such as extending certificate lifetimes or reusing keys.

The urgency behind ACME adoption is partly market-driven. The CA/Browser Forum has been steadily reducing maximum certificate lifetimes, from years to 90 days for many public CAs, with proposals to push further toward 47 days or even shorter. At these lifetimes, manual renewal isn’t just inefficient; it’s operationally impossible at scale. ACME adoption is increasingly a requirement rather than an optimization.

ACME works best when you treat certificate automation as identity governance, not as a convenience feature. In practice, that means you control who can issue certificates, how domain validation happens, where keys are stored, and how events are logged and reviewed, just like any other Identity security control.

ACME Protocol Automation Loop Diagram

How The ACME Protocol Works

The ACME protocol functions through a structured exchange of JSON messages over secure HTTPS connections. This process replaces the traditional, manual Certificate Signing Request (CSR) workflow with an automated agent-based model.

The Role of the ACME Client

The client is an agent installed on the web server or infrastructure requiring protection. It initiates requests for new certificates, handles cryptographic challenges, and monitors expiration dates. Because these agents function as highly privileged services, they are central to modern security strategies for non-human identities.

The Role of the ACME Server

The server resides with the Certificate Authority (CA), such as Let’s Encrypt or a private enterprise CA. It manages the account registrations, issues challenges to the client, and finalizes the issuance once the client proves domain control.

ACME Validation Methods: Challenges and Tradeoffs

To prove a requester owns a domain, the ACME protocol uses specific "challenges." Each method has distinct security implications for enterprise infrastructure.

• HTTP-01 Challenge: The client places a specific token at a predetermined URL on the web server. The CA verifies this token via a standard HTTP request.
• DNS-01 Challenge: The client creates a TXT record in the domain’s DNS settings. This is the only method that supports wildcard certificates.
• TLS-ALPN-01 Challenge: Validation occurs over TLS port 443 using a specific protocol identifier. This is ideal for environments where port 80 is restricted.

Real-World Benefits of Certificate Automation

Manual certificate management is error-prone and leads to significant operational risk. ACME provides an extensible framework that ensures identity lifecycle management remains consistent across sprawling cloud environments.

By automating the "monitor-renew-install" loop, organizations prevent expired certificates from causing application downtime. ACME supports CA agility by standardizing the issuance interface, reducing the work required to switch certificate authorities. However, achieving clean CA rotation in practice also requires abstracting CA-specific configurations, such as endpoint URLs, account registrations, and differences in challenge behavior, behind a management layer.

ACME Across The Machine Identity Lifecycle

This mapping frames ACME as a lifecycle control for machine identity programs.

Issue

ACME issues certificates when a new service or endpoint comes online. You control risk by restricting who can initiate orders and who can complete challenges.

Deploy

After issuance, systems deploy the certificate and private key to the appropriate runtime component, such as an ingress, proxy, or service mesh component. Poor deployment controls cause private key sprawl, and automation amplifies that sprawl.

Rotate

Rotation is ACME’s primary value. Frequent renewal reduces long-lived credential exposure, but only if you alert quickly to failures and recover cleanly.

Revoke

Revocation matters when keys leak or ownership changes. ACME supports revocation functions, but two problems limit its effectiveness:

1. Many teams do not integrate revocation into incident response workflows, so compromised certificates remain active.
2. Revocation checking itself is unreliable across the ecosystem because many clients implement OCSP and CRL checks as soft-fail or skip them entirely. This is a primary reason the industry has moved toward shorter certificate lifetimes as the practical mitigation: if a certificate expires in hours or days, the window of exposure from a compromised certificate shrinks even without reliable revocation.

Audit

ACME creates a trail of orders, validations, and renewals. Centralizing these logs gives you accountability for who issued what, when, and why, which helps both investigations and compliance.

ACME Challenges

ACME uses challenge-response to prove control of a domain. Teams often choose DNS-based validation for wildcard certificates and locked-down environments, and they choose HTTP-based validation for simpler public endpoints.

If you validate through DNS, DNS access becomes your issuance perimeter. Treat DNS API tokens like high-value credentials because they effectively control who can obtain certificates.

Why ACME Matters For Machine Identity Security

Machine identity security focuses on discovering, governing, and protecting non-human credentials, such as certificates, keys, and tokens. ACME helps teams keep certificate lifecycles aligned with cloud speed, especially when workloads change quickly, and services rely on TLS for trust.

ACME also reduces the temptation to stretch certificate lifetimes just to avoid renewals. Shorter lifetimes can reduce blast radius, but only if you can rotate reliably.

Implementation Patterns

ACME appears in a few recurring architectures. Choose the pattern that matches where you terminate TLS and who owns renewal operations.

Pattern 1: Ingress-Based Issuance

A central ingress controller requests and renews certificates for public endpoints, then serves TLS at the edge. This pattern keeps automation in one place and reduces key sprawl, but it creates a shared failure domain if teams overload one issuer pipeline.

Best Fit: Internet-facing apps with standardized ingress
Watch Out: A single failed renewal pipeline can impact many hostnames

Pattern 2: Service Mesh and mTLS Rotation

Workloads use a service mesh, a sidecar, or a workload identity framework such as SPIFFE/SPIRE to issue and rotate short-lived certificates for service-to-service authentication. In many implementations, workload identity platforms handle issuance directly through platform-level attestation rather than domain-based ACME challenges, making this pattern architecturally distinct from ACME even though the outcome (short-lived mTLS certificates) is similar.

Teams should evaluate whether ACME or a workload identity framework is the right issuance model for east-west traffic. This pattern supports short-lived identities and continuous rotation, which aligns with machine identity programs.

Best Fit: Microservices, east-west traffic, mTLS at scale
Watch Out: Teams bypass mesh controls during outages, then identity drift follows

Pattern 3: Internal CA With ACME As The Front Door

An internal certificate authority issues certificates, and ACME provides the standard automation interface for teams and platforms. This pattern keeps issuance within your trust boundary and supports consistent policy enforcement, but it requires strong DNS and key governance.

Best Fit: Enterprise internal services and private domains
Watch Out: DNS API token sprawl and weak ACME account key storage

Which Pattern Should You Choose?

Real World Evidence

Threat Model 1: ACME Client Compromise (Automated Certificate Abuse)

Unit 42 reporting continues to show that identity-driven access is a primary driver of attacker success. As organizations scale ACME to manage certificates at volume, the ACME client environment (the agent, its service account, and its secrets) becomes a high-value target.

• Automated speed, amplified: Attackers can operationalize newly disclosed weaknesses quickly. If an adversary compromises an ACME client—or gains access to the client’s credentials—they can automate certificate requests and obtain fraudulent certificates that allow malicious services to impersonate legitimate ones.
• What’s actually at risk: In this scenario, the attacker’s leverage comes from control of the ACME client or its keys (e.g., API tokens, account keys, CI/CD secrets, workload identity).
• Primary defensive investments: Focus on strong, key-based storage and access controls—HSM/KMS-protected where possible, least-privileged access for ACME-related identities, secret rotation, locked-down CI/CD runners, and tight audit trails for certificate issuance actions.

Threat Model 2: DNS or Domain Control Compromise (Abusing Legitimate ACME Workflows)

Separate from client compromise is a second, equally common pattern: attackers never touch the ACME client. Instead, they compromise the domain’s control plane—most often DNS—then use a perfectly legitimate ACME workflow to obtain certificates.

Unit 42 has documented incidents where adversaries abused Let’s Encrypt during DNS hijacking to issue certificates that made malicious infrastructure appear trustworthy. This is an example of infrastructure compromise, not ACME client compromise.

• Why this matters for ACME programs: DNS often gates certificate issuance (especially for DNS-01). If an attacker takes over DNS, they can satisfy validation challenges and obtain certificates that blend into normal traffic patterns—even when the ACME client remains secure.
• Primary defensive investments: Prioritize DNS security controls (lock down registrar/DNS accounts, MFA, least privilege, change control), plus Certificate Transparency monitoring to detect unexpected issuance, and CAA records to restrict which CAs are allowed to issue for your domains.

Bottom line: These are two distinct paths to bad certificates—client/key compromise vs. DNS/domain control compromise, and they require different security budgets.

Where ACME Secrets Leak In Real Life

Use this as a quick checklist during onboarding, troubleshooting, and incident review.

• Account Keys: Teams store ACME account keys in repos or shared admin boxes, then forget they exist. If attackers steal the key, they can attempt unauthorized certificate actions.
• DNS Tokens: DNS automation uses provider tokens that often carry broad permissions. If those tokens leak, attackers can satisfy DNS challenges and pivot into certificate issuance.
• Private Keys: Automation pipelines write private keys to disk in logs or temporary folders. That behavior turns certificate automation into key sprawl.
• Ingress Configs: Engineers copy validation configs across environments and misroute challenge paths. Misroutes cause silent failures and can expose validation endpoints.

ACME Technical Decision Table

ACME Protocol FAQs