Let's Encrypt maakt TLS-certificaten van 160 uur algemeen beschikbaar

Let's Encrypt heeft zijn kortdurende TLS-certificaten algemeen beschikbaar gemaakt. Deze zijn slechts 160 uur geldig, bijna zeven dagen. Dat moet voordelen bieden op het gebied van cybersecurity.

Klanten kunnen vanaf nu kiezen voor TLS-certificaten die slechts 160 uur geldig zijn, laat Let's Encrypt weten. De reguliere certificaten zijn momenteel 90 dagen geldig, hoewel het de bedoeling is dat de duur de komende twee jaar geleidelijk wordt verlaagd naar 45 dagen. Volgens Let's Encrypt is het niet de bedoeling dat de kortdurende certificaten in de toekomst de standaard worden.

Door de geldigheidsduur van de TLS-certificaten te verkleinen, wordt de kans op misbruik kleiner. Aanvallers hebben immers maar een aantal dagen de tijd om het certificaat te compromitteren. Zelfs als dat lukt, kunnen ze er ook maar een korte periode misbruik van maken. Na de 160 uur wordt het certificaat vernieuwd en moet de aanvaller helemaal opnieuw beginnen. Let's Encrypt gaf vorig jaar zijn eerste certificaten van zes dagen uit aan een selecte groep gebruikers, maar nu zijn ze dus breed beschikbaar gemaakt.

Reacties (147)

[PacinoAllstars]

Interessant nieuws (los van het feit dat het een publiek geheim is dat big tech de levensduur van certificaten near real-time willen) , maar los daarvan blijf ik huiverig bij dit soort ontwikkelingen rond Let’s Encrypt.

Het gemak en de gratis certificaten zijn super, maar laten we niet vergeten dat Let’s Encrypt een Amerikaanse organisatie is (onder de Internet Security Research Group, gevestigd in de VS). Elke keer dat een Europese server een certificaat aanvraagt via ACME of een OCSP-check doet voor revocation status, gaat dat verkeer naar servers die onder Amerikaanse jurisdictie vallen.

Zelfs als het verkeer zelf versleuteld is en de inhoud niet gelezen kan worden, zien zij wel:

• welk IP-adres het verzoek doet
• voor welk domein het certificaat aangevraagd wordt
• eventuele patronen in aanvragen

En ja, ook als je een VPN of proxy gebruikt: het IP dat zij zien is dan dat van de VPN-exitnode, maar de koppeling domein → aanvragend IP (of VPN-provider) blijft zichtbaar voor hen. Onder de CLOUD Act of een nationale beveiligingsbrief kunnen Amerikaanse autoriteiten die logs opvragen zonder dat wij daar veel over te zeggen hebben.

Voor individuele hobby-sites is dat misschien geen ramp, maar voor kritieke infrastructuur, overheden, bedrijven en nieuwsorganisaties in Europa voelt deze afhankelijkheid van een buitenlandse CA steeds ongemakkelijker aan, zeker nu de geopolitieke spanningen toenemen.

Ik zou graag zien dat Europa meer investeert in een eigen, onafhankelijke certificate authority met vergelijkbaar gemak en automatisering. Dan houden we de controle over onze eigen digitale infrastructuur een beetje meer in eigen hande.

[MagicAndWires]

In principe waar, maar ik weet niet wat de VS daar qua surveillance aan heeft, zeker als die persoon niet vanuit de VS opereert. Ik neem aan dat ze wat surveillance betreft tig andere mogelijkheden hebben, zeker voor enkel een IP adres. Een grotere dreiging lijkt mee meer dat ze Let's Encrypt opdragen alle certificaten in te trekken of de service helemaal offline halen.

Hoe dan ook geen slecht idee om een Europese service op te zetten.

[RobertMe]

Een grotere dreiging lijkt mee meer dat ze Let's Encrypt opdragen alle certificaten in te trekken of de service helemaal offline halen.

Is een vele malen grotere dreiging niet een backdoor of zo? Of gewoon letterlijk (specifieke) certificaten laten loggen / opsturen naar de overheid. Waarna die dus het TLS verkeer kunnen decrypten doordat ze het private certificaat hebben. In zo'n geval is het gebruik van TLS dus waardeloos, en kan het net zo goed plain text zijn. (V.w.b. meekijkende ogen van de overheid dus).

Het hele certificaten gebeuren is immers gestoeld op vertrouwen. Waaronder het vertrouwen dat maar één iemand het private deel bezit (maar mogelijk wel op meerdere servers gebruikt wordt) en dát dus de enige is die het kan ontsleutelen. De website bezoeker vertrouwt jou dus dat het certificaat niet gelekt is. En evenzo moet je als beheerder het vertrouwen hebben dat (óók) jou certificaat verstrekker het certificaat niet lekt.

[fastedje]

Wat ik erg dubieus vind is dat het veel interessanter is om CA en roor certificaten aan te vallen. Deze zijn veel langer geldig en je kan er een veel meer mee, osls valse certificaten genereren. Waarom dus de focus op de geldigheidsduur van gewone certs en niet die van certificaten authorities?

[soczol]

Ik denk dat je dat wel een beetje onderschat. Tegenwoordig zijn CA's volgens mij verplicht om Certificate Transparency logs bij te houden. Zodra er een certificaat wordt uitgegeven dat niet in die CT logs staan dan gaan de alarmbellen af. Tevens is het zo dat veel browsers tegenwoordig alleen certificaten accepteren die in die CT logs te vinden zijn.

Maar, true enough, dat is altijd "after the fact".

[demianmonteverd]

Zoals je al aangeeft, het is after the fact, maar ook... Als je 'snode plannen' hebt en die aan het uitvoeren bent, dan houd niets je toch tegen om te rommelen met de transparancy logs? En, bovendien moet je maar net kijken in die logs, jouw browser kijkt er echt niet realtime naar bijv.. Denk dat ze niet echt helpen voor targetted pogingen om verkeer decrypted te kunnen lezen.

[deadinspace]

Is een vele malen grotere dreiging niet een backdoor of zo? Of gewoon letterlijk (specifieke) certificaten laten loggen / opsturen naar de overheid. Waarna die dus het TLS verkeer kunnen decrypten doordat ze het private certificaat hebben. In zo'n geval is het gebruik van TLS dus waardeloos, en kan het net zo goed plain text zijn. (V.w.b. meekijkende ogen van de overheid dus).

Dat kan niet, dat is niet hoe certificaten werken.

Certificaten in het kort:

• Aanvrager genereert private+public keypair
• Aanvrager stuurt public key naar Certificate Authority (CA) met het verzoek daarmee een certificaat te maken voor een domein
• CA controleert of aanvrager het domein beheert
• CA genereert certificaat op basis van het domein en de gegeven public key, en stuurt het certificaat terug
• Website op het domein wordt geconfigureerd om het certificaat en de private key te gebruiken
• Client bezoekt website, website verstrekt certificaat + een handtekening voor het certificaat gemaakt op basis van de private key

Het certificaat is per definitie publiek, dus Let's Encrypt mag die lekken. Een "private certificaat" bestaat niet. De private key blijft altijd bij de aanvrager, dus Let's Encrypt kan die niet lekken.

Wat Let's Encrypt wel zou kunnen doen is een vals certificaat genereren op basis van een keypair van de Amerikaanse overheid. Daarmee krijgt de Amerikaanse overheid een eigen certificaat dat geldig is voor jouw domein.

Maarja, dat kan elk van de ~200 CAs wereldwijd. Het is bijvoorbeeld ooit gebeurd toen de Nederlandse CA DigiNotar gehackt was, toen hebben de inbrekers valse certificaten gemaakt voor o.a. gmail.com.

[MagicAndWires]

Backdoor is inderdaad nog ernstiger, had ik niet bedacht. Hangt ervan af hoe ze het aanmaken van certificaten hebben geïmplementeerd.


Maar als ik het me goed herriner wordt een al bestaand certificaat volgens mij alleen steeds opnieuw verlengt en ondertekend. Komt alleen de privésleutel van Let's Encrypt mee aan te pas.

[Tozz]

Dan snap je niet hoe certificaten werken. De private key is niet in handen van de uitgever. Alleen de csr

[aikebah]

Al zou het mij niets verbazen als die verwarring mede veroorzaakt wordt door hoe soms met certificaten omgegaan wordt. Jaren terug ook wel gehad dat ik een (intern) TLS certificaat nodig had en dat de aanvraag enkel wat gegevens is waarna je een private key en certificaatbundel uitgeleverd krijgt van de interne IT afdeling (waarschijnlijk omdat ze dan niet hoefden uitleggen hoe je een correcte (volledig conform de interne eisen aan de interne certificaten) CSR fabriceert.

Bij ons is het inmiddels wel al jaren correct ingeregeld, waarbij je hooguit de kans loopt dat je aanvraag geweigerd wordt omdat de CSR niet aan de gestelde eisen voldoet (automatisch via ACME protocol met controles op bedrijfsbeleid in de meeste gevallen, handmatige ticketprocedure met een CSR voor de gevallen waar aansluiten op ACME protocol oplossing niet mogelijk is (niet-standaard legacy interne domeinen die men niet in de ACME oplossing wil provisionen), maar zou me helemaal niet verbazen als er nog steeds IT afdelingen zijn die je 'volledig ontzorgen' en je een private key en bijbehorend certificaat uitleveren, waardoor je al snel kunt denken dat certificaat en private key samen uitgegeven worden.

[blondie1970]

Let's encrypt signed (verifieerd de eigenaar) slechts het publieke certificaat, de private key (uiteindelijk nodig voor de decryptie) komt is de signing niet voor en (als het goed is) is veilig opgeslagen onder je eigen beheer. MiTM zijn niet de zorg, DDoS enz zeer zeker (en beschikbaarheid is ook veiligheid)

[PacinoAllstars]

Klopt, de surveillance-waarde van “alleen een IP” lijkt beperkt, maar het gaat juist om de metadata; de directe koppeling tussen domeinnaam (bijv. kritieke infrastructuur, nieuws- of activisten-sites) en aanvragend IP/patroon/OCSP-queries. Dat is waardevolle intelligence voor mapping van infrastructuur, en onder de CLOUD Act geldt dat extraterritoriaal en daarmee ook voor Europese servers.

En je slaat de spijker op z’n kop met dat intrekken of offline halen, dat is een pas kill switch!

[GeroldM]

En dan ontdek je dat HTTP nog steeds werkt.

(/s als dat niet duidelijk is)

[sir_huxley]

Veel browsers hebben HSTS Wikipedia: HTTP Strict Transport Security geïmplementeerd.

De browser onthoud dus als het ware of je de website eerder via https heb bezocht. Indien dat het geval is dan weigert de browser via http te verbinden. Dit kan gereset worden maar vergt wel enige kennis.

[aikebah]

De browser onthoudt niet dat je de site via https bezocht hebt, hij onthoudt dat de server heeft gezegd dat ie voor de eerstkomende xx tijd altijd via https bezocht moet worden (en heeft een ingebakken lijstje van sites die bij de browser-bouwer hebben aangegeven dat ze altijd over https benaderd moeten worden)

Zolang de server-beheerder niks heeft ingeregeld onthoudt de browser helemaal niks over https of http gebruik (behalve dan de browse-history zelf)

[sir_huxley]

De browser onthoud dit wel degelijk. De server stuurt enkel een header waarin het aangeeft of het deze functie wilt activeren.

Zie Open HSTS Settings: Type chrome://net-internals/#hsts into your Chrome address bar and press Enter.

[aikebah]

Hij onthoud niets als de server die header niet meestuurt en het statement was "hij onthoud het als JIJ een site met https bezoekt"

[Reactie gewijzigd door aikebah op 18 januari 2026 22:05]

[demianmonteverd]

Dat werkt alleen zolang dat cert geldig blijft, en die tijd zijn ze dus aan het inkorten. Overigens is HSTS echt alleen voor de echte hard core admins, ik blijf er van weg, als je een grote site hebt en je maakt een miniscuul foutje (niet doen natuurlijk!) hangen al die gebruikers die je fout hebben opgehaald aan de lijn (of erger, je bent je klanten voor altijd kwijt)... Het is echt een mega krachtige oplossing, maar pfee...

[aikebah]

Nope, dat werkt zolang je zorgt voor een geldig TLS certificaat. Het koppelt enkel domeinnaam aan "MOET over https benaderd worden". Dus zolang jij zorgt dat je kortlevende certificaat op tijd ververst wordt is er helemaal niks mis met HSTS aanzetten en is het juist ten zeerste aan te raden om dat te doen en daarmee een extra blokkade te maken voor http-downgrade.

edit:
ik denk dat jij HSTS en certificate pinning door elkaar haalt.

[Reactie gewijzigd door aikebah op 18 januari 2026 22:09]

[demianmonteverd]

Je hebt helemaal gelijk. Ik was aan het denken aan cert pinning. Maar dat is een ander mechanisme. Ik weet niet waarom ik ze door elkaar heb gehaald. Misschien dat we ze een keer tegelijk ingezet hebben in een project.

[fenrirs]

Een grotere dreiging lijkt mee meer dat ze Let's Encrypt opdragen alle certificaten in te trekken of de service helemaal offline halen.

Deden ze dat maar eens, dan wordt direct duidelijk hoe afhankelijk wij zijn in de EU. Pas dan gaat er iets bewegen

[To_Tall]

Lets encrypt is gratis. En wordt veel gebruikt. Maar wil niet zeggen dat infra kritische systemen hier gebruik maken.

Zo zijn er tal van systemen die zelfde kunnen en doen als Letsencrypt.

Zo gebruikt de belastingdienst DigiCert certificaten die ook certificaten aan bieden met Max 47 dagen.

Goed digicert is ook Amerikaans. Maar geeft wel aan dat meer bedrijven soort gelijke diensten leveren.

Als we naar USA moeten kijken dan kunnen we het ook hebben over ICANN en/of IP uitgevers hebben gezien deze ook de USA beheerd worden.

[TechSupreme]

Tja, vruuger hadden wij DigiNotar. Weet je nog hoe dat afliep?

Daarna zijn publieke certificaten een tijdje door Logius beheerd, maar uiteindelijk is er gezegd dat commerciele bedrijven dat veel beter kunnen en is Nederland (toen als enige land met een eigen CA) gestopt.

Voor kritische infra heeft Nederland nog wel PKI Overheid, het private deel wat nog steeds door Logius wordt beheerd.

[To_Tall]

Tegenwoordig hebben we PKI-overheid.
https://www.pkioverheid.nl/

En als je gaat zoeken zie je dat de Nederlandse overheid meer CA diensten heeft zowel intern als extern gebruik.

[Reactie gewijzigd door To_Tall op 17 januari 2026 10:36]

[PacinoAllstars]

Klopt, PKIoverheid (beheer door Logius) is een Nederlands initiatief voor betrouwbare communicatie met en binnen de overheid, inclusief eIDAS-gekwalificeerde certificaten. Er zijn inderdaad meerdere TSP’s (zoals DigiCert, KPN) die onder dit stelsel opereren, zowel voor intern als extern gebruik.

Maar het is geen echt alternatief voor Let’s Encrypt op het open web:

•  Geen gratis, massaal geautomatiseerde domain-validated (DV) certificaten voor iedereen – het richt zich vooral op hogere assurance-niveaus (OV/EV/qualified), vaak betaald en met meer administratie.

•  Voor publieke browser-trust moeten de roots opgenomen zijn in de trust stores van Apple, Microsoft, Google en Mozilla en dit betreffen allemaal Amerikaanse big tech die de regels dicteert.

•  Zelfs eIDAS-gekwalificeerde webcertificaten en het beleid van Logius/TSP’s moeten voldoen aan de Baseline Requirements van het CA/Browser Forum (zoals expliciet vermeld in hun CPS-documenten).

Kortom, indirect blijven we gebonden aan Amerikaanse standaarden en gatekeepers.

[TechSupreme]

Even lezen, ik zeg zelf in de laatste zin dat Logius PKI Ovehreid beheert, maar PKI Oerveheid is alleen voor intern gebruik.

De de root van PKI Overheid is niet een geregistreed in je OS, in geen een OS dus het gaat heel lastig worden om daar publieke servers mee op te zetten.

PKI Overheid is alleen bedoelt voor de overheid zelf.

[aikebah]

edit:
had niet goed gelezen... reactie was niet relevant

[Reactie gewijzigd door aikebah op 17 januari 2026 11:57]

[PacinoAllstars]

Klopt, Let’s Encrypt is gratis en superpopulair, volgens W3Techs heeft het momenteel zo’n 64% marktaandeel onder bekende TLS-certificaten (https://w3techs.com/technologies/details/sc-letsencrypt). Dat is geen sterk argument voor, maar juist een risico: we hebben een groot deel van het Europese web afhankelijk gemaakt van één Amerikaanse CA.

Kritieke infrastructuur (zoals de Belastingdienst met DigiCert) kiest vaak betaalde opties, maar DigiCert is ook Amerikaans. Fragmentatie over meerdere Amerikaanse partijen helpt weinig: ze vallen allemaal onder de CLOUD Act, dus metadata van aanvragen en OCSP-checks blijft opvraagbaar door de VS, zonder Europese zeggenschap.

Net als bij ICANN en IP-toewijzing: we zijn al afhankelijk van de VS, maar nog een dominante laag toevoegen maakt ons alleen kwetsbaarder.

Europa heeft in mijn beleving echt een eigen, gratis en (geautomatiseerde) CA nodig voor echte digitale soevereiniteit.

[familyman]

Aangezien certificaten rusten op vertrouwen en het zo zoetjes aan nu toch zelfs voor henk en ingrid duidelijk moet zijn dat amerika niet te vertrouwen is....

Moet er zsm een europese dienst komen, en nog sneller onze overheidsdiensten van amerikaanse certificaten af.

Het is gestoord om er mee door te gaan, onder het mom, maar er is niks europees, het is zo duur of het is zo makkelijk.

[Tralapo]

Momenteel hebben we blijkbaar alleen een Italiaans alternatief, alleen nog nooit van gehoord: European Alternatives

[Yzord]

Europa is druk met andere dingen en heeft de slag om IT allang verloren en vrijwillig afgestaan aan voornamelijk de US. Er zijn geen visionairs in de EU, alleen uitvoerders en ja knikkers.

[bzuidgeest]

Als je een keer een race verliest bekend dat dan volgens jou dat je maar niet nog een keer probeert?

Met mensen met jou houding komen we zeker nergens. Die geven al op voor ze begonnen zijn op na het eerste verlies. (Zo klinkt je comment in ieder geval voor mij)

Als we willen kunnen we de schade die we gedaan hebben die te veel op vrienden te vertrouwen gewoon ongedaan maken. Ook op it gebied. Veel van de zogenaamde Amerikaanse innovaties zijn gewoon geboren uit onderzoek hier dat we verkocht hebben. Genoeg heeft zijn basis hier, alleen de uitvoering in de vs

[Reactie gewijzigd door bzuidgeest op 17 januari 2026 00:49]

[theduke1989]

maar alles gaat maar 1 richting op dus, amerika. dat is waar hij ook op doelt.
In principe bieden alle hosting bedrijven ~gratis SSL certificaten~ helaas alles van LetsEncryp. Dus ja we moeten er aan geloven, dat LetsEncrypt toch wel de standaard is voor alle gratis certificaten. Die allemaal naar USA gaan!

[WebHawk]

Gelukkig hebben wij DigiNotar- oh... wacht.

[Faloude]

Hahaha

[Nimja]

Blijkbaar is er: https://european-alternatives.eu/product/actalis-ssl - Die ook het ACME protocol gebruikt en uit Italie is.

Maar heeft een paar nadelen:

• Does not support wildcard certificates on free plan
• Does not support IDNs
• Dashboard does not have two factor authentication

[Reactie gewijzigd door Nimja op 16 januari 2026 22:20]

[MoonRaven]

Het niet hebben van wildcard is lastig. Voor zover ik weet vraagt traefik (mijn proxy manager) dit juist aan en ik zie ook geen plugin om het te supporten dat het voor elk subdomein dit aanvraagt. Zelfde met Nginx Proxy Manager.

[babbelbox]

Ik weet niet beter dat Traefik juis voor elke (sub)domein een eigen certificaat aanvraagt. Ik gebruik het al geruime tijd met succes op m'n docker swarm.

[Antyrael]

Ik gebruik NPM en kan je vertellen dat die geen wildcard certificaten gebruikt voor de proxies.

Vijand chatgpt kan Traefik het ook prima en is het zelfs de standaard methode.

Traefik will request one certificate per hostname when:

You use HTTP-01 or TLS-ALPN-01 ACME challenges

You define routers with explicit hostnames (Host(...))

You do not request a wildcard domain

Each router hostname results in its own cert

Tenzij:

You must use wildcard certs if:

Your services are not publicly reachable on port 80 or 443

You need HTTPS before routing exists

You want a single cert for many unknown subdomains

In those cases, DNS-01 + wildcard is required.

[TechSupreme]

Interessant nieuws (los van het feit dat het een publiek geheim is dat big tech de levensduur van certificaten near real-time willen) , maar los daarvan blijf ik huiverig bij dit soort ontwikkelingen rond Let’s Encrypt.

Near real-time? Ik weet niet wie jou dat wijs heeft gemaakt, maar dat is dus onzin. De PKI is juist opgezet omdat je het niet real-time of near real-time wil doen. Je wil eigenlijk rustig op je gemak en onafhankelijk van wie dan ook.

Wist jij dat vuuger het beleid was om server certificaten te versturen via sneaker net? Het RDW doet dat nog steeds. Daar is een reden voor!

Sowieso wat is near real-time volgens jou? Hoe near is near? Download voor de gein eens OpenSSL en ga eens met een je eigen CA een certificaat ondertekenen. Ook al heb je een krachtige moderne processor, kijk eens hoe lang dat duurt.

Volgens mij wil je zeggen dat er voor elke client een ander certificaat wordt voorgeschoteld, maar wat daar het nut van is, is mij totaal niet duidelijk. Ga jij continu nieuwe certificate genereren en die verzenden? Dat wordt een leuk MITM aanvalletje.

Je zult met een totaal andere opzet moeten komen als je dit near real-time wil gaan doen en dan nog, wat is het nut ervan?

Je argument over ACME snap ik even niet zo goed, je server zal sowieso internet facing moeten zijn. Het IP adres van je server is publieke informatie en is te achterhalen via een DNS query. Iedereen die met je server wil verbinden, zal het IP adres moeten weten.

De privacy bezwaren over OCSP zijn niet van vandaag of gisteren. Dat is ook de reden waarom het niet meer wordt gebruikt. Het nadeel van een CRL is dan wel weer dat er een flinke vertraging in zit en ook client side te manipuleren is. Elk nadeel heb ook wel zijn voordeel.

LE is juist gestopt met OCSP vanwege die privacy bezwaren:
https://letsencrypt.org/2024/12/05/ending-ocsp

Chromium heeft aangegeven het uit te faseren.

Wat ik daarom echt niet begrijp, ene kant wil je het allemaal near real-time en dan begin je ineens over privacy. Welke wil je nou?

Alles wat je noemt is eigenlijk onzin of helemaal niet eens zo erg. Het echt probleem hoor ik je niet benoemen. Om eerlijk te zijn, ik heb liever dat de CA van een werelddeel wordt gehost door een andere.

[Reactie gewijzigd door TechSupreme op 17 januari 2026 04:54]

[PacinoAllstars]

Met “near real-time” bedoelde ik de trend naar extreem korte certificaatlevensduur als alternatief voor echte revocation: certs verlopen vanzelf zo snel dat revocation minder nodig is.

Maar precies die shift wordt geforceerd door de CA/Browser Forum (Ballot SC081v3, april 2025), vooral gepusht door Apple en Google:

•  Vanaf 15 maart 2026: max 200 dagen

•  Verder naar ~47 dagen rond 2029

(staat in het dit artikel)

Officiële reden: kleiner attack window. Maar het dwingt vooral volledige ACME-automatisering af, handmatig verlengen of offline signing (sneakernet, zoals bij RDW) wordt onpraktisch. En raad eens: Big Tech (Apple/Google/Mozilla) profiteert ervan, want het maakt certificaatmanagement makkelijker via hun ecosystems, devices en cloud-tools.

Hardware-based oplossingen zoals smartcards of QSCD’s (onder ETSI/eIDAS voor qualified certs) worden veel lastiger bruikbaar, omdat je zo vaak moet vernieuwen (en ja post issuance is een optie).

Resultaat is dar iedereen stroomt naar geautomatiseerde (vaak Amerikaanse) CA’s zoals Let’s Encrypt.

Privacy bij lets encrypt is iets beter zonder OCSP, maar de centralisatie en VS-afhankelijkheid wordt alleen maar groter.

Eens dat dit een probleem is voor Europese digitale soevereiniteit? En jij denkt dat het bij 47 dagen blijft?

[TechSupreme]

Jij moet de betekenis van het woord "real-time" eens opzoeken.

Nogmaals, ik heb liever dat de CA van een continent in extern beheer is. Goed onthouden.

Maar het dwingt vooral volledige ACME-automatisering af

Je hebt nog steeds niet uitgelegd wat het probleem is dat het IP van de server bekend is. Dus dat de Amerikaanse overheid een DNS query doet op jouw domein is een privacy issue?

Big Tech (Apple/Google/Mozilla) profiteert ervan, want het maakt certificaatmanagement makkelijker via hun ecosystems, devices en cloud-tools.

Mozilla is big tech? Nice! En Microsoft is dat niet? Jammer! Ik snap je verhaal nu al helemaal niet meer. gaat het nou over browsers of over diensten? Je gaat van de hak op de tak. Als het dan toch alleen over browsers gaat, wat is je probleem met ACME?

Ene kant zeg je Browser Forum, andere kant zeg je vendor lockin... hoe dan?

Wat heeft dit alles te maken met het root certificaat? Jij haalt zoveel dingen door elkaar dat het onmogelijk is om te volgen nou wat je precies bedoelt, maar wat heeft de public key van de signing authority in je Brwoser te maken met de private certificaten die door LE worden afgegeven? Hoezo heb je daar tools van Apple of Google voor nodig? Tools van Apple, Google en Microsoft die voor totaal andere doeleinden worden gebruikt.... huh? Waar heb jij het eigenlijk over?

Hardware-based oplossingen zoals smartcards of QSCD’s (onder ETSI/eIDAS voor qualified certs) worden veel lastiger bruikbaar, omdat je zo vaak moet vernieuwen (en ja post issuance is een optie).

Wat heeft Browser Forum hiermee te maken? Ik citeer:

The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and suppliers of Internet browser software and other applications that use certificates (Certificate Consumers).

Ik wist niet dat het ETSI een browser maakte... Wat hebben eIDAS kaarten te maken met SSL verkeer?

Resultaat is dar iedereen stroomt naar geautomatiseerde (vaak Amerikaanse) CA’s zoals Let’s Encrypt.

Nogmaals hebben we het hier over SSL certificaten? Je hebt er echt een potje van gemaakt. En je hebt nog steeds niet het echt probleem benoemd, alleen dat de Amerikanen het IP adres van je server krijgen, iets wat al openbaar was... erg hoor.

[Reactie gewijzigd door TechSupreme op 17 januari 2026 22:18]

[PacinoAllstars]

De meeste antwoorden heb ik al in andere reacties gegeven in dit draadje.

Over Mozilla’s rol ben je vermoedelijk niet op de hoogte, je benaderd het waarschijnlijk naar hun browser-marktaandeel (~3-4%) doet vermoeden.

Echter, Mozilla zit als volwaardig lid in het CA/Browser Forum en heeft daar een zware stem, samen met Apple, Google en Microsoft. Beslissingen over Baseline Requirements (zoals de certificaatverkorting) worden daar genomen, en Mozilla pusht actief mee via hun Bugzilla-tickets en publieke policy-discussies (zie mozilla.org/security of hun wiki). Ze zijn geen “big tech” in omzet, maar wel een gatekeeper omdat Firefox een van de vier grote root stores beheert.

Maar de echte extra macht komt via hun NSS-library (Network Security Services): een open-source crypto/TLS-library die standaard in bijna alle Linux-distributies zit (Debian, Ubuntu, Fedora, etc.) en gebruikt wordt door talloze tools zoals curl, wget, Apache, Postfix, OpenVPN, dus los van of iemand Firefox gebruikt. Veel non-browser software vertrouwt impliciet op Mozilla’s root store en policy.

Resultaat: Mozilla’s eisen (bijv. korte levensduur, DANE-support, of root-inclusion) raken het hele Linux-ecosysteem, niet alleen Firefox-gebruikers. Dat geeft ze disproportionele invloed in het CA/B Forum, terwijl hun browser-aandeel klein is.

Daarmee is het forum geen democratisch ding per gebruiker, maar per vendor en Mozilla’s library-adoptie maakt ze daarmee zwaargewicht. Precies waarom die shortening zo hard doorgedrukt wordt, met centralisatie tot gevolg.

En daarmee niet goed voor Europese soevereiniteit.

[TechSupreme]

Dit hele verhaal is een gigantische facepalm.

Nogmaals, wat is de relatie tussen Browser Forum en ETSI? En wat heeft dat alles met SSL te maken?

Wat is het probleem dat je publieke IP bekend is bij je CA als je een ACME tool gebruikt? Je CA hoort sowieso te weten wie jij bent en IP is sowieso publiek, dus wat is het probleem dat je CA weet wat jouw IP is?

Je hebt het over SSL en dan spring je ineens naar andere toepassingen en relateer je dat aan SSL. Besef jij wel dat SSL en PKI niet hetzelfde zijn?

En dan nog een veel leukere, je hebt het over vendor lockin en dan begin jezelf over dat al die tools worden beheerd door instanties die Open Source aan de kern hebben.

En dan heb je nog steeds niet antwoord gegeven waarom ik zo graag mijn CA beheerd wil hebben door een instantie op een ander continent? Ik begin me echt af te vragen of jij uberhaupt begrijpt waar jij het over hebt, pasages citeren kan iedereen en dan per ongeluk roepen dat Browser Forum effect heeft hardware oplossingen, hoe dan?

Via een library gemaakt door Mozilla en die voornamelijk door Mozilla producten wordt gebruikt? Besef jij wel dat meeste distro's de ca-certificates package gebruiken als hun hoofd certificate store? Niemand gebruikt NSS, Oracle niet, Apache niet, niemand!

[Reactie gewijzigd door TechSupreme op 17 januari 2026 23:34]

[PacinoAllstars]

Laten we even bij de basis beginnen, want het lijkt erop dat je een paar fundamentele dingen door elkaar haalt.

Eerst: “SSL” is al jaren een misplaatste term. SSL 3.0 is in 2015 deprecated (RFC 7568), en alles sindsdien is TLS (1.2, 1.3). Mensen (inclusief jij) zeggen nog “SSL-certificaat” uit gewoonte, maar technisch is het TLS. Het artikel gaat over TLS-certificaten. Klein detail, maar als je zo precies wilt doen…

Dan ETSI en CA/B Forum: het CA/Browser Forum stelt de Baseline Requirements op voor publiek vertrouwde TLS-servercertificaten, precies wat browsers (en root stores) eisen om een cert trusted te maken. Voor qualified certificates onder eIDAS (ETSI etc) vaak met hardware zoals QSCD’s/smartcards) gelden extra EU-regels voor hogere assurance. Maar guess what: zelfs eIDAS-qualified TSP’s moeten, als ze web-trust willen (dus in browsers trusted), voldoen aan de CA/B BR’s inclusief de shortening en automatiseringseisen. Anders kom je niet in de root stores van Apple/Google/Microsoft/Mozilla. Geen ETSI-browser bekend? Precies, daarom indirecte afhankelijkheid.

Auditors? Om in die root programs te komen (en te blijven) moet een CA jaarlijks geaudit worden via WebTrust for CAs (North American standaard) of ETSI EN 319 403 (EU-stuk). Die audits mogen alleen door geaccrediteerde auditors, en onder eIDAS valt de accreditatie onder nationale bodies die lid zijn van ACAB-C (Accreditation Body for Conformity Assessment Bodies Council). Maar de root inclusion policy? Die dicteert Mozilla (via NSS/ca-certificates sync in distro’s), Google, Apple oftewel allemaal CA/B-leden.

Kortom: Europa heeft mooie regels (eIDAS/ETSI), maar voor het open web blijven we vastzitten aan Amerikaanse gatekeepers en hun BR’s. Resultaat: shortening forceert ACME, metadata naar VS, centralisatie bij Let’s Encrypt (64% marktaandeel).

IP publiek? Ja, maar continue aanvraagpatronen naar één partij niet. Dat is het punt dat je blijft negeren.

[TechSupreme]

erst: “SSL” is al jaren een misplaatste term. SSL 3.0 is in 2015 deprecated (RFC 7568), en alles sindsdien is TLS (1.2, 1.3). Mensen (inclusief jij) zeggen nog “SSL-certificaat” uit gewoonte, maar technisch is het TLS. Het artikel gaat over TLS-certificaten. Klein detail, maar als je zo precies wilt doen…

Nee hoor, SSL is in de volksmond gewoon een noemer voor een beveiligde HTTP verbinding. Buiten dat alles, wat doet dit eraan toe? Wil je echt discussies gaan voeren over symantiek?

Dan ETSI en CA/B Forum: het CA/Browser Forum stelt de Baseline Requirements op voor publiek vertrouwde TLS-servercertificaten

Ja... voor internet devices, SSL zeg maar. Buiten dat... ook al zou dat zo zijn... het is allemaal vrijwillig...

Wat dat allemaal heeft te maken met hardware tokens is een gigantisch mysterie.

Geen ETSI-browser bekend? Precies, daarom indirecte afhankelijkheid.

Nogmaals, wat de relatie is van PKI tot een webbrowser is alweer een gigantisch mysterie. Ik zal het je nogmaals vertellen, SSL is niet hetzelfde als PKI.

De PKI Overheid certificaten zitten in geen een browser store, maar is wel gecertificeerd. Hoe dat kan is een gigantisch mysterie. Volgens jou logica zou de overheid hun documenten over een SSL verbinding sturen om ze te ondertekenen en dan gaan ze voor elk document een apart.... uuuh laat maar.

Ik zie het al gebeuren, eerst even een Whatsapp bericht sturen om zeker te zijn dat ze aan de andere kant klaar staan en dan komt je document er gesigneerd uit... Uuuuh... huh? Ja dat is wat jij claimt.

Ik wist niet dat mijn webbrowser documenten en code kan signeren... weer wat geleerd. Niet echt handig de manier waarop het werkt. Waarom Mozilla dit jaren verborgen heeft gehouden is alweer een mysterie.

Die dicteert Mozilla (via NSS/ca-certificates sync in distro’s), Google, Apple oftewel allemaal CA/B-leden.

ca-certificates wordt voplgens de laatste informatie die ik krijg gewoon apart beheerd van de NSS library. NSS is iets totaal anders. De beheerders zeggen dat ze voor het gemak Mozilla volgen, maar meer als dat is het niet. Als morgen de beheerder van ca-certificates zeggen dat ze het anders gaan doen dan gaan ze het anders doen.

Maar dan nog, hoe een Debian package privacy problemen kan veroorzaken is alweer een gigantisch mysterie.

IP publiek? Ja, maar continue aanvraagpatronen naar één partij niet. Dat is het punt dat je blijft negeren.

Dus server beheerders moeten om de 47 dagen een nieuw certificaat aanvragen en dat zou een aanvraagpatroon... wat? Ja sorry ik ben gewoon dom ik snap het allemaal niet, probeer het anders eens uit te leggen?

Volgens mij denk jij dat de client elke 47 dagen een certificaat aan moet vragen ofzo. Of denk jij dat root certificaten om de 47 dagen vernieuwd gaan worden? Wat je allemaal verteld is een gigantisch mysterie voor mij, ik ben geintrigreerd.

[Reactie gewijzigd door TechSupreme op 18 januari 2026 01:41]

[TechSupreme]

Nou, aangezien jij niet gaat zeggen wat het echte probleem is, mag ik ervan uitgaan dat je absoluut geen idee hebt waar je het over hebt. Dat een signing authority jouw gedrag kan volgen via OCSP is een privacyprobleem, maar zoals eerder gezegd wordt OCSP zowel door CA's als door browserbouwers afgeschaft.

Maar goed, tot op een bepaald niveau heeft CRL hetzelfde probleem.

Het probleem is ook niet dat de CA het IP-adres van de server krijgt te zien krijgt; dit is inherent, omdat ze moeten verifiëren wie je bent en of dat domein ook echt van jou is. Dit kan met ACME, met een domainkey (zoals het meestal gaat), of zoals ze het vroeger deden met proof of identity via de post. Als je gaat zeggen dat je CA het IP van je server krijgt te zien en dat dat een probleem is, dan heb je echt geen idee waar je het over hebt. Iedereen die jouw site bezoekt, krijgt je IP te zien. Ik hoef niet eens jouw site te bezoeken, een simpele DNS query en ik krijg alle IP adressen van je domein , je subdomeinen en alles wat met je domein te maken heeft te zien.

Het echte probleem van een CA beheerd door je lokale overheid is dat je lokale overheid al het verkeer kan decrypten.
https://www.computerworld...a-debates-punishment.html
Wikipedia: Kazakhstan man-in-the-middle attack

Daarom heb ik liever dat mijn CA wordt beheerd door minimaal 2 andere buitenlandse bedrijven, want je lokale overheid heeft meer belang bij het spioneren op zijn eigen burgers dan een buitenlandse overheid, net zoals een bedrijf belang heeft bij het spioneren op zijn werknemers. Een buitenlandse overheid zal eerder spioneren op grote bedrijven of andere overheden, maar zal niet snel spioneren op specifieke burgers.

Dus je hele verhaal, leuk en aardig, maar er klopt gewoon geen zak van en je benoemt niet eens het echt probleem.

[Reactie gewijzigd door TechSupreme op 19 januari 2026 09:56]

[mobrockers]

[...]

Wist jij dat vuuger het beleid was om server certificaten te versturen via sneaker net? Het RDW doet dat nog steeds. Daar is een reden voor!

Dat is een beleid tbv een uitzondering. Primair beleid in fatsoenlijke organisaties is dat private keys niet gedeeld worden. Ongeacht overdrachtsmedium. Servers krijgen hun eigen server certificaten, maken zelf de csr aan. Geen enkele reden om private keys rond te sturen, zelfs niet via sneaker net.

[TechSupreme]

Leuk verhaal, maar wat dacht je van onderschepping?

[mobrockers]

Onderscheppen van...? Je deelt nooit private key materiaal, er wordt niks verstuurd, er wordt niks onderschept..?

[TechSupreme]

intransit...

[Lucas]

OCSP was inderdaad een privacy risico (tenzij gebruik gemaakt werd van OCSP stapling, maar dat was niet heel populair), daarom hebben ze support voor OCSP vorig jaar al stopgezet: https://letsencrypt.org/2024/12/05/ending-ocsp .

Het kunnen inzien welk IP-adres een certificaat heeft aangevraagd vind ik minder relevant, in een groot deel van de gevallen bestaat deze link immers al via DNS.

[demianmonteverd]

Er waren zat partijen in NL die OSCP stapling deden. Misschien was het niet populair bij de commerciele loadbalancers en mensen die hobby-matig aan de slag zijn en er misschien nog niet van gehoord hadden?

[VHware]

Er is o.a. Certum als Europese CA. Ondersteund ook het ACME-protocol
https://support.certum.eu...l-certificate-using-acme/
Het zijn alleen geen gratis certificaten zoals bij Let’s Encrypt.

Eerder was er een Noorse CA (BuyPass) met gratis certificaten, maar die is gestopt.

Actalis (Italiaanse CA) heeft wel ACME SSL met gratis certificaten:
https://www.actalis.com/n...r-acme-based-web-security

[Reactie gewijzigd door VHware op 16 januari 2026 22:52]

[Omega]

Ik ben zeker een voorstander van een Europees LetsEncrypt alternatief. Toch wil ik vermelden dat LetsEncrypt wordt gezien als een van de meest open en betrouwbare certificaat providers, de VS zou zeker dingen kunnen afwringen, al kan ik mij niet voorstellen dat LetsEncrypt hier makkelijk in mee zal gaan, en een hele hoop lawaai gaat maken mocht dit worden afgedwongen.

[Jerie]

Er is een Italiaans alternatief: Actalis SSL, hosting door Aruba Cloud. Beide Italiaans.

Zie: https://european-alternatives.eu/alternative-to/lets-encrypt

[maevian]

Gebruik dan gewoom zeroSSL? Dat is gevestigd in Oostenrijk.

[Giga_]

Tjah voor Let's Encrypt was het nog slechter gesteld met de digitale veiligheid. De tijd van DigiNotar? Verlopende certificaten. EV certificaten die echt 0 meerwaarde hadden want 95% van de bevolking snapt uberhaupt niet meer van het principe dan het heeft 'wel een slotje' of 'geen slotje'. En als ik naar mijn ouders kijk; zelfs dat snappen ze niet... SSL is door Let's Encrypt zo ontzettend toegankelijk geworden en heeft de extreme kosten die er op een gegeven moment werden gevraagd, zeker in de b2b hosting industrie extreem verlaagd.

Nu nog een Europese variant...

[asing]

Let's Encrypt is leuk voor de thuisgebruiker en MKB. Gratis en makkelijk. Er zijn alleen geen garanties. Wil je meer bescherming voor je data met meer garanties, dan kan je via elke willekeurige reseller een SSL certificaat kopen. Digicert geeft je bijvoorbeeld een groene address bar en tot 1.7 miljoen dollar compensatie als er misbruik wordt gemaakt. Ook heb je een helpdesk. Kost wel wat, bijna 1000 dollar.

Dan zijn er 2 vragen : hebben we op Europees grondgebied een SSL dienstverlener die dezelfde garanties biedt en hebben we er eentje (of dezelfde) die een vervanger kan zijn voor Let's Encrypt? Ik heb niet gezocht naar een antwoord moet ik je vertellen. Veel van die SSL dienstverleners zijn Amerikanen en Europese dienstverleners kunnen uiteraard ook worden gekocht.

Wil de EU zoiets goed doen, dan moet dit vanuit de EU geregeld worden in een vorm die niet te koop is. Pas dan kan je de garantie geven dat het ook zo blijft.

[maevian]

ZeroSSL is EU tegenhanger vam let's encrypt. In caddy is die de standaard voor DNS verificatie.

[Clueless]

ZeroSSL is eigendom van HID Global sinds 2024 en daardoor onderhevig aan de CLOUD Act helaas.

Zie ook: https://newsroom.hidglobal.com/hid-enhances-its-pki-offerings-acquisition-trusted-certificate-service-provider-zerossl

[TechSupreme]

Is EV SSL nog steeds een ding dan? Ik weet het niet zeker, maar volgens mij laten meeste browsers die groene adresbalk niet eens zien tegenwoordig. Het was een tijdje een rage, maar het is absoluut niet veiliger. Het was bedoeld om betrouwbaarder over tekomen bij klanten omdat je als bedrijf door een betrouwbare instantie geverifieerd werd en dus de klant wist wie jij bent.

Maar goed hoe betrouwbaar dat is. Richt een bedrijf op een bedrijven verzamelterein of vind een kattenvanger wiens huisadres je mag gebruiken bij het KvK en je kan even goed zo'n EV SSL certificaat krijgen.

Het is een wassenneus en daarom is het ook even snel verdwenen als het verscheen. Ga de straat op en vraag 10 willekeurige mensen over die groene balk, geen van hun weet dat het bestaat.

Als je wil suggereren dat een LE certificaat minder veilig is als welk ander certificaat dan is dat simpelweg onzin. Welke bescherming en garanties we het over hebben is mij daarom ook niet duidelijk.

Het verschil tussen LE en de rest is heel makkelijk. LE wil zoveel mogelijk websites aan de SSL hebben, dat is hun missie. Bij hun kan je terecht voor je domain en zelfs multidomain certificaten.

Geen wildcards, geen extension, geen atributes, geen EV SSL, geen code signing, geen S/MIME, geen DocuSign.

En inderdaad, het is alleen CertBot en jij, maar je hebt wel een gigantisch community waar je informatie uit kan halen, dus is die helpdesk echt nodig?

[Blokker_1999]

Welke bescherming zou je meer willen of kunnen krijgen met een betaald certificaat? De encryptie op die certificaten is namelijk identiek.

De groene adresbalk bestaat al jaren niet meer. En die 1.7 miljoen was vooral een PR slogan. Als jij je private key uitlekte, dan betaalden zij daar niet voor. De grap is natuurlijk dat de private key enkel aan jouw kant bekend is.

En als je een helpdesk nodig hebt, dan gaat er wat mij betreft toch iets mis met wat in essentie zo eenvoudig hoort te zijn dat je zelfs een 1st line medewerker het werk kunt laten doen.

En ik snap echt de drang niet om telkens als iemand iets zegt over de afhankelijkheid van Amerikaanse bedrijven dat er dan direct mensen zeggen dat de EU, de overheid, het zou moeten regelen. Waarom toch? Je bent net bang van de Amerikaanse overheid en wil net niet die overheidsbemoeienis om dan te zeggen dat de EU het moet regelen? Neen, laat het over aan de vrije markt.

[asing]

Kennelijk zit er toch nog iets aan zo'n betaald certificaat vast. Misschien niet tastbaar maar bedrijven betalen nog steeds voor een certificaat terwijl dat met LE eigenlijk niet meer nodig is. Paar voorbeeldjes:

• Tweakers : DigiCert
• Rabobank : Sectigo
• Amsterdam : DigiCert
• Belastingdienst : DigiCert

De reden waarom ik zeg dat de EU dit beter kan regelen is omdat dat zo ongeveer de enige garantie is dat een dienst niet opgekocht wordt door een Amerikaans bedrijf. Dat gebeurt nu te weinig, waardoor bijvoorbeeld de dienstverlener van DigId is opgekocht. Het is wel zoiets van "of je nou door de hond of de kat gebeten wordt..." want overheid en ICT is ook geen gelukkige combinatie.

[deadinspace]

Let's Encrypt is leuk voor de thuisgebruiker en MKB. Gratis en makkelijk. Er zijn alleen geen garanties. Wil je meer bescherming voor je data met meer garanties, dan kan je via elke willekeurige reseller een SSL certificaat kopen.

Ohjee, er heeft weer iemand naar de marketingpraatjes van Digicert geluisterd

Digicert geeft je bijvoorbeeld een groene address bar

Cool! Hoe doen ze dat als browsers dat al 6 jaar niet meer ondersteunen?

en tot 1.7 miljoen dollar compensatie als er misbruik wordt gemaakt.

Ahja, de bekende 1+ miljoen SSL garanties. Die nog nooit uitgekeerd zijn, omdat ze 1) zaken dekken die onmogelijk zijn 2) in hun voorwaarde vrijwel al het andere uitsluiten en 3) als een CA het daadwerkelijk genoeg verneukt dat die garantie in de picture komt dan wordt hun CA status ingetrokken en is die toko failliet.

Als voorbeeld van het eerste, veel van dat soort garanties dekken het uitlekken van de aanvrager's private key door de CA. Maar de private key van de aanvrager komt nooit bij de CA terecht (dat is hoe certificaten werken), dus dan kan de CA die ook niet uitlekken. Dat is een beetje als een reisverzekering afsluiten op je huis.

Voor meer leesvoer: hier heeft iemand uitgebreider geschreven over die zogenaamde warranties, inclusief een duik in de voorwaarden. De moeite waard als je om dat soort dingen geeft.

Ook heb je een helpdesk. Kost wel wat, bijna 1000 dollar.

True, maar in de praktijk heb je daar weinig aan in mijn ervaring. Zeker niet genoeg om $1000 te rechtvaardigen.

[Qlimaxxx]

Is sinds 2021 niet de default CA van acme.sh gewijzigd naar ZeroSSL? Volgens mij is dat een Oostenrijks alternatief voor Let’s Encrypt.

[striper]

Helaas, die lijken overgenomen te zijn door HID, wat in Texas z'n hoofdkwartier heeft HID is weer onderdeel van Assa Abloy, wat een Zweeds bedrijf is. Snap jij het nog?

[maevian]

Dan is het toch eerder Zweeds als Amerikaans

[striper]

Ja, dat zou je zeggen, maar het is de vraag of ZeroSSL daarmee buiten de US Cloud Act valt.

Daarbij komt: Bij ZeroSSL krijg je maar 3 certificaten voor niets (geen wildcard); daarna betaal je minimaal 10 euro per maand.

[maevian]

Zero SSL heeft juist geen limiet als je ACME gebruikt, in tegenstelling tot de limiet van 50 bij let’s encrypt.

https://help.zerossl.com/hc/en-us/articles/17864245480093-Advantages-over-Using-Let-s-Encrypt

Hoofdzetel is in Oostenrijk dus vallen niet onder de cloud act

[striper]

Vreemd, op hun pricing pagina staat toch echt slechts 3 certificaten onder "Free".

edit:
Het lijkt erop dat je toch gelijk hebt. Die limiet van 3 geldt niet voor ACME certs. Vreemde marketing.

https://zerossl.com/documentation/acme/

[Reactie gewijzigd door striper op 17 januari 2026 10:55]

[Blokker_1999]

Heel dat betoog, maar je hebt blijkbaar nooit geleerd waarom Let's Encrypt de levensduur van certificaten aan het verkorten is, of waarom de browser makers lang levende certificaten niet langer willen ondersteunen (nog max. 47 dagen in 2029).

Al heel veel jaren doen web browsers namelijk geen enkele controle op het al dan niet ingetrokken zijn van een certificaat. Zij kijken enkel naar de certificate chain en of het root certificaat vertrouwd wordt. Is dat allemaal in orde en is het certificaat nog in zijn geldigheidsperiode? Dan wordt het certificaat gewoon vertrouwd.

Het enige wat LE kan loggen is de server die het certificaat heeft aangevraagd. En dat IP adres moet net bekend zijn, want men moet een validatie kunnen uitvoeren of de aanvrager wel die server is. Dus als jij bezorgd bent dat de Amerikaanse overheid kan zien op welke server een website draait, dan heb ik een nieuwe 3-letter afkorting voor je om eens op te zoeken: DNS. Een hele bibliotheek die openbaar opvraagbaar is en waar al die informatie reeds in staat.

[PacinoAllstars]

Het dwingt massale ACME-automatisering af. Elke 47 dagen een nieuw cert aanvragen betekent continue, geautomatiseerde verbindingen naar Amerikaanse servers. Niet alleen het initiële IP (ja, publiek via DNS), maar ook patronen, timing en volume van aanvragen lekker centrale metadata bij één dominante Amerikaanse CA.

En ja, DNS maakt domein-IP-koppeling publiek, maar niet de aanvraagstromen naar één specifieke partij die onder CLOUD Act valt. Met 64% marktaandeel heb je een perfecte kill switch: één NSL en massa-intrekking of service-onderbreking, en half Europa’s web ligt plat.

Kortere levensduur is een security-win, maar in dit geval tegen een prijs: namelijk nog meer VS-centralisatie. Daarom zeg ik, tijd voor een Europese tegenhanger.

[macaidwin]

Zouden ze ook in 1 klap certificaten van bijv. NL domeinen of van Europese bedrijven ongeldig kunnen maken? Europese aanvragen door een aan eu toegewezen root laten ondertekenen en die uitschakelen? Wel een risico als je er zo over nadenkt.

[PacinoAllstars]

dat is precies het kill-switch-risico.

Selectief “.nl” intrekken is technisch lastig (geen TLD-filter), maar er zijn wel bredere opties:

• Massa-intrekking van intermediates/CRL’s onder CLOUD Act-druk → waarschuwingen en problemen bij strenge clients.
• Root distrust door browser vendors (Apple/Google/etc.) → alle LE-certs wereldwijd meteen ontrusted (zoals bij Symantec vroeger).

Met 64% marktaandeel LE raakt dat vooral Europa hard, want er is geen schaalbare EU-root voor gratis DV-certs, dus geen echt alternatief.

[CaptainKansloos]

Elke keer dat een Europese server een certificaat aanvraagt via ACME of een OCSP-check doet voor revocation status, gaat dat verkeer naar servers die onder Amerikaanse jurisdictie vallen.

Zelfs als het verkeer zelf versleuteld is en de inhoud niet gelezen kan worden, zien zij wel:

welk IP-adres het verzoek doet

voor welk domein het certificaat aangevraagd wordt

eventuele patronen in aanvragen

OCSP wordt / is voor een belangrijk deel al uitgefaseerd. Zie ook hier. Bovendien moest OCSP stapling die problemen die je opsomt al oplossen.

Het 'probleem' voor ACME bestaat nog steeds, maar dat komt omdat de endpoint zelf nou eenmaal de aanvraag moet doen. Jouw paspoort moet je ook zelf aanvragen, dat kun je niet zomaar uitbesteden.

Op zich heb je wel een valide punt in dat het mooi zou zijn als er een quasi souverein Europees alternatief zou komen voor Let's Encrypt.

[Reactie gewijzigd door CaptainKansloos op 17 januari 2026 09:30]

[maevian]

Dat is er al lang met zeroSSL

[VriendP2]

Ik denk niet dat we Europa (de EU) automatisch moeten vertrouwen met dat soort gegevens. De EU heeft namelijk ook wat autoritaire trekjes gekregen de laatste jaren, zoals een vliegverbod, blokkeren van Russische nieuwssites, MICA wetgeving rondom crypto en dat soort dingen. Laten we het over de retoriek dan nog maar niet hebben. Het lijkt erop dat de EU zichzelf ziet als een soort superstaat en dat is in combinatie met het gedachtengoed eerlijk gezegd nogal eng, maar ik dwaal af.

Uiteindelijk is een Certificate Authority een autoriteit en daar horen regels bij. Fatsoensregels, wettelijke beperkingen en transparantie waar nodig. Dat wordt in de EU ook lastig. De vraag is volgens mij meer wie we dan wel vertrouwen en als we daar intelligent in willen zijn dan is het antwoord eenvoudig: niemand.

[demianmonteverd]

De EU is niet perfect, maar om nu te klagen dat men 'Russische nieuwssites' blokkeert gaat m.i. echt veel te ver. Je hebt het over media die vooral mis- en desinformatie verspreiden (betaald en bestuurd door de regering in Moskou) en elke week wel een keer dreigen met gebruik van kernwapens wapens richting het EU-lid van de dag. Rotterdam is een populaire bij ze trouwens. Overigens, je kunt die zenders nog steeds kijken op youtube, met handige vertaling, zodat je niet alleen maar de plaatsnaam hoort die ze bedreigen, maar ook waarmee ze dreigen, makkelijk te lezen in de ondertiteling. Je mist er echt niets aan. Tenzij je van de ironie en morbide absurde humor bent, in dat geval, ga het vooral kijken, dan is het een aanrader.

Maar goed inhoudelijk, er is niet zo veel op tegen om eigen certs te kunnen uitgeven. Je hebt er nog niet zo heel veel aan aangezien we massaal de goedgekeurde CA's vanuit de OS'en krijgen of vanuit de browsers, die verrassing ook uit de VS komen. Maar goed, het is een valide punt dat onze massale afhankelijkheid van bijv. Let's Encrypt niet ideaal is.

[Triblade_8472]

Daarom gaat OSCP er ook uit. Veel stoppen er al mee.

Een CRL is ook wel beperkt, maar daar staat vaak genoeg in om niks te achterhalen.

Het enge van Amerikaanse CA's is dat ze toegang hebben tot de root waarmee een MitM makkelijk mogelijk is.

[Guru Evi]

TLS certificaten en de logs van aanvragen en de chains zijn publiek beschikbaar, dat heet certificate transparency. Natuurlijk weet je waar de aanvraag vandaan komt, het komt van de webserver van een publiek web adres en de logs van je aanvraag zijn publiek beschikbaar. Security through obscurity is geen model dat je mag gebruiken.

De private keys kunnen niet gestolen worden gelijk welke regering, ze zitten opgesloten in een hardware module. Eenmaal zo’n systeem voelt dat ze gecompromitteerd worden, worden de sleutels gewist. Dit systeem is gebouwd door een Frans defensieconglomeraat (Thales), als enige achterdeurtjes erin staan komen ze van de EU.

Een regering kan LE niet forceren valse certificaten te maken, bewijs hiervan wordt automatisch publiek, en het is gemakkelijk te controleren zou een LE certificaat niet in die logs staan.

LE doet Domain Validation, je kan TLS sowieso niet gebruiken als een identiteitsbewijs van de website. Als jij g00gle.com registreert, kun je daar een TLS certificaat voor maken. Het belang van een TLS certificaat is om het verkeer tussen twee partijen te versleutelen, niet om te bewijzen wie de partijen zijn, het belang van een TLS certificaat in een overheidsactie is nihil.

Daarnaast doe LE enkel maar aan het tekenen, overheden hebben hun eigen tekensystemen, als een overheid een vals certificaat wilt maken kunnen ze dit doen zonder LE, zoals China doet en waarom de root “Staat der Nederlanden” niet langer vertrouwd wordt door de browsers, indien je nog denkt dat als de EU dit doet het beter zou zijn, de EU heeft al zijn aandeel aan farces gehad op dat gebied.

[Reactie gewijzigd door Guru Evi op 17 januari 2026 14:45]

[lenwar]

Je verhaal klopt helemaal, maar op het ‘welk ip-adres de aanvraag doet’ na, is de rest al publiek. Er zijn certificate transparancy logs, waar LE (en volgens mij alle andere CA’s?) naar publiceren. De eigenaren van domeinen zijn in principe ook al publiek.

https://crt.sh/?q=Tweakers.net
https://www.whois.com/whois/tweakers.net

En geloof maar dat als de overheid veiligheidsdiensten van een land om meer contactinformatie vragen dat ze dat gewoon doen.

Die transparantie is juist een kracht van ‘het systeem’. Zo kan iedereen zien welke certificaten er zijn, en door welke CA ze zijn aangemaakt, om eventuele malafide certificaten makkelijker te detecteren zijn.

[FurriousFox]

Deze certificaten die 160 uur geldig zijn, zijn overigens voornamelijk bedoeld voor IP-certificaten (dat je een SSL certificaat kan krijgen voor https://1.1.1.1 bijvoorbeeld), dat is de hele reden waarom let's encrypt dit heeft uitgebracht. Omdat ip adressen vaak geleased worden en regelmatig van eigenaar veranderen (wat normaalgesproken niet gebeurt met domeinen) is deze kortere 160 uur geldigheid nodig.

[Uberprutser]

Elke 72 uur een nieuwe, werkt prima. Mochten ze een storing hebben heb je nog 3 dagen om te vernieuwen.

[MagicAndWires]

Het steeds opnieuw aanmaken van zoveel certificaten zal wel meer rekenkracht vereisen dus ik neem aan dat ze het daarom op 6 dagen houden.

[Noxious]

LetsEncrypt maakt voor de duidelijkheid het sleutelpaar niet.

Je maakt zelf het complete sleutelpaar (private key + public key); de public key en bijbehorende metadata gaan in een PKCS #10 formaat naar LetsEncrypt toe als CSR (Certificate Signing Request).

Na de verificatie (bijv. HTTP-01 challenge) stopt LetsEncrypt dit in een X.509 jasje en deze ondertekenen ze met hun issuing key, en sturen een X.509 certificaat terug. De 'ingewikkelde' wiskunde van het genereren is dus helemaal lokaal, LetsEncrypt krijgt nooit je private key - ze controleren en ondertekenen enkel.

[MagicAndWires]

Dat de privésleutel van de gebruiker er niet bij aan te pas komt wist ik maar ik dacht dat het ondertekenen van een sleutel ook rekenkracht vereiste. Weer wat geleerd.

[Uberprutser]

Meer dat je zelf elke 72 uur je certificaten vernieuwd en ruimte houdt voor failure aan hun kant.

[striper]

Ik denk eerder aan failure aan je eigen kant

Let's Encrypt beheerde vorig jaar 550 miljoen certificaten. Met een levensduur van 3 dagen betekent dat dat ze meer dan 2100 certificaten per seconde moeten kunnen ondertekenen. Ieder uur downtime levert 7.6 miljoen gedupeerde domeinen op. Maw, failure aan Let's Encrypt zijde is niet de reden van die drie dagen. Het is waarschijnlijk opgelegd door limieten aan het aantal certificaten dat ze kunnen ondertekenen en domeinen die ze kunnen verifiëren per tijdseenheid.

[GertMenkel]

Het maken van zo'n certificaat is niet heel veel zwaarder dan het gebruiken van zo'n certificaat.

Genoeg entropie behouden om veilig willekeurige nummers te genereren kost ook tijd, maar dat kost ook niet zo lang dat je er nou heel veel aan kwijt bent (tenzij je hele zware versies van RSA gebruikt zonder hardwareversnelling, dan is het grootschalig verzamelen van entropie een uitdaging).

[MoonRaven]

Een reverse proxy zal dit kunnen doen en dit kost echt niet veel rekenkracht.

[Blokker_1999]

Het zal maar net een lang weekend zijn ... . Een week is al vrij kort, korter moet echt niet. En ik ben dan ook meer dan tevreden dat het CA/B de limiet die ze in 2029 opleggen gehouden heeft op 1,5 maand.

[kevinkrs]

niet gemeen bedoeld naar als een gemiddelde certificaat 1 maand tot een jaar geldig is, waarom zou ee certificaat van 6 dagen en 16 uur moeten boeien precies?

[SiGNe]

Zoals in het artikel staat heeft een kwaadwillende partij dan minder tijd om een certificaat te faken.
Doordat er elke 6 dagen een nieuw certificaat is moeten ze dan meer moeite doen.

[fastedje]

Alleen wordt er voor zover ik weet nooit gecontroleerd of je wel een nieuwe public key gebruikt. Dat is alsof je sloten en sleutels elle dag vervangt door sloten met exact dezelfde code.

[SiGNe]

Ik gebruik zelf Certify om mijn keys te vernieuwen, die gebruikt ook elke keer een nieuwe public key.
Heb er verder geen omkijken meer naar

[-Vasa-]

De huidige mindset is dat certificaten op zich niet te betrouwen zijn, en dat het vertrouwen dat je er in kan hebben daalt hoe langer geleden ze uitgegeven zijn. Dit zorgt er ook voor dat vanaf volgend jaar certificaten die een jaar geldig zijn, en via een commcerciële CA zijn uitgegeven, slechts 47 dagen zullen geldig zijn, dit om beheerders aan te moedigen hun certificaten renewal te automatiseren.

Op zich een zeer leuk idee, maar praktisch voor beheerders een heleboel werk afhankelijk van hoe je flow er momenteel uitziet. Vooral omdat als ik onze tussenpartij waar wij wij onze certs halen en waar we dus onze facturen mee regelen vraag hoe we dit naar hen toe moeten automatiseren, en zij dus het zelf nog niet weten. En het is niet alsof dit een kleine speler is, ik ga hun naam nu niet noemen maar ze zitten in de top 5 van de spelers hierover in de Benelux.
En dat is dan nog maar simpelweg de automatisering an sich, laat staan hoe je dit gaat moeten verwezelijken met wildcard certs die je net nodig hebt omdat je ze moet kunnen gebruiken op meerdere servers voor verschillende onderdelen waarbij er constant nieuwe namen bijkomen die je op geen enkel moment kunt voorspellen.

Mijn inschatting tot nu is dus dat het voor meer fouten gaat zorgen op publiek beschikbare websites en dus ook gaat zorgen dat men mensen weer gaat aanleren dat het ok is die waarschuwingen van je browser te negeren, en dus het tegenovergestelde effect gaat hebben dan dat men zegt te willen bereiken.
En dan komt mijn cynische kant naar boven en denk ik dat dat daar dus niets mee te maken had, maar dat het eerder is om te zorgen dat zinvolle, kostenefficiënte oplossingen zoals wildcard certs uitgefaseerd worden en je als bedrijf plots duizenden afzonderlijke certs gaat moeten aanvragen en betalen.

Ongetwijfeld dat men daarover dan ook zegt dat een wildcard cert onveilig is omdat als één server of (sub)domein gecompromiteerd is, ze dat allemaal zijn, maar dat gaat er al van uit dat je maar één specifiek cert per server gebruikt. Met duizende specifieke certs op één server zijn die evengoed allemaal gecompromiteerd als je server dat is. En daar helpt de kortere renewal tijd ook niet tegen aangezien je op die server dus je mechanismen moet instellen om automatisch te renewen wat blijft werken tijdens de tijd dat je gecompromiteerd bent zonder het te weten. En in die zijn blijft dan nog steeds een cert revocation nodig en doet die kortere renewal tijd vrijwel niets zinvol.

[Reactie gewijzigd door -Vasa- op 19 januari 2026 08:28]

[DarkWoesel]

Wat heeft een gemiddelde tweaker hier aan? Ben helaas niet meer te tweakeroid hiervoor....

[Boudewijn]

Relatief weinig; als je certificaat gecompromitteerd raakt kan een kwaadwillende gedurende 160 uur (maximaal, ervanuitgaande dat hij direct na compromittatie aan de slag kan) nare dingen doen.


Wat kan ermee?

- Je voordoen als een andere site als je een man-in-the-middle-aanval doet

- Verkeer ontsleutelen als je kunt tappen.

- Ongetwijfeld ook allerlei dingen met digitale handtekeningen van documenten en dergelijke

[FreezeXJ]

Ik ben dan vooral bang dat als er 1 cert compromised is dat de volgende dat ook wel eens kan zijn. Het hele proces is geautomatiseerd als het goed is, dus het is niet dat iemand per ongeluk een private key meestuurt met z'n certificaatje ofzo. Dan is misschien het probleem minder lang nog actief nadat het lek boven is, maar als ik zo de aanvallen zie, is detectie soms weken/maanden na de breuk.

[Boudewijn]

Tsja als je erachter komt dat je server gepwned is dan mag je idd je certificaten vervangen. Het vervelende aan een passieve aanval, zoals een tap-met-ontsleuteling is dat je het niet merkt

[RobbieB]

Zei er iemand DigiNotar?

[Gr4mpyC3t]

Veel Tweakers werken overdag op een IT-afdeling waar ze omgevingen beheren. Best handig om te weten dat Let's Encrypt met deze functionaliteit komt.

Daarnaast wordt er 's avonds thuis geknutseld met servers, een NAS of eigen services achter een reverse proxy. Ook daar is Let's Encrypt dan goud waard, juist omdat je gratis en met ACME gemakkelijk certificaten kunt uitrollen en vernieuwen.

Wie dan toch al ervaring heeft met het automatiseren van Let's Encrypt is het een simpele aanpassing in de code.

[HollowGamer]

Zo simpel vind ik het niet, ondanks dat ik al jaren met LE werk.

Je hebt er namelijk rate-limits opzitten, dus als je gaat 'experimenteren' dan heb je zomaar dat je site 24 uur (of langer) eruit ligt, omdat je te veel mislukte requests hebt gedaan.

De enige goede manier zijn wrappers/proxies gebruiken. Caddy (inclusief DNS module) heeft zoiets al standaard bijvoorbeeld, echt zelf aan de slag gaan raad ik echt af (tenzij je echt weet wat je doet). Beste is ook dat je meteen een wildcard certificaat neemt, en niet achteraf. De meeste willen dat wel geloof ik.

Een reverse certificaat lokaal heeft ook nadelen. Als je iets hebt als home.mijndomain.ext, dan kan je iemand zijn prive IP-adres achterhalen door er gewoon naar te pingen. Het zal vast beter kunnen, maar de meeste doen dit, zonder zich af te vragen of het wel zo veilig is.

[Reactie gewijzigd door HollowGamer op 16 januari 2026 21:46]

[Gr4mpyC3t]

Ben het met je eens dat de gemiddelde gebruiker beter een dienst/service kan gebruiken waar Let's Encrypt onersteuning in zit, maar een beetje tweaker pakt inderdaad de staging CA zoals @Lucas zegt of neem de optie die @GertMenkel aandraagt (die ik overigens nog niet kende).

En ik weet niet of ik het eens ben met je opmerking over een wildcard. Volgens mij is het tegenwoordig best practice om dit niet te doen, omdat je juist een SSL-cert in leven houdt dat bij misbruik op zo'n beetje op ieder willekeurig subdomein geplakt kan worden. Dat kon vroeger misschien vanuit praktisch/financieel perspectief, maar is tegenwoordig niet echt een argument meer.

[RobertMe]

En ik weet niet of ik het eens ben met je opmerking over een wildcard. Volgens mij is het tegenwoordig best practice om dit niet te doen, omdat je juist een SSL-cert in leven houdt dat bij misbruik op zo'n beetje op ieder willekeurig subdomein geplakt kan worden. Dat kon vroeger misschien vanuit praktisch/financieel perspectief, maar is tegenwoordig niet echt een argument meer.

An zich een valide punt dat een wildcard bij lekken dus ook op alle subdomeinen kan.
Maar, er is ook een keerzeide aan de domein specifieke certificaten: certificate transparency logs. CAs moeten publiceren welke certificaten er zijn aangevraagd. Hiermee lekken dus meteen al je domeinnamen uit, ook als die (in principe) alleen voor intern gebruik zijn. Je mist dan dus een "security through obscurity" deel.

Zie bv hier voor Tweakers(.net): https://crt.sh/?q=tweakers.net (die blijkbaar ook een wildcard gebruiken ).

[Gr4mpyC3t]

Als het toch voor intern gebruik is, wat maakt het dan uit dat je subdomeinen bekend zijn? Een domeinnaam is niet per definitie een gevoelig gegeven en dat publieke IP wat aan je hoofddomein hangt heeft de gehele wereld ook al 1000x gepold.

En als het echt zo geheim moet, zou ik altijd voor een interne Certificate Authority kiezen of self-signed certs afzonderlijk vertrouwen.

[RobertMe]

Een domeinnaam is niet per definitie een gevoelig gegeven en dat publieke IP wat aan je hoofddomein hangt heeft de gehele wereld ook al 1000x gepold.

Maar met dat IP adres kom je nergens. Of nouja, je komt op een reverse proxy uit. Maar zonder de juiste domeinnaam te weten zal die reverse proxy een "fout" geven (404/...) i.p.v. zomaar een van de services "afleveren".

En als het echt zo geheim moet, zou ik altijd voor een interne Certificate Authority kiezen of self-signed certs afzonderlijk vertrouwen.

An zich een valide punt, maar iets als StepCA opzetten is ook meer werk en voegt complexiteit toe. En dan is het nog afhankelijk van hoe "intern" zaken zijn. Ik heb ook een VPS draaien met wat zaken voor mij en familie. Daarvan hoeven de (sub)domeinen w.m.b. niet publiekelijk bekend te zijn. Maar als ik er een eigen CA tegenaan gooi zou ik ook moeten zorgen dat dat root certificaat vertrouwd wordt door (alle) apparaten van die familieleden. Voegt ook weer complexiteit / extra werk toe. Gebruik maken van een CA die uberhaupt al door alle apparaten vertrouwd wordt is dan een stuk makkelijker.

[Gr4mpyC3t]

Uiteraard ben ik het ook met je eens dat het niet bekend hoeft te zijn wat er allemaal in gebruik is op die VPS, maar als het achter een reverse proxy zit, dan is die proxy toch de plek om het verkeer op een veilige manier af te handelen?​

Als je iets aan het internet hangt, dan weet je gewoon dat er binnen een paar minuten poortscans op je afgevuurd worden. Security by obscurity is een slechte raadgever en geen volwaardige maatregel in het zakje van beveiligingsmaatregelen. Ze pakken eerder een zero-day in je reverse proxy om in je netwerk te komen, maar dan heb je tenminste nog je SSL-certs verhuld.

[maevian]

Voor lokale ssl certs gebruik ik dns verification met cloudflare plugin, als je liever Europees blijft kan je ook OVH plug-in gebruiken. OVH is trouwens een leuke registrar voor je homelab, hun .ovh tld is spotgoedkoop.

[HollowGamer]

Dan kan zeker iets uitmaken. Je wilt niet al die subdomains exposen, laat een gebruiker (of bot) maar moeite doen daar achter te komen.

Ik zou dus wel altijd kiezen voor een wildcard setup, je geeft niets prijs. Ook dat veel tutorials dus home.example.com aanraden, zou ik ook niet zo snel doen. Niet alleen wat ik zei dat je direct een portaal hebt naar je eigen huis/VPN/proxy, maar ook dat je een te lange naam kan krijgen voor de browser (langenaam.home.example.com kan voor issues zorgen). Beter is dan echt een eigen domein kopen puur voor verbinding naar een prive omgeving.

[Lucas]

Als je wil experimenteren kan je dat beter doen met de staging CA: https://letsencrypt.org/docs/staging-environment/, deze heeft veel minder strenge rate limits.

[GertMenkel]

Mocht de stagingomgeving van Let's Encrypt niet genoeg zijn, dan kun je Caddy instellen om zelf een ACME-server te zijn. 17 regels config voor de ACME-server (waarvan de meeste accolades zijn) en vier extra regels config aan de HTTPS-serverkant en je kunt met je eigen CA oneindige pogingen uitvoeren voor je je spul aan het publieke CA-systeem hangt.

Of je importeert je eigen certificaat op je computer en gebruikt je eigen TLS-infrastructuur, dat kan natuurlijk ook.

[HollowGamer]

Klopt, alleen is dit iets dat je moet instellen en ook kennis van moet hebben.

Ik werk met LE echt als leek. Daarom gebruik ik ook zoveel mogelijk wrappers of tools die er zijn zonder certbot of acme.sh aan te raken (beide gehad, en allebei niet leuk bij issues).

Wat @GertMenkel aangeeft is zeker interessant. Dat vind ik ook veel beter, dan met allemaal scripts die mogelijk nog meer openzetten op filesystem niveau (door je eigen schuld, maar zie het uit de ogen van een leek).

Soms zou ik hopen dat het echt veel eenvoudiger kon. Niet allemaal gedoe met plugins en hopen dat je het goed hebt ingesteld.

[lenwar]

Je maakt wel aannames met wat ‘veel mensen’ doen? Waar zijn die op gebaseerd?

De documentatie van LE is prima en de voorgestelde tools doen het ook prima. (Certbot en acme.sh).

Ik weet even niet wat je bedoelt met een reverse certificate? Als je een certificaat bedoelt voor een reverse proxy, dan zie ik geen probleem dat iemand je netwerkadres(sen) kent. Je hebt tenslotte die reverse proxy? (Daar heb je hem voor, toch?)

Gezien je een flink aantal certificaten met ASN’s kunt krijgen, zou ik persoonlijk ook niet weten, waarom je een wildcard-certificaat zou willen, anders dan laksigheid bij het eenmalig opzetten. (Hooguit als je heel dynamisch met containers die vanaf het internet toegankelijk moeten zijn werkt ofzo, maar dat is, niet echt gebruikelijk voor een consument.)

[HollowGamer]

Ik bedoelde misschien beter veel leken, zoals mij.

Voor mij moet een certificaat gewoon werken, en moet ik heel eenvoudig een nieuw subdomein kunnen toevoegen en die benaderen over TLS.

Het probleem zonder wildcard, is dat deze in een lijst komt te staan. Ik ben de naam even kwijt van dit ding (subject?), maar je ziet dus een hele lijst met alle subdomains. Dat kan zeer onwenselijk zijn, zeker als je service hebt die je liever (meer) geheim wilt houden. Of dat je even een subdomein nodig hebt voor testing/tijdelijk.

[lenwar]

Voor mij moet een certificaat gewoon werken, en moet ik heel eenvoudig een nieuw subdomein kunnen toevoegen en die benaderen over TLS.

Dit staat buiten kijf. Een certificaat is een stuk gereedschap dat het moet doen. Punt. Dit zal niemand tegenspreken.

Het probleem zonder wildcard, is dat deze in een lijst komt te staan.

Er is inderdaad een CT-log (Certificate Transparency).
https://crt.sh/?q=hema.nl

Die transparantie zorgt voor een groot stuk extra veiligheid. Organisaties kunnen controleren of malafide certificaten worden aangemaakt, enzovoorts. (dat is in elk geval het doel.) (Er is ook een CRL (Certificate Revocation List), waarin ingetrokken certificaten worden benoemd. Zo kan een browser dus proberen om ingetrokken certificaten niet te accepteren.)

Je kunt het inderdaad onwenselijk vinden om de namen minder publiek te maken, al moet ik zeggen dat als de beveiliging van je systeem afhankelijk is van het niet publiek maken van een naam... Nou ja. Daar heb ik een mening over Als het echt zo belangrijk is, zou ik het denk ik niet direct aan het internet hangen, maar dat verschilt natuurlijk per service of dat wel of niet realistisch is .

Ik heb in m'n eigen lan ook een letsencrypt-certificaten op m'n privé-domein, die niet op internet bestaan.
(printer.domein.nl, home-assistant.domein.nl, enz.) Die subdomeinen bestaan niet op de publieke name servers, maar alleen in m'n lan.)

Als iemand echt graag wil, zijn er overigens wel manieren om de subdomein uit te lezen. Vroeger kon je bij de meeste name servers, gewoon een AXFR (DNS zone transfer) request doen. De meeste laten dit nu niet meer toe.

Maar er zijn webportals die het doen: https://hackertarget.com/find-dns-host-records/ is er één van (je zult geen 100% accurate data krijgen op die site, maar probeer hem voor de gein is op je eigen domein ), maar ook OWASP heeft een netwerk-suite waar je vrij makkelijk dit soort zaken kunt regelen.

Of dat je even een subdomein nodig hebt voor testing/tijdelijk.

Daar zou ik juist geen wildcard voor nemen, maar gewoon een tijdelijk certificaat van een of ander. Ik zou juist niet willen dat mijn 'echte certificaten' (met bijbehorende private keys), op test-diensten gebruikt worden. Je kunt bij Letsencrypt 300 certificaten per 3 uur krijgen (per account). (of 50 certificaten per week per domein.) https://letsencrypt.org/docs/rate-limits/

Maar goed. Stel dat ik regelmatig moet testen, zou ik een certificaat aanvragen met test1.domein.nl, test2.domein.nl (tot en met test10.domein.nl) in de ASNs. Dan heb je één certificaat voor 10 subdomeinen, en dan hang je die test-services gewoon aan één van die zaken.

Ik bedoelde misschien beter veel leken, zoals mij.

Als je jezelf als leek beschouwd, dan zou ik 'juist' geen wildcard-certificaat nemen. Die certificaten zijn zo openlijk bruikbaar bij inbreuk, dat je daar extra voorzichtig mee moet zijn en dat vereist bepaalde expertise.

[MoonRaven]

Er zitten genoeg mensen met een thuislab hier en ook mensen die in de software ontwikkeling zitten.

[TheMak]

Gebeurt het weleens dat een certificaat niet opgevraagd kan worden bij le?

[Jeoh]

Zelden: https://letsencrypt.status.io/pages/history/55957a99e800baa4470002da

[neevedr]

Mijn HTB tick begon meteen te werken en ik heb het certificaat maar even ontcijferd:

TLS Certificate – Basisinformatie

Type: X.509 (End-entity / Leaf certificaat)
Doel: TLS Web Server Authenticatie (HTTPS)

Onderwerp (Subject)

Domein: helloworld.letsencrypt.org

Uitgever (Issuer)

Certificate Authority: Let’s Encrypt

Intermediate: Let’s Encrypt E6

Geldigheidsperiode

Niet geldig vóór: 2025-02-19 17:30:01 UTC

Niet geldig na: 2025-02-26 17:30:00 UTC

Cryptografie

Publieke sleutel-algoritme: ECDSA (P-256)

Handtekening-algoritme: ECDSA met SHA-384

Extensies

Subject Alternative Name (SAN): helloworld.letsencrypt.org

Key Usage: Digital Signature

Extended Key Usage: TLS Web Server Authenticatie

Certificaatketen
helloworld.letsencrypt.org
└── Let’s Encrypt E6
└── ISRG Root X1

Dit is dus certificaat van vorig jaar.

[Reactie gewijzigd door neevedr op 16 januari 2026 21:53]

[Llopigat]

De reguliere certificaten zijn momenteel 90 dagen geldig, hoewel het de bedoeling is dat de duur de komende twee jaar geleidelijk wordt verlaagd naar 45 dagen.

Zo vervelend Ik gebruik die dingen op mijn interne netwerk (en VPN) dus niets dat internet toegankelijk is. Maar het proces dat ze vernieuwt via DNS (DNS-01 methode) gaat vaak mis (de gewone poort 80/443 methode kan ik niet gebruiken omdat er niets van buiten bereikbaar is). Dus ik zit elke keer tegen problemen aan te hikken en dan heb ik maar weinig tijd om die op te lossen. Erg vervelend. Ik zou ze gewoon liefst voor een jaar hebben, immers is het alleen voor mijzelf.

Vroeger had ik gewoon een eigen CA om ze uit te geven (ook heel simpel te doen) maar google heeft het ook al onmogelijk gemaakt om zelf CA certificaten toe te voegen aan system store op Android - Sinds versie 7 ofzo al. En Apps kunnen zelf toegevoegde CA's gewoon negeren op android. En geen https gebruiken werkt ook niet goed want dingen als PWA's werken niet zonder https.

Er zou een klasse moeten zijn voor niet-internet-bereikbare certificaten met lange houdbaarheid. Of gewoon het eigen CA toevoegen weer mogelijk maken.

Ik had gehoopt dat door de dikke gratis concurrentie van Let's Encrypt de commerciele CA aanbieders hun diensten wat goedkoper zouden maken maar dat is helaas ook niet gebeurd. Die zijn zelfs niet meer betaalbaar voor een privepersoon.

[Reactie gewijzigd door Llopigat op 17 januari 2026 05:03]

[Blokker_1999]

Nog even geduld. In de loop van 2026 komt LE met een nieuwe challange type, genaamd DNS-PERSIST-01. Hierbij wordt het mogelijk om een vaste, statische sleutel in je DNS te zetten waarmee je dus niet elke keer nieuwe records moet aanmaken.

[Llopigat]

Oooh dat klinkt wel super ja. Ik hoop dat dat ook snel wordt ondersteund door de tooling. Bedankt voor de tip.

[jurgen1976]

Oh dat is goed nieuws het genoemde issue van @Llopigat is mij helaas maar al te bekend. Persistent dns record maakt het leven een stuk eenvoudiger.

[VHware]

Maar het proces dat ze vernieuwt via DNS (DNS-01 methode) gaat vaak mis

Ik weet niet welke DNS-provider je gebruikt, maar bij je automation zou je moeten kunnen instellen dat er tot zeg 5 minuten gewacht moet worden (afhankelijk van hoe traag je DNS-provider is na maken van TXT-records, dat ze op te vragen zijn), voor dat je ACME client richting Let’s Encrypt (of andere CA) stuurt dat verificatie mag plaatsvinden.

Bij mij wacht de automation 2 minuten na TXT-records aanmaken voordat verificatie verzoek gestuurd wordt en gaat daarmee altijd goed.

[Blokker_1999]

Klopt, ik geloof dat je zelfs vandaag de records kunt aanmaken en morgen je certificaat kunt gaan opvragen. Die tokens zijn op dit moment nog altijd 30 dagen geldig, al zal dat in 2028 teruggaan naar 7 uur bij LE.

[Llopigat]

Ik gebruik cloudflare DNS, ik heb speciaal dat domein daar naartoe overgezet omdat ik met andere DNS providers (zoals transIP) extreem veel problemen had. TransIP heeft bijvoorbeeld iets in hun API veranderd, iets met een global key die niet meer werkte, ik weet het niet meer precies.

Maar zelfs met cloudflare heb ik constant problemen en het probleem is niet de propagation want ik zie onmiddelijk de key terug. Ik weet niet wat het wel is maar het gaat zo vaak mis dat ik vervolgens weer door let's encrypt geband word door te veel pogingen. Een wachttijd heb ik er allang in staan inderdaad.

Ik heb ook verschillende tools geprobeerd. Acme, Caddy (met ingebouwde challenge) en nog een waarvan ik de naam vergeten ben.

[Reactie gewijzigd door Llopigat op 17 januari 2026 09:30]

[maevian]

Voor mij wekt caddy met de cloudflare plugin nochtans perfect, caddy is ook overgestapt op zeroSSL die doen minder moeilijk bij te veel aanvragen.

[pennywiser]

Ook Cloudflare icm Certbot. Nooit problemen.

[lenwar]

Ik gebruik zelf ook cloudflare, maar ik heb letterlijk nooit problemen gehad. Ik gebruik certbot en acme.sh op de verschillende platformen. (Op m’n home assistent gebruik ik de Letsencrypt add-on die volgens mij certbot gebruikt)

[S-1-5-7]

Eens. Ik heb op bijna alle hosts (die enkel intern of via VPN te bereiken zijn) in mijn netwerk een wildcard-certificaat geïnstalleerd. Dit wildcard-certificaat genereer ik op een client met internettoegang (ook via de DNS-methode) en kopieer ik vervolgens met SSH naar alle hosts.

Deze handmatige actie is prima om uit te voeren eens per drie maanden. 45 dagen is al "vervelender", maar ook nog wel te doen. Maar blijft het daarbij?

Waarom kan men niet zelf kiezen of ze certificaten gebruiken die 7, 45 of 90 dagen geldig zijn?

[Blokker_1999]

Je kan dat perfect kiezen, maar weet dat vanaf 15 maart 2029 elke grote web browser geen certificaten meer zal vertrouwen met een geldigheid van meer dan 47 dagen.

[VHware]

Het reduceren van SSL-Certificaat geldigheidsduur is een beslissing van Certificate Authority/Browser (CA/B) Forum en niet van Let’s Encrypt zelf. Uiteindelijk zullen alle publieke CA’s vanaf maart 2029 certificaten uitgeven met een maximum geldigheidsduur van 47 dagen.

Zie hier voor de volledige tijdlijn:
https://www.globalsign.co...-certificate-validity-era

[PaulHelper]

Overigens als je een leuke registrar hebt dan kun je ofwel met een al beschikbare variant of zelf gemaakt moet scriptje deze dns challenge automatiseren. Acme.sh heeft er voor een hele hoop. Maargoed afhankelijk van je registrar en of vereiste voor de cliënt is dat makkelijker gezegd dan gedaan

[Gr4mpyC3t]

Oeps, dubbel. Foutje.

[Reactie gewijzigd door Gr4mpyC3t op 16 januari 2026 21:15]

[arithcoder]

Ik vind dit stupid! Hoe vaak wordt een certificaat gebroken? Als het zo gemakkelijk was, dan hadden we geen certs die een jaar of langer geldig zijn. Ik blijf bij de 90 dagen. (of 45 binnenkort)

[latka]

Ik snap de logica als het gaat om breken (als je kijkt hoeveel entropie een wachtwoord heeft en hoe lang mensen die mogen gebruiken in een beetje bedrijf en met het laatste NIS advies om niet meer iedere 6 weken te wijzigen dus nog een stuk langer). Het gaat dan ook voornamelijk om lekken van de private key (bijv. door een hack of foute configuratie). Breken van de encryptie achter TLS is dan ook niet het echte risico.

[TechSupreme]

Inbraak bij een CA heb je het over, dat gebeurt zelden inderdaad. Maar daat gaat het niet om. Het gaat hier om diefstal bij de gebruiker en dat gebeurt best vaak.

[lenwar]

Het gaat in mindere mate om het breken van een certificaat, maar eerder om het stelen van de key.
Je zet een tap op een lijn. Je pikt alle versleutelde data op. Je steelt een paar maanden later de private key, en je kunt met terugwerkende kracht de data ontsleutelen. (N.b. er komt wel iets meer bij kijken, maar even voor het gemak.)

Hoe korter het certificaat (met private key!) geldig is, hoe minder data de kwaadwillende je data kan ontsleutelen.
Voor onze prive-domeinen of sites als Tweakers, is dat niet zo heel spannend, maar transactie-data van overheden, banken, of militaire zaken kunnen wel serieus gedoe zijn.