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.