The Clause That Showed Up Without Warning
You did not get an email. Nobody does. On June 4, 2026, Let's Encrypt shipped version 1.7 of its Subscriber Agreement, and Section 3.1 grew a new warranty. Request a certificate now and you attest that you are not "located in, organized under the laws of, or ordinarily resident in any country or territory that is the target of comprehensive U.S. sanctions." Certbot renewed your cert that night like it always does. The ACME account never blinked. Your legal exposure changed anyway.
Five weeks later, on July 6, 2026, version 1.8 replaced 1.7 and rewrote that same clause into softer, broader "comply with applicable laws" language. Two rewrites of one paragraph inside a month. On a document your automation signs on your behalf every sixty days. On a document almost nobody on your team has ever opened.
That is the actual story. Not the geopolitics. The fact that a legal agreement you accept programmatically changed under you, and the only reason you heard about it was a Hacker News thread with 454 points.
What Version 1.7 Actually Said
The wording in 1.7 was specific. Two attestations landed in the agreement. You are not located in, organized under, or ordinarily resident in a comprehensively sanctioned territory. And you are not "a prohibited or restricted party under U.S. or other applicable sanctions and export control laws."
Read the first line literally and it is enormous. It does not say "government of." It says persons. Anyone ordinarily resident in one of those places is, by plain reading, a person located in a country targeted by comprehensive sanctions. The person running a small mail server in Tehran. The volunteer keeping a community forum online in Havana. Let's Encrypt spent a decade telling the world that HTTPS should be free and universal, and here was a paragraph that appeared to fence part of that world back out.
The comments caught it within hours. A Let's Encrypt representative stepped in to say exemptions exist for personal communications and for OFAC authorizations that promote internet freedom. True. Also not what the agreement text said. And an agreement is enforced on its text, not on a forum reply.
Then 1.8 Walked It Back, Sort Of
Version 1.8 is the interesting move. Let's Encrypt pulled the explicit "located in a sanctioned territory" attestation and swapped in a wider section about complying with applicable law, including U.S. export control and sanctions rules. Their published line: this "clarifies its existing policy and does not affect where or to whom it issues certificates," and they "continue to serve permitted non-governmental users in sanctioned countries and territories where exemptions and authorizations apply."
So the sharp edge got sanded down. Good. But look at what did not change. The direction. A U.S.-based nonprofit CA answers to OFAC, and now the subscriber agreement says so out loud instead of leaving it implied. The clarification is real and the reassurance is probably sincere. It is still a legal warranty you make, not a technical guarantee they give you.
Who Is Actually On The List
Want to reason about this instead of panic? Know the list. OFAC's comprehensively sanctioned jurisdictions right now are Cuba, Iran, North Korea, and the occupied Ukrainian regions of Crimea, Donetsk, and Luhansk. Syria was on it and came off at the end of 2025. The list is not fixed, which is the whole point. It moves with foreign policy, and your subscriber agreement now moves with it.
Most people reading this do not host inside those borders. But "I serve users there" is a different question from "I am resident there." Run a CDN edge, a mail relay, or a global community platform and you sit closer to the blast radius than you'd guess.
The Real Problem Is Single-CA Risk
Here is the part that matters wherever your servers live. Nothing about your certificates stopped working. This was a warranty change, not a technical block. No geolocation check on the ACME endpoint. No new challenge failure. No revocation wave. Your renewals kept renewing.
That is exactly why it is easy to ignore, and dangerous to. Everyone designs for the technical failure of a CA. Rate limits. An outage. A validation that botched itself at 3 a.m. Hardly anyone designs for the policy failure of a CA, where the issuer is up, healthy, fast, and simply decides, or is compelled to decide, that it will no longer serve some class of subscriber. You cannot retry your way out of that one. Let's Encrypt has had genuine outages this year too. A 90-minute elevated error window in June. A paused-issuance incident back in May. Those you wait out. A policy that excludes you, you do not.
If your entire certificate strategy is one ACME account against one CA, you do not have a strategy. You have a dependency you have never tested failing over. It's the same lesson as the Let's Encrypt rate limit story in a different coat, and it lines up with what the warranty reality check post argued. The value a CA hands you is a working cert. The risk it carries is everything else printed in the agreement.
Build A Second Issuer Before You Need One
The fix is not to abandon Let's Encrypt. It is to make your automation CA-agnostic so swapping issuers is a config change and not a weekend. ACME is a standard. ZeroSSL, Google Trust Services, Buypass, and others all speak it. Wire up a backup now, while everything works, so the muscle exists when it doesn't.
With cert-manager that means a second ClusterIssuer pointed at a different ACME directory:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: zerossl-backup
spec:
acme:
server: https://acme.zerossl.com/v2/DV90
email: ops@example.com
externalAccountBinding:
keyID: <your-eab-kid>
keySecretRef:
name: zerossl-eab
key: hmacKey
privateKeySecretRef:
name: zerossl-backup-account-key
solvers:
- dns01:
cloudflare:
apiTokenSecretRef:
name: cloudflare-token
key: api-token
Switching a certificate over is then a one-line issuerRef change on the Certificate object. Test it in staging today rather than meeting the external-account-binding flow for the first time during an incident.
Running acme.sh instead? Same idea, different shape. Register both and keep the switch documented:
# Primary
acme.sh --issue -d example.com --server letsencrypt --dns dns_cf
# Backup, already registered and ready
acme.sh --register-account -m ops@example.com --server zerossl
acme.sh --issue -d example.com --server zerossl --dns dns_cf
Why do this before you need it? Because the failover path has its own bugs. A different account key. An external account binding. A separate rate limit. A challenge quirk that behaves just differently enough to ruin your evening. You want to hit those on a Tuesday, not during the outage that forced the switch. The ACME client traps post covers how these clients bite. Assume the backup path has a few teeth of its own.
Read The Agreement You Sign 4,000 Times A Year
A cert on a 60-day cycle means your automation accepts the current Subscriber Agreement roughly every two months, forever, no human in the loop. That is the deal you made when you automated, and it was the right deal. It also means "we agreed to this once in 2019" is fiction. You agreed to v1.8 the last time you renewed. You will agree to v1.9 whenever it lands.
So hand the boring job to someone. Let's Encrypt keeps every version and a diff of every change in its public repository. When a new version drops, skim the diff. It is usually two paragraphs. Know your CA's comprehensive-sanctions posture if any slice of your audience sits near that line. And treat "the agreement changed and nobody noticed" as the monitoring gap it plainly is.
What To Monitor So You Find Out First
You watch expiry dates. Watch the earlier signals too. A CA relationship going sideways shows up before a renewal fails outright. Alert on renewal attempts that error rather than succeed, not only on certs about to lapse, because a policy-driven refusal surfaces as a failing renewal weeks ahead of the old cert's expiry. Track which CA issued each live certificate, pulled from Certificate Transparency logs, so you know your real exposure per issuer instead of assuming it is all Let's Encrypt. Watch the issuer field for drift, because a cert that quietly came from your backup CA is telling you the primary path already broke. External monitoring is what catches the renewal that failed silently, which is the whole case for automating SSL monitoring to begin with.
None of this means Let's Encrypt is untrustworthy. It is still the best thing to happen to the open web in a decade. It means you handed a legal and operational dependency to one organization, wired it into automation, and then stopped looking. The sanctions clause broke nothing. It flipped the lights on for a second, and what it lit up was how little most teams know about the paper their robots keep signing.
Frequently asked questions
Did the sanctions clause stop my certificates from renewing? No. Both version 1.7 and version 1.8 changed the legal warranties in the Subscriber Agreement, not the technical issuance path. There is no geolocation check on Let's Encrypt's ACME endpoint, so renewals continued as normal and nothing was revoked because of the change.
What is the difference between version 1.7 and version 1.8? Version 1.7, dated June 4, 2026, added an explicit attestation that you are not located in or resident in a comprehensively sanctioned territory. Version 1.8, dated July 6, 2026, removed that specific wording and replaced it with a broader clause about complying with applicable law, including U.S. sanctions and export controls, which Let's Encrypt says clarifies rather than changes its policy.
Which countries and territories are affected? The U.S. OFAC comprehensively sanctioned jurisdictions are currently Cuba, Iran, North Korea, and the occupied Ukrainian regions of Crimea, Donetsk, and Luhansk. Syria was on the list until it was removed at the end of 2025. The list changes with U.S. foreign policy, so recheck it rather than memorizing it.
Should I stop using Let's Encrypt because of this? No, but stop depending on it as your only issuer. Configure a second ACME-compatible CA such as ZeroSSL, Google Trust Services, or Buypass now, test the failover in staging, and make switching a config change rather than an emergency. The risk here is single-CA dependency, not Let's Encrypt specifically.
How would I even know if my CA changed its agreement? Let's Encrypt publishes every Subscriber Agreement version and a diff of the changes in its public document repository. Put a periodic check of that page on whoever owns your certificate tooling, and alert on renewal attempts that error out, since a policy-driven refusal shows up as a failing renewal well before the current certificate expires.
