April 10, 2026
When “broken” is the feature
The difficulty of making sure your website is broken
Let’s Encrypt is making “broken” sites on purpose—and commenters are losing it
TLDR: Let’s Encrypt built a tool to host good, expired, and revoked test sites so developers can see how browsers react. Commenters say Chrome often shrugs while Firefox complains, igniting a fight over whether revocation checks even work—plus one “ditch HTTPS” hot take that everyone dogpiled.
Let’s Encrypt just did the most chaotic thing: it’s building websites with bad locks on purpose so developers can test how apps react when a site’s ID badge (a certificate) is expired or revoked—aka canceled before it’s due. The wild part? It’s way harder to keep a site “broken” in the right way than to keep it secure. So the team wrote a custom Go app to mint, cancel, and carefully time these test certificates while they wait for revocation lists to update.
But the real fireworks are in the comments. Web veteran paulirish drops a friendly reminder that badssl.com already has a zoo of “intentionally broken” test sites, and the crowd nods. Then things split: multiple users swear that Chrome shrugs at the revoked pages while Firefox throws warnings, and Android users pile on with similar “Chrome accepts, Firefox rejects” tales. Cue the chorus: “Do browsers even check this stuff?” The vibe is equal parts baffled and exasperated.
Enter the spice: one commenter declares “HTTP works fine, just add your own crypto,” igniting the classic meme: never roll your own crypto. Another shares a comedy-of-errors about trying to simulate a bad network… but the Wi‑Fi was too good. In short, Let’s Encrypt built a lab for breaking things the right way—only to expose that browsers don’t even agree on what “broken” looks like. Drama secured.
Key Points
- •Let’s Encrypt built a Go program to reliably host test sites with valid, expired, and non-expired revoked certificates.
- •The prior approach using certbot, nginx, and shell scripts became too complex for consistent management.
- •Certificates are requested via ACME using the lego library and validated with TLS-ALPN-01.
- •Revocation is requested through ACME and confirmed by polling the certificate’s CRL URL until the serial number appears.
- •The system delays deployment: at least 24 hours for revocations to propagate and until past expiry for expired certificates (minimum six days).