Let's Encrypt had a higher error rate for 90 minutes today
A brief spike in errors at Let’s Encrypt, the free certificate authority used by much of the web, raised concerns about its reliability and the risks of concentrating so much TLS infrastructure in a single provider. Commenters debate whether shorter certificate lifetimes and strict browser handling of expirations improve security or just create more fragility, especially when outages or poor automation lead to renewal failures. Alternatives like ZeroSSL and Google Trust Services are mentioned, alongside broader critiques of certificate revocation, status-page transparency, and the usability of browser security warnings.
Outage impact and status-page semantics
- Incident was a ~90-minute period of elevated issuance errors due to upstream networking, not a full-day outage.
- Let’s Encrypt staff (posting personally) say most requests still succeeded; some users report repeated 400/500s and zero successful renewals during that window.
- Confusion over “Degraded Performance”: some read it as near-total failure; others note status-page language often downplays serious problems.
- The status banner being green during an “Active Incident” is criticized as misleading, especially on mobile where detailed status text is off-screen.
Short certificate lifetimes vs. revocation
- Debate over push for ever-shorter lifetimes (90 days → 45 days → even days).
- One side: shorter lifetimes limit damage from stolen keys and shrink CRLs; expiry is core to the model.
- Other side: more frequent renewals increase dependence on CA uptime and infrastructure fragility; revocation should be fixed instead.
- Revocation today is widely viewed as broken, though some argue newer mechanisms (e.g., CRLite in Firefox) largely solve this, pending broader vendor adoption.
Operational hygiene and automation
- Many emphasize clients should renew well before expiry (e.g., at 60 of 90 days) and with retries/backoff, making short outages a non-event.
- Criticism of setups that attempt renewal only shortly before expiry; compared to using a passport that is technically valid but effectively unusable near expiration.
Alternatives and centralization risk
- Some see Let’s Encrypt as a de facto single point of failure for much of the web; others counter that alternative CAs (ZeroSSL, Google Trust Services, etc.) exist.
- Practical switchover in a crisis is questioned: lack of built-in failover, potential load spikes on other CAs, and complexity of serving multiple certs per key.
- Broader critiques target the web PKI model and reliance on US-based CAs; proposals include DNS-published self-signed keys or stronger regulation of network intermediaries.
Browser handling of expired certificates
- Disagreement over whether browsers should soften errors for just-expired certs.
- Some argue harsh failures are necessary to force proper automation and avoid security complacency; others think nuanced, time-based warnings could improve usability without major risk.