Upcoming changes to Let's Encrypt and how they affect XMPP server operators

Original Article ↗ Hacker News Discussion ↗

Background and XMPP Impact

  • Let’s Encrypt will stop issuing certificates with the clientAuth EKU because of new Chrome root program rules; XMPP s2s commonly reuses those certs for “client” side in TLS handshakes.
  • Prosody and some other XMPP servers already accept server-only (serverAuth) certs for both ends of s2s connections, knowingly violating TLS/XMPP RFCs and default TLS library behavior.
  • The blog post’s goal (per discussion) is to alert XMPP operators so they upgrade/adjust configs to avoid federation breakage; at least one non‑conformant implementation was already fixed months ago.
  • Debian/ejabberd users may be affected until their stack is updated; some suggest simply ignoring EKU checks in XMPP contexts.

Why Let’s Encrypt Changed & Role of Google/WebPKI

  • Chrome now demands “single‑purpose” WebPKI roots: if a root is in the browser store, its sub‑CAs must essentially only issue serverAuth TLS certificates.
  • This is motivated by past friction: non‑web uses of WebPKI (e.g., legacy payment terminals, SHA‑1 certs) were used to resist stricter security changes; browsers want to decouple web security decisions from other ecosystems.
  • Let’s Encrypt could run a separate non‑WebPKI root for client auth, but claims there isn’t enough demand to justify the cost and complexity.

Debate: Security Improvement vs Centralization/Hostility

  • Supporters argue:
    • Mixed‑use hierarchies complicate policy, revocation, and risk analysis.
    • Separating purposes is good cryptographic hygiene and reduces “wrong context” vulnerabilities.
  • Critics argue:
    • This primarily serves browser vendors’ control, not actual risk reduction; XMPP and similar protocols become collateral damage.
    • The practical effect is that non‑web software will just ignore EKU, turning all server certs into de‑facto client certs, so security is not meaningfully improved.
    • Google’s dominance (via Chrome and CA/B Forum) effectively lets it dictate PKI for everyone, not just the web.

Are Public Client Certs Useful or Broken?

  • Several commenters say using publicly‑trusted certs for client auth is fundamentally unsound: many systems never validate SAN/Subject properly (citing SAML/xmlsec incidents), so “any valid cert” can bypass auth.
  • Others counter that for federated server‑to‑server use (XMPP, SMTP, etc.), domain‑validated client/server certs from a public CA are a pragmatic way to authenticate peers without bilateral setup.

Alternatives and XMPP‑Specific Options

  • Dialback over TLS and DNSSEC/DANE are discussed:
    • Dialback is simpler but can be more MITM‑prone unless combined with TLS cert checks; it also predates modern tooling.
    • DANE is supported by Prosody and others but hampered by low DNSSEC deployment and operational complexity.
  • Private PKI or protocol‑specific roots are viewed as technically cleaner but likely infeasible at Internet scale without LE‑like funding and automation.
  • Some conclude the pragmatic near‑term path for XMPP is to keep using WebPKI certs but standardize ignoring the client/server EKU distinction for s2s.