ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
59% Positive
Analyzed from 5986 words in the discussion.
Trending Topics
#certificates#certificate#let#encrypt#sanctions#trust#https#government#should#control
Discussion (234 Comments)Read Original on HackerNews
That said, pretty sure this is stems from the insane US legal requirement to not export SSL technology to enemy countries. I'm sure some of y'all are old enough to remember when web browsers came in "international friendly" versions that supported 40 bit encryption, or "fancy secure" versions with 128 bit encryption.
Most of our sanctions-related blocks apply only to the governments of certain sanctioned countries, not their general population.
This subscriber agreement update was intended to better reflect our legal requirements. It does not reflect a major change in the service we provide. Our compliance program does evolve over time, and part of that is communicating about it better in our terms of service. It's clear from some of the comments here that we have more work to do to make that text more understandable, we'll work on that.
"That said, pretty sure this is stems from the insane US legal requirement to not export SSL technology to enemy countries. I'm sure some of y'all are old enough to remember when web browsers came in "international friendly" versions that supported 40 bit encryption, or "fancy secure" versions with 128 bit encryption."
It doesn't.
This is most likely OFAC. Lets Encrypt could apply for a license to do business with sanctioned entities, and given their use case it would most likely be approved.
https://ofac.treasury.gov/ofac-license-application-page
[0]: https://en.wikipedia.org/wiki/Wickard_v._Filburn
They might be compelled to issue a certificate to an unauthorized (by browser PKI policies, not local law) entity, but that would be very conspicuous due to Certificate Transparency.
Anonymity and encrypted communication are two very, very different things. Have one but not the other and you're essentially handing off your private data incl. passwords to whoever that has a tap on the communication between you and the server can fetch them, too. Have the other but not the one and everyone will know who you are, but they can't eavesdrop.
Because they're betraying their own goals, as stated in their About page: “It is a service run for the public’s benefit. [...] Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost. [...] Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.” Now they own they are under the control of a political organization.
Here is the paragraph Let's Encrypt added to their Subscription Agreement on 2026-06-04:
> You are not a person or entity that is:
> (a) located in, organized under the laws of, or ordinarily resident in any country or territory that is the target of comprehensive U.S. sanctions;
> (b) a prohibited or restricted party under U.S. or other applicable sanctions and export control laws and regulations;
> or (c) owned or controlled by or acting on behalf of anyone described in (a) or (b).
> You agree to use Let’s Encrypt Certificates and any services provided by or on behalf of ISRG in compliance with applicable U.S. export control and sanctions laws and regulations.
> "Across 2018-2019, the RISC-V community has reflected on the geo-political landscape and we have heard concerns from around the world that investment in RISC-V must come with IP access continuity to ensure a long-term strategic investment. We first mentioned our intentions to move at the December 2018 summit. Incorporation in Switzerland has the effect of calming concerns of political disruption to the open collaboration model. RISC-V International does not maintain any commercial interest in products or services as a non-profit, membership organization. There have not been any export restrictions on RISC-V in the US and we have complied with all US laws. The move does not circumvent any existing restrictions, but rather alleviates uncertainty going forward.
> In March 2020, the RISC-V International Association was incorporated in Switzerland. Along with this, we shifted to a new, more inclusive membership structure. Members of RISC-V International have access to and participate in the development of the RISC-V ISA specification and extensions as well as related hardware and software. RISC-V has a Board of Directors composed of member representatives as well as a Technical Committee of work group leaders."
> RISC-V International has not incorporated in Switzerland based on any one country, company, government, or event. This move is reflective of community concern and managing strategic risk for our community investing in RISC-V for the next 50+ years.
> The IP contributed and produced by RISC-V International is held under industry and global standard licenses that are already open to leverage by any company regardless of jurisdiction. This licensing is a common open source approach to foster collaboration that is not tied to any geographic regulation. IP in the public domain has not been subject to export control.
https://riscv.org/about/
e.g. https://www.consilium.europa.eu/en/policies/sanctions-agains...
Let say someone created an Russian Let's Encrypt. It has all the technical aspects as regular LE in that you can request a certificate and get one through an acme challenge. That is all great and all, but no browser will recognize it as valid. No operative system will recognize it as valid. The Russian state might add the new LE as valid for government computers, but the real work would be to get any other participants in the world to do the same. The issue is not a technical one but rather a social one that is built on trust.
When Russia invaded Ukraine there was a major discussion if IANA/ICANN should have disconnected Russia from domain names and IP addresses. That discussion ended on a decision to not do that because the symbolic benefit was deemed minor compared to the harm to the system in large, especially once the war end. If you got two roots, then a domain name or IP address can now suddenly have two locations, and it would be a massive pain to try fix it even if people wanted to fix it. Certificate Authorities do not share this trait since there can be an almost unlimited number of roots and none of them can conflict with each other (assuming no hash collision). If Russia spins up a new CA then people can use that one today if they want to, and they can continue to do so after the war has ended.
Russian quasi-government structures are spending quadrillion of rubles on a TSPU (censorship system) to spy on Russian residents, US ...helps them by making snooping on what is currently encrypted traffic possible by banning accessible encryption!
The terms of service update to clarify what we have always done, comply with relevant law, has not changed the situation for either country.
According to https://news.ycombinator.com/item?id=48457280 it affects all people ordinarily resident in those territories, not just their governments:
> You are not a person or entity that is:
> (a) located in, organized under the laws of, or ordinarily resident in any country or territory that is the target of comprehensive U.S. sanctions;
> [other 'or' conditions]
Let's Encrypt can issue certificates for non-government entities in Iran and Russia due to statutory exemptions protecting personal communications, alongside specific Office of Foreign Assets Control (OFAC) authorizations designed to promote Internet freedom and human rights.
We will look into whether we can make things more easily understandable in the subscriber agreement.
"You are not a person or entity that is: (a) located in, organized under the laws of, or ordinarily resident in any country or territory that is the target of comprehensive U.S. sanctions; "
this says nothing (edit: specific) about government (edit: only), and is applicable to normal people in those areas.
Still needs updating if it's supposed to only apply to governments, though.
Let's Encrypt becomes subject to US export restrictions on cryptography if they are a US company, or if they post anything to github or post anything to major app stores. Every app I have ever posted to Google Play has had to submit a form to the US government declaring what use they make of cryptography.
These restrictions have been in force since that late 1950s (with a long and complicated history with respect to computer cryptography). This particular text looks like a boilerplate restriction, that's required to comply with US EAR export requirements to me.
Digital certificates that signs software packages are used to enforce exclusion by some manufacturers. Let's encrypt is not in that space to my knowledge, but it is a place where you the owner do not have the right to determine which certificate authority should be trusted, and generally the only one that is trusted is the manufacturer. Its arguable if we even should be calling such entities a certificate authority, even if they technically are the owner of the root certificate that signs the package.
Russian government issued their new root certificate years ago.
Nobody trusted it enough to request a certificate from them or install it on their computers. Including almost all of the russian residents.
If Let's Encrypt enforces the rules, as written in pdf, a lot of people would lose a choice.
Frankly, even publishing a statement like that would make the scales of trust tip for some.
With all the problems with Web PKI, at least the bad actors are getting distrusted, and this provides a very strong enforcement on the rest. And Certificate Transparency makes sure the mis-issuance would be caught. It is not perfect by any means, but things are getting better.
With DANE (or other country-issued certificates), every government will absolutely double-issue certificates to police, secret service and friends of goverment, and no one will have any recourse. (In the past I'd say that only countries like Russia would do it.. but with today's climate, I am sure both US and many European countries will do that too)
Note that phones already try to prevent you from using a certificate that you provide yourself.
Maybe we should have solve the ISP snooping problem by making that illegal instead.
If it were as cheap and efficient as TLS these days, yes, absolutely
> Maybe we should have solve the ISP snooping problem by making that illegal instead.
We could do both! ISP snooping is still a problem for metadata (SNI).
If you want encryption without trust, just use self-signed certs.
I think the "digital tyranny" is a side effect, not the main goal. They're "mainly a means" to prevent certain kinds of MITM attacks.
Front matter:
2.1 "Term": 3.1 "Warranties":What's gonna happen if I were to begin or continue using one letsencrypt certificate from ... Greenland? Cuba? The EU?
Has letsencrypt been served with a subpoena?
While it's certainly possible that ISRG has been served a subpoena because it appears the US DOJ is now a mix of hacks and incompetent buffoons, it wouldn't matter because the whole point is that they don't know anything - what you told them is literally logged publicly for everybody to see without even knowing how to spell "subpoena" let alone issue one.
Some people have this insane idea that somehow the CA has some secret which either they minted and sent to the CA, or the CA minted and gave them a copy and so the US government could get this secret with a subpoena - but the whole fucking point of a Public Key Infrastructure is that we're using Public Key Encryption, if we were OK with everybody having secrets all over the place this entire thing wouldn't be needed.
LetsEncrypt certainly doesn't, but I've seen certificate storefronts that generate the key on their side and provide you the key and the certificate, so you don't have to figure out how to generate a key.
Looking at LavaBit^1 I really would not be so comfortable. The world and especially the US has not gotten more free since then.
[1]https://en.wikipedia.org/wiki/Lavabit
So to be effective this means a hypothetical bad actor (maybe the US government or anybody else) issues bogus certificates, then either logs them - making a permanent record for everybody to see, or also subverts two or more logs, so that they issue bogus proofs.
This is a very expensive one shot attack on whatever the target would be, I guess it's not stupider than "Let's bomb Iran for no good reason" but it's up there.
https://www.france24.com/en/americas/20250820-us-hits-icc-wi...
Perhaps because "US territories" are a thing, perhaps because it's way more newsworthy if LE bans the US, or perhaps im just a dummie.
The EU could easily bootstrap a Let's Encrypt competitor if it truly cared about removing dependencies on US based entities.
Cross-signed roots are common. Just takes money and maybe audits, but it's the same audit they'd need to get in the browser root stores anyway.
ZeroSSL from Austria also has a limited free tier. https://zerossl.com/pricing/
I mean really, if you use lets encrypt for anything that runs in a production environment, the responsible thing to do is build a fallback to switch to another provider in case LE has a bad day (or hits a brick wall and needs to say, enforce export restrictions).
LWN has a good writeup on the audit situation as of 2014: https://lwn.net/Articles/590879/
It is more of an example of how the internet/software industry is too consolidated to the US, and thus other countries are too dependent on the US in those areas. If the internet infrastructure was well distributed, then people in sanction countries could simply get certificates issued by a different CA, and in some cases they can. However, this is complicated by the fact that the list of trusted CAs is dominated by US organizations (Google, Mozilla, Apple, Microsoft). If you want to reach western audience you must use certs from a CA approved by them.
Then I graduated in International Relations and understood that the hole is much deeper than that.
Now it's pretty obvious with all the shit that trump has been doing, but back then me and much of the people I know were oblivious to what US power really means.
In all seriousness, as an American I'd love to see a healthier, more well-distributed tech industry, but I don't see many companies stepping up to provide competing services. It's my understanding that china has alternatives to many of these products/services, but I really don't see how anyone in Europe could possibly use a US-free internet.
Maybe because the US dropped most of its anti trust regulations, leading to ridiculously monopolistic practices such as "acquire everything that may be threatening".
This is the main reason letsencrypt is so popular.
But can we still trust them?
I am not well versed in how their systemwide certificate issuance works: If they have to add this to their terms to comply with their government, could the same government use pressure to leverage let’s encrypt to do harm.
- We’re based in Austria (ZeroSSL GmbH). The company was acquired by HID in 2024, which is part of Assa Abloy (Sweden).
- We’re not positioning ourselves as a purely EU-based CA substitute, and we generally don’t market it that way.
- For DV certs specifically, we act as a distributor. Under the hood these are Sectigo-issued certificates, similar to how other providers (for example Namecheap) operate.
Happy to clarify further if useful.
OK, but in the context of this topic thr interesting part isn't your marketing but your jurisdiction.
Could you clarify which jurisdiction you operate under and a link on the ZeroSSL website that collaborates that?
Thank you <3
There's no reason to believe they're any less subject to US jurisdiction than LetsEncrypt.
HID was acquired by Assa Abloy in 2000. No idea whether that means we now consider it Swedish.
ZeroSSL used to be Austrian until their acquisition in 2024.
I used to work for a company that got acquired by HID. It looks like HID has retained their original offices in some form.
Don't get me wrong, I agree that there is some lack of "who actually runs/controls this", especially on the about page where I expect such things to be.
At the very least it's not as transparent as I'd wish from a CA. E.g their Certificate Agreement is from Sectigo, so are they involved? No mention anywhere else from what I can see.
I can't comment on the EU part though - not that relevant in my case.
That’s a pretty steep increase. I would almost be more interested in a monthly fee per cert.
> By using ZeroSSL's ACME feature, you will be able to generate an unlimited amount of 90-day SSL certificates at no charge, also supporting multi-domain certificates and wildcards. Each certificate you create will be stored in your ZeroSSL account.
[0]: https://zerossl.com/documentation/acme/
Genuine question! Because I assumed there were other places you could get a SSL certificate, but people in this thread seem to be implying that without Let's Encrypt, there's no way for people in those sanctioned territories to get a cert.
No account, no payment, a single bash command or a certbot that runs regularly and you have your own globally recognised certificate
Historically, providers used to make the most frictions so that they could justify absolutely crazy fees for signing any certificates. It doesn't goes down well in DevOps, it doesn't work with indies who don't have 3 to 4 digits figures to blow in httpS, everyone including organisations ended up making certificates authorities of their own to sign stuff... and let's encrypt was successful at making certificates easy, free and actually secure
No.
is this standard MitM, or is it some crucially distinct variation?
> Also known as a monster-in-the-middle,[1][2] machine-in-the-middle,[3] meddler-in-the-middle,[4] manipulator-in-the-middle,[5][6] person-in-the-middle[7] (PITM), or adversary-in-the-middle[8] (AITM) attack.
I'm pretty sure a LE server hitting an Iranian or North Korean endpoint and validating a crypto challenge does not break any OFAC or EAR rules, and no money changes hands. And if a non-US entity wants to do it, the US would just sanction them. Microsoft and Mozilla are certainly not going to include a North Korean or Russian state CA in the root trusted certs (and if they did, the US government could just threaten them with sanctions, too).
Hard not to say "we warned you" about making self-signed certs completely unusable in favor of a very centralized approach.
But in fact, little by little you have all the stacks needed to be able to isolate some entities from internet at the us request in a very short time
Whatever USofA, it's not hard to have their own cosmodrome and certificates.
Tangential, in 2026 website certificates feel like nothing, disposable automation artifact, toxic max-security[1], vehicle for those who rent seek, fingerprint.
[1] https://tom7.org/httpv/httpv.pdf
The interesting version is that Web PKI is not just cryptographic infrastructure. It is also a policy distribution system. A browser trust store, a CA, a subscriber agreement, revocation rules, export controls, and sanctions law all end up in the request path of "can this site speak HTTPS to normal users?"
That does not make Let’s Encrypt uniquely bad. Any CA has some jurisdiction, owners, contracts, root-program obligations, abuse process, and legal exposure. Moving the CA changes the governance surface; it does not remove governance.
But it does mean "just use Let’s Encrypt" is not a neutral answer when protocols, browsers, APIs, app stores, or regulators effectively require TLS. The operational dependency is not only ACME uptime and certificate issuance. It is also jurisdictional continuity.
The hard product question is what failure mode we want:
1. Web PKI: power concentrates in CAs, browsers, and root programs. 2. DANE/DNSSEC: power shifts toward DNS operators, registries, registrars, and governments. 3. Self-signed / TOFU / pinning: power shifts toward application-specific trust and worse UX. 4. Multiple CAs: better resilience, but still bounded by browser trust stores and legal chokepoints.
There is no apolitical trust system here. There are only different control planes with different failure modes.
The practical ask from Let’s Encrypt should be clarity: issuance vs renewal vs revocation, existing certs vs future certs, domain location vs subscriber location, hosting location vs user location, and how they interpret “use” of a certificate. Without that, operators are left guessing whether this is a narrow compliance clause or a broad infrastructure-risk event.
Europe starts to shield itself from the risk since Nicolas Guillou, the French ICC judge who issued a warrant against bibi got sanctioned (France officially protested about this case)
China is being successful at blocking US firms out of their supply chains (they already use Linux on Loongarch processors with some homemade architecture and pioneer RISC V), since a bunch of their companies also got sanctions for supplying the governement
US stands so much for freedom that it's the first country to refuse immigration to FIFA world cup teams and athletes, with Iranians not allowed to stay between games and Somali goalkeeper being turned away at the border. Germany itself didn't do for the 1936 Olympics.
So at best, they're only shooting themselves in the foot by showing any US component in a supply chain is a risk, while using US clouds were already a risk of loss of revenue from FISA requests to undercut your bid and rot your company and using US dollars for trade was already a liability
In the meantime, US companies can do anything, break any financial law and abuse every human right, they'll just sign DPAs to avoid prosecution
> 2. officially or formally ratified or confirmed.
> 3. penalized, especially by way of discipline or to force compliance with legal obligations.
So who can use lets encrypt? Those that are penalised or those that are confirmed.
[1] https://www.dictionary.com/browse/sanctioned
> [You certify to LetsEncrypt that] …
> You are not a person or entity that is: (a) located in, organized under the laws of, or ordinarily resident in any country or territory that is the target of comprehensive U.S. sanctions; (b) a prohibited or restricted party under U.S. or other applicable sanctions and export control laws and regulations; or (c) owned or controlled by or acting on behalf of anyone described in (a) or (b). You agree to use Let’s Encrypt Certificates and any services provided by or on behalf of ISRG in compliance with applicable U.S. export control and sanctions laws and regulations.