RFC 8555 automated the TLS renewal task founders used to miss

The workload

Before automation, keeping a website's TLS certificate valid was a recurring manual task: request a certificate, prove control of the domain, install the new one before the old expired, and repeat every year or two — a task any solo operator could forget, and outages from expired certificates were a recognized failure pattern. The Automatic Certificate Management Environment (ACME) protocol, published by the IETF as RFC 8555 in March 2019, standardized a way to remove the manual steps. Adopting it today means running an ACME client — Certbot and equivalents built into most hosting platforms — rather than implementing the RFC directly; the workload is confirming a host's automated renewal is actually configured and firing.

What the documents show

RFC 8555's abstract states, verified, that it 'describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance,' covering account registration, domain-control validation, and issuance and revocation as operations a client and a certificate authority's server exchange automatically. Let's Encrypt's own description of how it works, published by the CA that popularized ACME, states, verified, that the goal is to 'set up an HTTPS server and have it automatically obtain browser-trusted certificates without any human intervention,' and separately that renewing a certificate 'means repeating the issuance process over again,' confirming ACME treats renewal as a repeat of the same automated exchange, not a distinct manual procedure.

The operating cost

ACME is a protocol, not a paid service; Let's Encrypt issues certificates under it at no charge, and most hosting platforms fold automated renewal into their existing hosting fee rather than billing separately. The remaining cost is the compute and DNS or HTTP access an ACME client needs for domain validation, negligible on any platform already running the client on the founder's behalf.

The stop condition

Neither document claims automated renewal removes every certificate-related risk; the RFC describes what the protocol automates — issuance and renewal handshakes — not adjacent failures like a misconfigured client, an expired ACME account, or a validation method that silently stops working. This is an editorial stop condition: renewal should be treated as done, not merely configured, only after a founder has observed one full cycle succeed and confirmed the resulting certificate is the one being served, since a silently failing client looks identical to a working one until the old certificate expires anyway.

• Has an actual renewal cycle been observed to succeed, not just assumed from the client being installed?
• What happens, and who is notified, if an automated renewal attempt fails?
• Is the ACME account itself still valid, with no email or ownership change since it was created?

RFC 8555 turned a once-manual, easy-to-forget task into a background protocol exchange between a client and a certificate authority. The standard automates the mechanics of proving control and issuing a certificate; it does not automate noticing when that automation has quietly stopped working.