Bridge SSL
- Bridge SSL
- ACME
ACME explained: how automated certificate issuance works
The name stands for automatic certificate management environment, and knowing that helps nobody. What matters is the exchange it defines.
What the protocol does
Four steps, performed by software on your side against a service run by the authority.
Create an account
A key pair identifies you to the authority. This is separate from the key that will be in your certificate, and it persists across issuances.
Request a certificate for some names
The software says which hostnames it wants covered.
Prove control of each name
The authority issues a challenge for every name, and the software satisfies it. This is the step everything else depends on, and the different ways of doing it are the main thing to understand.
Receive the certificate
Once the challenges are validated, the authority signs and returns the certificate along with its chain.
Renewal repeats the whole exchange. There is no separate renewal operation, which is consistent with what renewal always was, as described on certificate renewal.
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.
HTTP validation
asks you to serve a specific file at a specific path over the unencrypted port. Simple, requires no DNS access, and works only for names that already resolve to a server you control. See HTTP-01.
DNS validation
asks you to publish a specific text record for the name. Slower, requires the ability to change DNS automatically, and is the only option for wildcard certificates. See DNS-01.
TLS validation
proves control through the encrypted connection itself, on the encrypted port, without needing the unencrypted one. Useful where the unencrypted port is closed. See TLS-ALPN-01.
The choice is usually made for you by circumstance rather than preference: wildcards force DNS validation, a closed unencrypted port forces TLS validation, and everything else defaults 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, or updating a DNS record, 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, which is the failure described on expired certificates.
Those three are the whole of it, and most broken automation is one of them missing rather than a protocol problem.
What it changes operationally
Three things, and the third is the one people underestimate.
Certificates stop being events
No purchase, no ticket, no calendar entry. This is the visible benefit.
Keys get replaced regularly
Most clients generate a new key at each renewal, so no key stays in service for years, which is a security improvement nobody has to remember to make.
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.
The last point is why the monitoring advice throughout this material is to watch expiry independently of whatever renews. Automation that fails silently produces exactly the same outage as no automation at all.
What it does not do
It does not verify your organisation
ACME proves control of names, so it issues domain-validated certificates. Organisation-validated certificates involve human checks and are not obtained this way, as covered on certificate types.
It does not manage your server
Deployment is the client's job or yours, not the protocol's.
It does not remove limits
Authorities apply rate limits, and hitting them during a misconfigured loop is a real way to lock yourself out temporarily. See rate limits.
Why this replaced buying certificates
The shift happened quickly once the protocol existed, and the reason explains the shape of everything current.
Before automation, obtaining a certificate involved a purchase, a verification process with human steps, and a manual installation. That cost made encryption a decision rather than a default: sites weighed whether a given page was worth a certificate, and most concluded it was not.
Automation removed the cost and the delay together. When a certificate can be obtained in seconds by software, encrypting everything stops being a project and becomes a configuration, and the argument against encrypting a site collapses to nothing.
The second-order effect matters more than the first. Because issuance is automatic, lifetimes could be shortened without making anyone's life harder, and shorter lifetimes limit the damage from a compromised key better than revocation ever managed. The whole current arrangement of the public certificate system rests on this protocol existing.
That is also why manual issuance now feels awkward: the surrounding practices, including short lifetimes, assume automation is present.
Where to go next
The clients page covers what actually runs the protocol and how they differ. Renewal automation covers making it reliable rather than merely working.
If you are choosing a challenge, start with the constraint: wildcard certificates require DNS validation, and everything else follows from what your environment permits.
Automate certificates with Bridge SSL
Bridge SSL performs issuance, validation, renewal, and deployment as part of serving your site, so none of the three requirements above becomes something you operate. The dependency described above still exists, and it sits with the platform rather than with a process on your server that nobody is watching. See what the platform offers at Bridge CDN.
FAQ
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 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 determine almost everything that can go wrong later.
Which validation method should I use?
Whichever your environment permits, and the choice is usually made for you. Wildcards require DNS validation. A host that refuses unencrypted connections needs the handshake-based method. Everywhere else the file-based method asks for the least access and has the fewest moving parts.
Does ACME issue organisation-validated certificates?
No. The protocol proves control of names, and control is exactly what domain validation certifies. Organisation and extended validation involve checks on a company that cannot be automated this way, which is why they stay outside the protocol and outside the automation built on it.
What breaks most often?
Not the protocol itself, which rarely surprises anyone. Three failures dominate instead: 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.
Certificates that renew themselves
Bridge SSL is the TLS layer of Bridge CDN: issuance and renewal happen as part of serving your site, wildcards included. Nothing to install, nothing to schedule.