Let's Encrypt bans certificate usage in any US sanctioned territory [pdf]

Legal context & what changed

  • The new Subscriber Agreement says users must not be located in, organized under, or “ordinarily resident” in comprehensively US‑sanctioned countries, nor be sanctioned parties or controlled by them.
  • Many see this as standard US sanctions/export-control compliance for a US entity; some are surprised it took this long.
  • Others argue US sanctions law is unusually extraterritorial and that this shows how much global infrastructure is effectively under US policy control.

Jurisdiction, extraterritoriality & politics

  • Multiple comments stress that any US‑linked CA (including those owned by US firms or cross-signing with them) will face similar constraints.
  • There is debate over whether setting up an EU or “neutral” branch meaningfully avoids US reach; some say the US would still target the parent, others note this clashes with other countries’ sovereignty.
  • Broader concern: sanctions now frequently target individuals (including international court officials), making them feel arbitrary and political.

Impact on users in sanctioned regions

  • Fears that ordinary users and small sites in Russia, Iran, etc. will lose LE, pushing them to local/state CAs and facilitating government MITM.
  • An Iranian commenter notes similar dynamics when US cloud providers blocked Iranian users, driving them to state‑aligned infrastructure.
  • LE representatives say certificates remain available to most users in Iran/Russia and that blocks are focused on government entities, but the contract text appears broader, creating confusion.

Alternatives to Let’s Encrypt

  • Mentioned options: ZeroSSL (Austrian, now owned by HID/Assa Abloy, Sectigo under the hood), Actalis (Italy, has a free ACME tier), and historically Buypass.
  • Several point out these are also tied into US/EU jurisdictions and have their own sanctions clauses, sometimes stricter than LE’s.
  • Some note practical issues: obscure free tiers, mobile sites hiding legal info, ACME quirks, rate limits, lack of wildcards/SAN, or required accounts.

Trust, centralization & governance of Web PKI

  • Many argue the real problem is centralization: ~60% of the web depends on one US‑based CA, and browsers/OS vendors (mostly US) control trust stores.
  • Others counter that ACME makes switching CAs relatively easy and operators should already have multi‑CA fallbacks.
  • A recurring theme: Web PKI is not purely technical; it’s a policy and sanctions distribution system that now sits in the critical path of “can this site use HTTPS?”

Technical & architectural debates

  • Alternatives discussed:
    • DANE/DNSSEC (shift power to DNS registries/governments; DNSSEC seen as messy and politically controlled).
    • Country CAs or government-issued certs (critics fear pervasive state MITM).
    • Self-signed/TOFU/pinning (better autonomy, worse UX and deployability).
  • Certificate Transparency is cited as a partial check on CA abuse, but targeted attacks might still evade detection if site owners don’t monitor logs.

Ambiguities and open questions

  • How strictly LE will interpret “ordinarily resident” and “use … in compliance with US sanctions” is unclear.
  • Some wonder how enforcement will actually work (TLD blocks, IP geo, account screening) and whether existing certs could be broadly revoked.
  • Several call on LE to align the subscriber text with their stated practice and explain more concretely what is and isn’t allowed.