Let's Encrypt herstelt vergeten sanctie-uitzonderingen in voorwaarden

Let's Encrypt publiceert versie 1.8 van zijn gebruiksvoorwaarden met daarin de belangrijke uitzonderingen op geopolitiek gebied die het recent in versie 1.7 was vergeten. Certificaatgebruik in landen onder Amerikaanse sancties leek uitgesloten, maar dat was 'een vergissing'.

De bijgewerkte versie 1.8 staat online en gaat 6 juli in. De non-profitorganisatie achter Let's Encrypt, de Internet Security Research Group (ISRG), nam in versie 1.7 geopolitieke beperkingen op, maar vergat daarbij belangrijke uitzonderingen te noemen. Die uitzonderingen staan het gebruik van beveiligingscertificaten toch toe voor personen, bedrijven en organisaties in landen die vallen onder sancties, exportwetten of -regulering van de Amerikaanse overheid.

De gewraakte passage (het zevende punt onder paragraaf 3.1) is verwijderd uit de nieuwe versie van de gebruiksvoorwaarden. De geopolitieke kwestie van certificaatgebruik in sanctielanden staat in de nieuw ingelaste paragraaf 5. Die gaat over het voldoen aan toepasselijke wet- en regelgeving. Daarbij is de formulering aangepast.

De paragraaf vermeldt uitdrukkelijk dat de organisatie achter Let's Encrypt zonder waarschuwing nieuwe certificaten kan weigeren en dat ze diensten kan opschorten of schrappen. Dit geldt als ISRG bepaalt dat een gebruiker, of een moederbedrijf daarvan, valt onder sancties, exportbeperkingen of exportregels. Daarbij geldt 'toepasselijk recht', wat de eerder vergeten uitzonderingen bestrijkt.

'Niet opzettelijk weggelaten'

De vorige versie van de gebruiksvoorwaarden 'was incompleet', liet een woordvoerder eerder al weten aan Tweakers. Op de vraag hoe dit kon gebeuren, antwoordt de organisatie nu dat het 'een vergissing' was. De belangrijke uitzonderingen 'waren niet opzettelijk weggelaten', verzekert de woordvoerder.

De nieuwe versie verschijnt tegelijk met een aankondigingspost van ISRG. Dit in tegenstelling tot de vorige versie, die de organisatie begin deze maand simpelweg online zette. In de post over de bijgewerkte gebruiksvoorwaarden schrijft communicatiedirecteur Sarah Gran dat de vorige verandering voor verwarring zorgde. De non-profit biedt excuses aan en geeft uitleg.

Reacties (30)

[DeCo]

Note to self: onderzoeken of Actalis een goed EU alternatief is.

[Ghoelian]

Die kende ik nog niet. Net even gecheckt, voor zover ik kan vinden is het goedkoopste certificaat bij hun 30 euro, dat vind ik toch wel wat duur voor een enkel domein. Het certificaat is dan wel een jaar geldig, dat krijg je bij Let's Encrypt niet. Dit klopt niet, als je onder "subscriptions" kijkt is er ook een gratis versie, waar je een certificaat die 90 dagen geldig is kan krijgen.

Ik zie ook een aantal plaatjes op de homepagina die toch wel heel erg AI-gegenereerd lijken.

[Reactie gewijzigd door Ghoelian op 24 juni 2026 16:03]

[Blokker_1999]

Waarom zou je vandaag nog een cert van 1 jaar wensen? Als het doel is deze te gebruiken voor een website kan je er niets mee want geen enkel certificaat dat van een publieke CA komt wordt nog vertrouwd als het 1 jaar geldig is. De maximale geldigheidsduur die browsers vandaag nog vertrouwen is 200 dagen, over een jaar is het 100 dagen en in 2029 wordt dat 47 dagen.

[Keypunchie]

Gaan nog een hele hoop die nog niet hun automatisering op orde hebben door gebeten worden, overigens.

Automatisch certificaat vernieuwen is 1 ding, maar zonder (of met minimale) downtime dat nieuwe certificaat vervolgens inlezen is vaak nog wel een issue.

Loop er zelf tegenaan met een systeem dat 24/7 hoge throughput heeft. De huidige methode voor het inlezen van een nieuw certificaat, geeft geen downtime, maar levert helaas (tijdelijk) performanceverlies op. Acceptabel, maar niet ideaal.

IP- (en dus TLS-)terminatie *ervoor* zetten kan niet, vanwege mutual TLS vereiste.

En deze oplossing vereist weer wat extra complexiteit om de vernieuwing op een relatief laag-impact moment te laten uitvoeren. Terwijl ik het graag natuurlijk lekker simpel houd!

[uiltje]

Mutual TLS kan je meestal inregelen met een aparte connector waarbij het user-certificaat wordt doorgegeven aan de achterliggende applicatie-server. Zo werken oa de Apache - Tomcat connectoren. Natuurlijk moet je backend / firewall config er dan ook mee om weten te gaan. Maar het is wel degelijk te programmeren / configureren.

[Keypunchie]

Maar wat geef je dan door? De connectie doorgeven kan (ssl-passthrough), maar dan houd je het probleem dat je termineert op de plek waar je een nieuw server-certificaat moet inlezen en die kan dat in dit geval dus niet zonder herstart.

[uiltje]

Je termineerd op de TLS accelerator en die geeft (automatisch of op aanvraag) de client certificate chain door (deze is meestal via de "context" op te vragen). Daarna kan je daarmee whitelisten enzo. Dus de foutafhandeling daarvan is dan in de applicatie server, de naam van de client enzo zitten in het leaf-certificaat.

Natuurlijk moet je niet alle client certs toestaan want dan heb je kans op een denial of service; meestal zijn de client certs natuurlijk van een specifieke CA, dus bij certs uit de verkeerde boom kapt de accelerator de verbinding al af.

[Reactie gewijzigd door uiltje op 25 juni 2026 01:41]

[Ghoelian]

Ik heb zelf nu gewoon al mijn certificaten via Let's Encrypt lopen met automatische renewal, dus de geldigheid interesseert mij totaal niet.

Ik kan alleen bij Actalis niks vinden over automatische renewal, alleen dat je dat handmatig via hun website kan doen. Dat ga ik toch echt niet elke 90 dagen doen.

[RobertMe]

Ik zie ook dat ze een free tier hebben. Waarmee je via ACME een kort (90 dagen) certificaat kunt krijgen, onbeperkt in aantal (domeinen, terugkerende aanvragen/vernieuwen, ...).

Waarschijnlijk kijk je dus verkeerd / bij een andere "variant" (certificaten kopen met striktere controles of je wel de eigenaar bent?).

En als je certificaten wilt hebben puur voor een home lab (intern gebruik) zou je ook nog een eigen CA kunnen opzetten. Met Step CA relatief makkelijk te doen. Heb die zelf nu een maandje zoiets draaien, en dat gaat ook prima. Doet ook ACME waarmee ik heb gewoon in bv Traefik heb kunnen hangen. Maar uiteraard moet je dan wel je eigen CA installeren op alle apparaten (of door de waarschuwing dat cert niet vertrouwd is heen klikken:+). Dus niet geschikt voor publiek gebruik.

[M66B]

Het probleem van Actalis is dat de private key door hun servers wordt gegenereerd:

https://davidroessli.com/logs/free-smime-certificates-in-2019/#update20191219

De certificaten zelf, bijvoorbeeld voor S/MIME zijn prima bruikbaar.

[DeCo]

Als je ACME gebruikt voor TLS/SSL, wordt de keypair op de eigen server gegenereerd. Dan is dat geen probleem? S/MIME is inderdaad een ander verhaal.

[M66B]

Dat is een ander verhaal inderdaad. Goed punt.

[Llopigat]

Oh ja dat is geen goede optie inderdaad. Het is niet voor niet zo dat je die zelf genereert en dan de public key laat ondertekenen. Wat raar dat ze dat zo doen. Tegen alle regels in.

[Keypunchie]

Dat lijkt voor S/MIME het geval. Voor TLS lijkt het anders te zijn.

[Saeverix]

Heb het net even bekeken, maar een exacte vervanger voor Let's Encrypt is het nog niet. De gratis tier van Actalis biedt geen wildcard-certificaten en heeft voor zover ik kan zien slechts ondersteuning voor 1 domein.

Ik heb zelf 2 domeinen en gebruik wildcard-certificaten, dus Actalis valt momenteel af voor mij. Een korte zoektocht naar andere EU-alternatieven komt erop neer dat die er simpelweg nog niet zijn.

[Clueless]

Je zou nog kunnen kijken naar ZeroSSL. Is supported via Certbot en ACME.sh. Zit in Oostenrijk geloof ik.

Moet je een accountje aanmaken in de Free Tier. Dan krijg je 3x een 90dagen certificaat via hun web-dashboard maar unlimited via ACME:

Unlimited Certificates, Free of Charge:

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.

ZeroSSL - Documentation > ACME

Met de support voor SAN en wildcards komt het goed overeen met wat Let's Encrypt aanbiedt.

[RobertMe]

Je zou nog kunnen kijken naar ZeroSSL. Is supported via Certbot en ACME.sh. Zit in Oostenrijk geloof ik.

Ik kan zo snel geen eenduidig actueel antwoord vinden. Wel opgericht in Wenen, Oostenrijk. Op een gegeven moment overgenomen en naar Engeland (Londen) verhuisd. Mogelijk daar nu nog gevestigd? Mogelijk niet?
In beiden gevallen in ieder geval niet in VS gevestigd geweest.

[Saeverix]

Klonk als een fijn alternatief, maar zie dat ze twee jaar terug overgenomen zijn door het Amerikaanse HID: https://newsroom.hidglobal.com/hid-enhances-its-pki-offerings-acquisition-trusted-certificate-service-provider-zerossl?utm_campaign=ms-msgeneric&utm_medium=organic-social&ls=organic-social&utm_source=linkedin&utm_offer=press-release&mtm_offer=press-release&utm_detail=acquisition-release-jan-2024-zerossl-li-tw-ig&mtm_detail=acquisition-release-jan-2024-zerossl-li-tw-ig

[Xatom]

Ik ben een paar maanden terug overgestapt op Actalis, je kan unlimited certificaten aanmaken als je gebruikt maakt van ACME. De switch was ook heel simpel, alleen het ACME URL aanpassen en de credentials uit het control panel van Actalis kopieren.

Maar geen wildcard certificaten inderdaad.

[readefries]

De tekst op de site klinkt wat ambigu over hoeveel domeinen je kunt toevoegen.

DV Single domain - 90d Unlimited with ACME *

Ik lees het als je onbeperkt domeinen kunt toevoegen. Dat is precies wat er ook bij de andere pakketten staat, alleen staat bij de gratis variant de preconditie dat je ACME gebruikt.

Ik heb een account aangemaakt, maar ik moet het nog even koppelen aan cert-manager in k8s om certificaten aan te maken.

Wat ik me afvraag: wat maakt het voor jou uit of je ACME gebruikt of een wildcardcertificaat gebruikt? Als je het automatiseert, is dat dan toch minder relevant?

[WhatsappHack]

N=1, maar heb slechte ervaring met ze en de opzet is nogal raar. Iig nu geen LE vervanger.

[Keypunchie]

Ze zitten in de belangrijkste standaard CA's, dus in principe is er geen plek waar LE zit waar zijn niet ook vertrouwd worden.

Maar, het is een commercieel bedrijf (onderdeel van Aruba), dus de vraag is wel.of ze niet in de toekomst hun verdienmodel gaan aanpassen

[Mathi159]

Welke garantie hebben gebruikers eigenlijk dat Let's Encrypt niet alle certificaten linea recta naar de Amerikaanse 'veiligheids' diensten stuurt?

[laurxp]

Dit is met het gebruikte ACME-protocol onmogelijk. De geheime sleutel verlaat nóóit de client.

Daarnaast, alle certificaten zijn al publiek. De CAs zijn verplicht om ze in een publieke "certificate transparency" log te zetten. Dat is nou juist de manier waarop ze voorkomen dat een CA stiekem wat certificaten voor de CIA aanmaakt!

[Keypunchie]

Dat laatste blijft wel een risico, want die verplichting is niet wettelijk, of technisch, maar een proces-afspraak.

Als de CIA/FBI/NSA aanklopt met FISA of CLOUD Act in de hand (of iets waarop "nationale veiligheid" staat) en een publiek certificaat voor Tweakers.net (of een ander domein) opeist met eis van stilte (gag order), dan zal hun advocaat ongetwijfeld adviseren om dat gewoon te doen...

[RobertMe]

Dat is geen probleem. Het certificaat wordt lokaal gegenereerd, en het publieke deel wordt door LE ondertekend. En nouja: "het publieke deel" dus. Dus je moet het al als publiek beschouwen, en dus kun je het ook prima beschouwen dat de Amerikaanse 'veiligheids' diensten het in handen hebben. Zolang het private deel maar private is. En dat is het dus omdat je dat zelf lokaal genereert en dat nooit over de lijn gaat, ook niet naar LE.

[fastedje]

Je kan elk certificaat gewoon al direct van de server zelf opvragen met.openssl. in het certificaat zelf staan geen geheimen, iederen mag dat inzien. De private key moet wel prive blijven.

[Patriot]

Mogelijk komt het gewoon door de aard van het nieuws, maar wat leest dit artikel beroerd. De gemaakte fout van vergeten voorwaarden is hersteld door de gewraakte passage te verwijderen, de tekst is qua formulering aangepast en staat in een nieuwe paragraaf. Ja ja.

En dit:

Daarbij geldt 'toepasselijk recht', wat de eerder vergeten uitzonderingen bestrijkt.

Volgens mij is het cruciale verschil gewoon dat er in de bewoording niet meer staat dat je verklaart je niet in een land te bevinden waar sancties tegen zijn. De oude bewoording was (nadruk toegevoegd):

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;

De nieuwe bewoording is specifieker en expliciet: Als wij (ISRG) bepalen dat jij (en niet zozeer het land) onder die sancties valt dan kunnen we alles intrekken.

[NotHere]

Dit nieuws valt ongeveer tegelijk met een Bugzilla report van een bedrijf dat TLS-certificaten uitgeeft en zich daarbij niet houdt aan EU-sancties.

https://bugzilla.mozilla.org/show_bug.cgi?id=2049237

Toeval?

[laurxp]

Toeval?

Ja?

Er is geen enkele link tussen Harica en LetsEncrypt, en er is geen enkele eis vanuit de CA/B Forum om enige vorm van sanctie-validatie te doen voor DV certs.

LE neemt zulke statements op in hun voorwaarden omdat ze in de VS zitten, en ze zich aan de lokale wetgeving moeten houden. Ze zijn niet bereid om in juridische problemen te komen door willens en wetens certificaten te verstrekken aan partijen die onder sancties vallen. Dit is niet héél gek, want waarom zou je je hele bedrijf riskeren? Als ze een juridisch bevel krijgen om vanwege sancties een certificaat in te trekken, dan zúllen ze dat dus doen, en ze zijn daar open over.

Harica zal ongetwijfeld een vergelijkbare positie hebben. Een email van een random persoon is voor hun alleen niet genoeg om een DV certificaat in te trekken - want voor hetzelfde geld staat dat vol met leugens: hoe weet je 100% zeker dat een domein écht in handen is van een entiteit onder sanctie? Zolang ze geen juridisch bevel krijgen, is er dus geen reden om te handelen.