Let's Encrypt is 10 years old now

Original Article ↗ Hacker News Discussion ↗

Overall sentiment about Let’s Encrypt

  • Widely praised as ending the “certificate racket” and making HTTPS the default, especially for small sites and side projects that previously ran without TLS.
  • ACME and automation viewed as the true breakthrough: certs become routine ops instead of manual deployments with CSRs, emails, and resellers.
  • Seen as essential infrastructure and one of the most impactful web security changes of the last decade.
  • Multiple comments note Mozilla/Chrome/Firefox’s role in pushing HTTPS and creating space for LE.

Debate: “Encrypt everything” vs. plain HTTP

  • Many argue all sites, even “kebab shop menus” and static info pages, should use TLS for integrity, privacy, and to prevent ISP ad injection, malware, and BGP/DNS MITM.
  • Others consider universal TLS “cargo cult”:
    • Static info sites may not justify the complexity and breakage risk.
    • TLS deprecations and HSTS can lock users out of otherwise-safe, unmaintained archives.
    • Some nostalgic or archival sites intentionally keep HTTP for “historical integrity.”
  • Counterpoint: without TLS, site owners lose control over what users actually see (ads, modified donation links, etc.), and mass MITM attacks scale far better than tampering with physical mail.

Usability, complexity, and breakage

  • For many, modern servers (Caddy, integrated ACME, certbot) make TLS nearly zero-cost.
  • Others report real pain: fragile tooling (e.g., certbot dependencies), protocol/cipher deprecations breaking previously A+ setups, and extra “knobs” compared to plain HTTP.
  • Short lifetimes and HSTS increase operational risk: expired or misconfigured certs can block users entirely.
  • Some PaaS/cloud and enterprise appliances still make automation awkward, pushing people to paid long-lived or wildcard certs.

PKI trust model, centralization, and policy

  • Several criticize the WebPKI model: any trusted CA can issue for any domain; hostile or incompetent actors and state influence are concerns.
  • Suggested alternatives: DNSSEC+DANE, registrar-issued certs, web-of-trust, decentralized/crypto-based systems; commenters note scalability and UX issues.
  • EV/OV certs generally viewed as overpriced and ineffective for phishing; browsers have largely removed special UI, and misissuance rates are claimed higher than DV.
  • Some institutions (banks, governments, large enterprises) still ban LE or require long-lived or specific paid CAs, often due to regulation, checklists, or legal concerns.

Other points

  • DNS-level attacks (e.g., DNS hijack) can still yield valid certs; mitigations like DNSSEC, CAA, certificate transparency, and multi-perspective validation are discussed.
  • S/MIME is mentioned as an area where a LE-like free, automated CA would be valuable but currently missing.
  • Reminder that Let’s Encrypt is donation-funded and non-profit; some caution against introducing paid tiers that could misalign incentives.