Bridge SSL
ACME explained: how automated certificate issuance works
ACME, standardised as RFC 8555, is a protocol that lets software request, obtain, renew and revoke certificates with no person involved at any step [1]. ACME certificates are ordinary certificates: the protocol changes how a certificate authority checks the request and hands over the result, not what the certificate is [1].
The name stands for Automatic Certificate Management Environment, and knowing that helps nobody. What matters is the exchange it defines.
- What it proves
- control of each name, which is domain validation [1]
- Wildcard names
- of the three standard ACME challenges, only DNS-01; HTTP-01 and TLS-ALPN-01 are not allowed [4]
- Renewal
- a new order; the protocol has no separate renewal operation [1]
- Two keys
- the account key signs requests; the certificate key travels in the signing request and must differ from it [1]
What the protocol does
The ACME protocol starts with an account. The client generates a key pair and signs the account request with it; this account key identifies you in every later request, and it must not be the key that goes into a certificate [1]. With the account in place, a certificate takes four steps, performed by software on your side against a service run by the authority [1].
Order a certificate for some names
The client lists the hostnames it wants covered. The authority answers with the authorizations it needs, one or more challenges for each name [1].
Prove control of each name
The client completes one challenge per name and tells the authority it is ready; the authority then checks. This is the step everything else depends on, and the different ways of doing it are the main thing to understand.
Finalize with a signing request
The client submits a certificate signing request carrying the public key to be certified [1].
Download the certificate
The authority issues it, and the client fetches the certificate together with its chain, as PEM by default [1].
Renewal and revocation
Renewing a certificate with ACME means placing a new order: a certificate never changes once issued, and there is no separate renewal operation [1]. The authority can skip the challenge when an authorization the client completed earlier for that name has not expired [1]. RFC 9773 adds a way for the authority to suggest when each certificate should be renewed [3]. Revocation goes through the same interface, as a request signed by an account authorized for the certificate or by the certificate's own private key [1].
The three challenges
Each challenge proves control of a name in a different way, and each has a situation where it is the only option. In all three, the response is built from the challenge token and a fingerprint of your account key, so it is tied to that account; the certificate authority checks it from its own side [1][2].
| Challenge | How the client proves control | What it needs from you | Wildcard names |
|---|---|---|---|
| HTTP-01 | serves a file at /.well-known/acme-challenge/<token>, fetched over HTTP on port 80 [1] | a web server the name already points to, reachable on port 80; no DNS access | not allowed [4] |
| DNS-01 | publishes a TXT record for the name [1] | the ability to change DNS automatically | allowed [4] |
| TLS-ALPN-01 | presents a validation certificate during a TLS handshake on port 443, under the acme-tls/1 protocol [2] | control of the TLS endpoint for the name | not allowed [4] |
Circumstance makes the choice, not preference. Only DNS validation is left for wildcard SSL certificates [4]. A closed port 80 rules out HTTP validation and leaves TLS-ALPN-01 or DNS-01. Everything else can default to HTTP validation, because it needs the least access.
What automation actually requires
The protocol is the easy part. What it demands of your environment is where setups succeed or fail.
Something must run regularly
Renewal happens on a schedule, so a process, a timer, or a platform must be responsible for it and must keep running. An automation that was set up once and stopped is worse than none, because nobody is watching.
Something must be able to satisfy the challenge unattended
Writing a file into the web root for HTTP-01, or updating a DNS record for DNS-01, has to happen without a person. For DNS validation this means credentials that can change your zone, which is a permission worth scoping deliberately.
Something must deploy the result
Obtaining a certificate is not serving it. The software must place the files and reload the server, or the new certificate sits unused while the old one runs out. ACME delivers PEM by default [1]; a server that imports a single bundle, such as a PKCS#12 file, needs the files in that certificate format first.
When a setup breaks, check those three before suspecting the protocol.
What it changes operationally
Three things, and the third is the easiest to overlook.
Certificates stop being events
No purchase, no ticket, no calendar entry. This is the visible benefit.
Keys can be replaced at every renewal
Each order is finalized with its own signing request, so a client can put a fresh key into every new certificate [1]. A key then need not outlive the certificate it was made for.
A new dependency appears
Your site's continued function now depends on software that talks to an external service on a schedule. That is a good trade against manual renewal, and it is a dependency, so it deserves the same monitoring as anything else you depend on.
That dependency is the reason to watch expiry independently of whatever renews. Automation that fails silently produces the same outage as no automation at all. With many certificates, knowing each one you run, who answers for it and how it gets replaced is the job of SSL certificate lifecycle management.
What it does not do
ACME challenges do not verify your organisation
They prove control of names, which is what a domain-validated certificate attests [1]. Organisation and extended validation also check the real-world identity of the requester [1]. For issuance that cannot yet be fully automated, such as extended validation, RFC 8555 describes external account binding, which can allow an ACME account to use authorizations granted to an account outside ACME [1]. The difference is covered on certificate types.
It does not manage your server
Deployment is the client's job or yours, not the protocol's. When it is yours, it is the same five steps as installing a certificate by hand.
It does not tie you to one authority
A client starts from the directory URL of an ACME server, and the directory lists the address of every operation [1]. Pointing the same client at another authority means changing that URL and creating an account there.
What ACME replaced
Before ACME, obtaining a domain-validated SSL certificate was a set of manual steps. RFC 8555 lists them: generate a signing request, paste it into the authority's web page, place a challenge on the web server or in DNS, or answer an email, then download the certificate and install it [1]. The authors report that in informal usability tests, webmasters often needed 1 to 3 hours to obtain and install a certificate [1].
Automation removed the person from each of those steps, and with them the hours the procedure took. When software can obtain a certificate unattended, encrypting a site stops being a project and becomes a configuration.
Shorter lifetimes make that harder to do without. Under the CA/Browser Forum Baseline Requirements, the maximum validity of a publicly trusted server certificate falls to 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029 [4]. Until a certificate expires, revoking certificates is the only way to withdraw one early, so a shorter lifetime caps how long a compromised key stays usable.
Where to go next
The ACME clients page covers what runs the protocol and how clients differ; Certbot, for example, describes itself as a client that fetches a certificate and deploys it to a web server [5]. Automating certificate renewal covers making it reliable rather than merely working. For one authority in practice, see how Let's Encrypt checks each challenge and which ports it needs open. Getting a wildcard SSL certificate from Let's Encrypt through DNS-01 has a page of its own.
Automate certificates with Bridge SSL
Bridge SSL is the certificate layer of Bridge CDN: the platform issues a certificate through ACME when a hostname needs one, serves it and renews it, so none of the three requirements above becomes something you operate. The new dependency still exists; it sits with the platform rather than with a process on your server, and checking expiry from outside applies here as well.
FAQ
The protocol
What is ACME?
A protocol that lets software obtain and renew certificates without a person in the loop, by proving control of the names being certified. The proof is the whole mechanism: the certificate authority sets a task only the name's operator can complete, checks the result, and signs on that basis.
Do I need to understand it to use it?
Not in detail, because a client implements the protocol on your behalf. What you do decide is which validation method fits your environment and where the client runs, and those two choices shape what can go wrong later.
Does ACME issue organisation-validated certificates?
Not through its challenges. They prove control of names, and control is exactly what domain validation certifies. For issuance that cannot yet be fully automated, such as extended validation, RFC 8555 describes external account binding, which can allow an ACME account to use authorizations granted to an account outside ACME. [1]
The certificate you receive
What is an ACME certificate, and what does the authority hand over?
An ACME certificate is an ordinary certificate that was ordered through the ACME protocol; the protocol changes how the authority checks the request and delivers the result, not what the certificate is. The download is a PEM file, the default format, and a file of that type can hold more than one certificate. The first certificate in it is the end-entity certificate, the one issued for your names, and each following certificate should directly certify the one before it. A certificate that represents a trust anchor can be left out of the file, provided that the supported peers are known to have the omitted certificates. The authority can also advertise alternative chains that start with the same end-entity certificate, and the client decides which one suits it. Converting the file for a server that expects another container is covered under certificate formats.
Names an ACME certificate covers
Does an ACME certificate cover one hostname or several?
The order decides: it can list several names. An order carries an array of identifiers, and the certificate is requested for that set. The signing request has to indicate exactly the same set of identifiers as the order, so finalizing returns an error when the two differ. The authority must also refuse a request it cannot fulfil as specified, and it must not issue a certificate with contents other than those requested. Control of each name in the order is still proved one name at a time, through the challenges described above.
Running it
Which validation method should I use?
Whichever your environment permits; its constraints decide. Of the three standard ACME challenges, wildcards allow only DNS-01. A host with port 80 closed can use TLS-ALPN-01 on port 443, or DNS-01. Everywhere else the file-based method asks for the least access and has the fewest moving parts.
What breaks in ACME automation?
The failures sit around the protocol rather than in it: the schedule stopped running and nobody noticed, the challenge cannot be completed without a person present, or the certificate was obtained successfully and never reached the service that needed it.
Is automated renewal safe to rely on?
Yes, on one condition: expiry has to be monitored by something that does not depend on the automation performing it. A check that shares the same machinery reports success right up until the moment both stop, which is the failure that turns into an outage.
Sources
RFC 8555, Automatic Certificate Management Environment (ACME) — sections 1, 4, 7.1.1, 7.1.3, 7.3, 7.3.4, 7.4, 7.4.2, 7.6, 8.3, 8.4, 11.1.
RFC 8737, ACME TLS-ALPN-01 challenge — port 443,
acme-tls/1.RFC 9773, ACME Renewal Information (ARI) Extension — a renewal window suggested by the authority.
CA/Browser Forum, Baseline Requirements for publicly trusted TLS server certificates — section 3.2.2.4 (wildcard names: allowed for DNS Change, a value in a TXT record; not allowed for the ACME HTTP and TLS-ALPN methods), section 6.3.2 (maximum validity).
Certbot documentation, Introduction.
RFC 8555, section 9.1 — media type application/pem-certificate-chain: the order of certificates in the downloaded file.