Why I no longer have an old-school cert on my HTTPS site

Original Article ↗ Hacker News Discussion ↗

A blog post about replacing a traditional paid TLS certificate with a Let’s Encrypt one using ACME sparks wider criticism of the protocol’s complexity and the trustworthiness of popular clients like Certbot. Commenters debate whether ACME, JOSE/JWK, and JSON-based signatures are over‑engineered or a reasonable response to the messy legacy of X.509 and ASN.1, and whether it’s safer to write minimal custom clients, use lightweight alternatives, or rely on built‑in automation in web servers. The thread also touches on why HTTPS is increasingly mandatory even for simple blogs, the decline of older certificate models (including EV certs), and frustration with registrars such as Gandi.

Access to the blog

  • Several commenters note intermittent reachability and apparent IP or ISP blocking; some report being unable to read the site from parts of Europe.
  • This leads a few to question the author’s operational choices or competence, though others say the site works fine from their regions.

ACME, Let’s Encrypt, and client complexity

  • Many sympathize with distrust of large, opaque ACME clients (especially ones that run as root, edit webserver configs, or have large, hard‑to‑audit codebases).
  • Others argue the protocol is reasonably designed for a genuinely hard problem and that existing clients have seen wide real‑world use without major disasters.
  • A recurring theme: ACME itself is fine, but typical tooling is overcomplicated, poorly documented, or intrusive.

Tooling: certbot, acme.sh, and alternatives

  • Certbot is criticized for:
    • Mutating webserver configs by default.
    • Being “complexity creep” and hard to reason about or hook correctly.
  • Defenses of certbot note:
    • Webroot and DNS plugins avoid config munging and can run unprivileged, with simple post‑hooks to reload servers.
  • acme.sh receives both praise (simple dependencies, good DNS‑01 support) and criticism (8000 lines of shell, lots of open issues, controversial ZeroSSL default).
  • Other small clients (dehydrated, acme_tiny, uacme, OpenBSD’s acme-client, Apache mod_md, Caddy’s built‑in ACME) are suggested for people who want minimal or integrated solutions.
  • Several stress that the ACME client need not run on the webserver; a separate machine or jail can handle issuance and distribute certs.

JOSE, JWK, JSON, and cryptographic overengineering

  • Some agree with the post that JOSE/JWK/JWS and ACME’s use of JSON, base64url, and nested structures are “galactically overengineered”.
  • Others counter that:
    • They’re still simpler than legacy ASN.1/X.509/PKCS stacks or XMLDSig.
    • Complexity largely reflects real interoperability and algorithm‑support needs; most users rely on libraries rather than hand‑rolling.
  • Long subthreads debate JSON’s numeric semantics, lack of strong typing, and alternatives (S‑expressions, protobuf, Dhall).

X.509, SANs, and protocol history

  • Several comments explain why SANs are mandatory, how CN‑only certs broke, and how browser behavior evolved to enforce SAN usage.
  • ASN.1/X.509 internals and certificate fields (issuer, validity, serials, key usage, CT SCTs) are discussed as inherently complex but mostly hidden by tooling.

Security model, HTTPS everywhere, and wildcards

  • Strong consensus that plain HTTP is now effectively unsafe:
    • MITM injection, tracking, and “watering hole” attacks are cited.
    • Browsers mark HTTP as “not secure”, restrict APIs to HTTPS, and auto‑upgrade in many cases.
  • Some still claim “no reason” for TLS on a blog; replies emphasize reader privacy, integrity, and defense‑in‑depth even for “static” content.
  • DNS‑01 and wildcards:
    • DNS‑01 is praised for decoupling ACME from webserver configs and enabling wildcards or internal domains.
    • Critics note operational pain: fast TXT updates, propagation delays, anycast issues.
    • Wildcards are seen by some as helpful for obscuring internal hostnames; others consider them a dangerous single point of compromise.
    • Techniques like acme-dns or delegating _acme-challenge via NS/CNAME are suggested to isolate DNS updates.

Manual vs automated cert management; “perfect vs good”

  • Some commenters echo the author’s desire to fully understand and tightly control every component touching keys, even if that means writing a bespoke client.
  • Others argue this is overkill for a personal blog, and that widely used, reasonably secure automation (possibly behind a load balancer or in containers) is a better use of time.
  • There’s debate over whether rolling a custom C++ ACME client is actually safer than using a well‑reviewed existing one.

PKI evolution, EV, and ACME’s inevitability

  • Several note that non‑ACME cert workflows are effectively dead as certificate lifetimes shrink and automation becomes mandatory.
  • Long, detailed subthreads explain why EV certificates failed in practice (UI confusion, phishers obtaining similar EV names, human‑driven verification not scaling) and how CA/Browser Forum baseline requirements and Certificate Transparency reshaped the ecosystem.

Registrars and Gandi

  • The post’s aside about leaving Gandi prompts discussion of registrar choices.
  • Multiple people report large Gandi price hikes and new fees since an acquisition, and describe migrating to alternatives (Porkbun, Cloudflare, Route53, small regional registrars).