How the ACME protocol automates certificate issuance

Abstract

In 2015, only about 40% of websites used HTTPS. Today HTTPS is used over 95% of the time. The ACME protocol made that shift possible.

The Automatic Certificate Management Environment (ACME) protocol enables software to automatically prove domain control to a certificate authority without any human involvement. No more generating CSRs by hand. No more copy-pasting into web forms. No more waiting for validation emails.

ACME largely solved certificate issuance. But it didn’t solve certificate operations. Getting a certificate is trivially easy now, but getting that certificate onto all the servers that need it? That’s still your problem.

What is the ACME protocol?

Before ACME, getting a certificate was a manual slog. The RFC 8555 specification itself describes the old process:

Generate a CSR using OpenSSL incantations you copied from Stack Overflow.
Paste it into a CA’s web form.
Prove domain ownership through some ad-hoc method (usually clicking a link in an email).
Download the certificate.
Figure out which format your server needs and install it manually.

The spec notes that webmasters needed 1-3 hours to get a certificate installed!

ACME automates all of this. Here’s the ACME protocol explained step by step:

Account registration. Your ACME client generates a key pair and registers with the CA. All future requests are signed with this key, so the CA knows they’re from you.
Order creation. The client sends a JSON request to the CA’s newOrder endpoint listing the domain names you want on the certificate. The CA responds with an order object containing authorization URLs for each domain.
Authorization. For each domain, the client fetches the authorization object, which contains available validation methods (more on that next). The client picks a validation method and implements the expected response, then tells the CA to validate.
Finalization. Once all authorizations pass, the client submits a Certificate Signing Request to the order’s finalize URL. The CA issues the certificate and provides a download URL.
Download. The client fetches the certificate chain and installs it.

The whole exchange happens over HTTPS using signed JSON messages. No web forms. No emails. No humans. A certificate that used to take hours now takes seconds.

Every major certificate authority supports the protocol today. It’s become the standard way certificates get issued.

ACME validation methods

The ACME protocol defines three validation methods to prove you control a domain, each with tradeoffs.

HTTP-01 is the simplest. The CA gives you a token, you put it in a file at /.well-known/acme-challenge/ on your web server. Works great for a single web server with port 80 open to the internet.

DNS-01 requires you to create a TXT record in your domain’s DNS with a specific value. It’s the only method that works for wildcard certificates. It also works when your server isn’t publicly accessible. But your ACME client needs to modify your DNS, which can be high-risk.

TLS-ALPN-01 validates over TLS on port 443 using a special ALPN protocol identifier. Useful when you can’t open port 80 but can control TLS termination.

The history of ACME

ACME emerged from two teams who discovered they were solving the same problem.

At Mozilla, Josh Aas and Eric Rescorla were designing a free, automated certificate authority. At the University of Michigan and EFF, Alex Halderman and Peter Eckersley were building a protocol for automatic certificate issuance. The teams found each other and merged efforts in 2013, incorporating the Internet Security Research Group as the nonprofit that would operate Let’s Encrypt.

They knew they needed an automated way to issue certificates, so they approached Richard Barnes, then at Mozilla, with the idea for software to automate certificate provisioning. He wrote the first ACME specification draft and the initial Let’s Encrypt CA software (Boulder) on a flight home from an IETF meeting. Some of that original code is still running in production. Barnes shepherded ACME through the IETF standardization process, which completed in March 2019 with RFC 8555.

The standardization process improved the protocol significantly. The IETF discussions led to a redesign where clients request certificates first and then complete required validations, rather than the original flow of validating domains before requesting certs. This made wildcard certificate handling more natural. The community also pushed for all requests to be authenticated, leading to the POST-as-GET pattern in the current spec.

For the full history with interviews from the people who built it, Christophe Brocas wrote an excellent piece worth reading.

A decade later, every major CA supports ACME. ZeroSSL, Google Trust Services, SSL.com, Sectigo, DigiCert. They had to. With a mechanism to automate certificates, the CA/Browser Forum voted in April 2025 to reduce maximum certificate lifetimes to 47 days by March 2029.

ACME keeps evolving

The protocol continues to develop. RFC 9773, published in 2025, adds ACME Renewal Information (ARI). ARI lets certificate authorities suggest renewal windows to clients, which is critical when a CA needs to mass-revoke certificates due to compliance issues. Let’s Encrypt now lets clients who renew via ARI bypass rate limits.

Two new challenge types are on the way. dns-persist-01 will allow you to link your DNS to an ACME issuer one time, so you don’t need to rotate keys. A new dns-account-01 challenge addresses multi-CDN environments. There’s even work on using ACME for device attestation certificates, extending the protocol well beyond its original web server use case.

The challenge is client-side adoption. Most ACME clients are “set and forget.” People install certbot, configure a cron job, and never touch it again. Aaron Gable, interviewed in Brocas’ blog above, notes that even when client projects implement new features like ARI, their massive install bases don’t update. The ecosystem turns over slowly.

What ACME doesn’t solve

ACME handles issuance, and that’s it. The protocol is a conversation between one client and one CA. What happens after the certificate arrives is outside the spec entirely.

Certbot, the original ACME client, works beautifully for one certificate, on one server. But you probably don’t just have one server.

You have a web farm. You have that legacy Windows box running a vendor application. You have staging environments and development servers. You have that one machine under someone’s desk that nobody remembers but is apparently critical to payroll. Should each of them be their own ACME client?

Certbot’s official guidance for multi-server deployments is essentially “figure it out yourself.” So people do. They write rsync scripts. They build Ansible playbooks. They create one-off certificate management systems that operate without monitoring or audit.

Each server needs to have HTTP port 80 open to the internet for validation, or worse hold credentials to update your DNS. DNS API keys scattered across your infrastructure, on every machine that might need a certificate. One compromised server and an attacker has write access to your entire DNS and take over.

How CertKit handles ACME

CertKit is a centralized ACME client that runs in one place. It talks to certificate authorities (Let’s Encrypt, Sectigo, your enterprise CA, whatever supports ACME), handles all the validation, manages renewals centrally, and then distributes certificates to wherever they need to go.

You don’t need to expose port 80 on every server, or pass around your DNS credentials. You create a CNAME record pointing the ACME challenge name to us, and we handle the rest. All your certificates are available in a secure file API or pushed where they need to go.

One place to manage ACME protocol certificates. Deployed everywhere they’re needed. Monitored so you know when something breaks before your customers tell you. We’re picking up where ACME left off, automating the rest of your certificate lifecycle management.