What is ACME protocol? How does ACME protocol work?

ACME (Automated Certificate Management Environment) is a protocol, defined in RFC 8555, that automates domain validation and certificate issuance so a server can obtain and renew a trusted certificate without human intervention.

ACME automates certificate issuance by having a client prove control of a domain through an HTTP or DNS challenge, then submitting a Certificate Signing Request that the CA verifies and signs automatically. Originally built by the Internet Security Research Group for Let’s Encrypt, ACME is now standardized in RFC 8555 and supported by many CAs for any certificate validity period they offer, not just Let’s Encrypt’s original 90-day default.

Key Takeaways

• ACME was built by ISRG for Let’s Encrypt, then standardized as RFC 8555. The Internet Engineering Task Force formalized the protocol so any CA, not just Let’s Encrypt, can implement it.
• Domain validation happens through HTTP or DNS challenges. The client proves control of a domain by placing a CA-provided string on the server or in a DNS record before the CA will issue a certificate.
• ACME automates the full lifecycle: issue, renew, and revoke. Client tools like Certbot handle all three actions without requiring a person to log into a CA portal.
• The 90-day default is a Let’s Encrypt policy choice, not a protocol limit. ACME itself supports any validity period a CA chooses to offer, which matters as the industry moves toward shorter validity periods under CA/Browser Forum Ballot SC-081v3.
• ACME cannot validate certificates on purely internal networks directly. Public CAs cannot reach internal-only systems for HTTP or DNS challenges, so internal ACME use requires a certificate manager that can make those connections locally.

How ACME Works, Step by Step

ACME automates the same core steps a manual certificate request follows, just without a human at any point in the process.

1. Client registration. The ACME client generates an account key pair and registers with the CA’s ACME server.
2. Domain authorization. The CA issues an HTTP-based or DNS-based challenge; the client proves control of the domain by satisfying it.
3. Order creation. The client creates an order specifying the certificate it needs.
4. CSR submission and issuance. The client generates a CSR and submits it; once the CA confirms the CSR and domain authorization are both valid, it issues the certificate.
5. Installation. The client installs the issued certificate on the server or device automatically.
6. Renewal or revocation. As the certificate approaches expiration, the client requests renewal through the same automated flow; revocation follows a similar signed request if needed.

The ACME Protocol Model

ACME runs over HTTPS using JSON Web Signature (JWS) objects, structured as a REST API between client and CA.

ACME clients are represented by an account key pair: the private key signs every message sent to the server, and the CA’s ACME server uses the corresponding public key to verify message authenticity and integrity. This same signed-request pattern covers registration, domain authorization, issuance, and revocation, giving ACME a single consistent security model across every operation it performs.

Where ACME Does and Does Not Apply

ACME works well for public-facing certificates but has real limits on internal networks and in incident response.

• Public CAs cannot reach internal-only systems. External ACME servers cannot make HTTP or DNS connections to systems inside a private network, so purely internal certificates need a certificate manager that can perform those checks locally.
• No built-in trigger for emergency replacement. ACME has no primary mechanism for automatically triggering certificate replacement in response to an event like a CA compromise; that still requires separate incident response tooling.
• Broad platform support is a genuine strength. A wide range of CAs, certificate managers, and clients across TLS servers and operating systems support ACME, which is unusual for a certificate protocol and adds real interoperability value.

Why the 90-Day Default Is a Policy Choice, Not a Protocol Limit

ACME’s association with Let’s Encrypt’s 90-day certificates leads to a common misunderstanding about what the protocol itself requires.

Let’s Encrypt chose a 90-day validity period as its own issuance policy when it built ACME to drive its business model, but nothing in RFC 8555 ties ACME to that specific window. Any CA implementing ACME can issue certificates for whatever validity period it supports, which is precisely why ACME is well positioned to handle the industry’s move toward much shorter validity periods, down to 47 days by 2029 under CA/Browser Forum Ballot SC-081v3, without any change to the underlying protocol.

How Encryption Consulting Helps

CertSecure Manager supports ACME-based issuance alongside SCEP and EST, automating certificate requests, domain validation, and renewal across public-facing and internal environments as certificate validity periods continue to shorten. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

Who created the ACME protocol?

The Internet Security Research Group (ISRG) originally developed ACME to power Let’s Encrypt’s automated certificate issuance. The Internet Engineering Task Force (IETF) later standardized it as RFC 8555, allowing any Certificate Authority to implement ACME, not just Let’s Encrypt.

Does ACME only issue 90-day certificates?

No. The 90-day default is a policy choice Let’s Encrypt made for its own service, not a limitation of the ACME protocol itself. Any CA implementing ACME can issue certificates for whatever validity period it supports, including the shorter periods the industry is moving toward under CA/Browser Forum Ballot SC-081v3.

Can ACME issue certificates for internal-only servers?

Not directly through a public CA, since external ACME servers cannot make HTTP or DNS connections to systems inside a private network to complete domain validation. Internal ACME-based issuance requires a certificate manager capable of making those validation connections locally within the network.

What happens if a CA is compromised while using ACME?

ACME has no built-in mechanism for automatically triggering certificate replacement in response to a CA compromise or similar event. Organizations still need separate incident response processes and tooling, such as a certificate management platform, to detect the compromise and force rapid reissuance.

Automate Certificate Issuance With ACME

Automate certificate lifecycles with CertSecure Manager across ACME, SCEP, and EST, ready for whatever validity period your CA supports.