Let's Encrypt verkort geldigheid certificaten en komt met nieuwe DNS-challenge

Let's Encrypt gaat de geldigheidsduur van SSL- en TLS-certificaten gefaseerd verkorten tot 45 dagen. Nu zijn de certificaten die het bedrijf uitgeeft nog negentig dagen geldig. Ook komt Let's Encrypt met een nieuwe DNS-challenge om de validatie voor domeincontrole te vereenvoudigen.

Het ACME-profiel tlsserver, dat opt-in is, zal volgens Let's Encrypt vanaf 13 mei 2026 certificaten uitgeven met een geldigheidsduur van 45 dagen. Vanaf 10 februari 2027 schakelt het ACME-profiel classic naar een geldigheidsduur van 64 dagen en vanaf 16 februari 2028 zijn de certificaten in dat profiel 45 dagen geldig. De authorization reuse period, de periode waarin certificaten kunnen worden verlengd of aangevraagd zonder domeincontrole te hoeven uitvoeren, wordt daarbij vanaf 10 februari 2027 verkort naar tien dagen en vanaf 16 februari 2028 naar zeven uur. De veranderingen zijn in lijn met een wijziging van de richtlijnen van het CA/Browser Forum die eerder dit jaar werden aangenomen.

Let's Encrypt erkent dat het aantonen van domeincontrole 'het moeilijkste onderdeel' is van het automatisch uitgeven van certificaten. Dit wordt nog moeilijker door de kortere geldigheidsduur van certificaten en de kortere authorization reuse period. Daarom introduceert het bedrijf ook een nieuwe DNS-challengemethode: DNS-Persist-01. Het belangrijkste voordeel van deze nieuwe methode is volgens het bedrijf dat de DNS TXT-vermelding die wordt gebruikt om controle aan te tonen, niet bij elke vernieuwing hoeft te worden gewijzigd. Let's Encrypt verwacht dat DNS-Persist-01 in 2026 beschikbaar zal komen.

Reacties (70)

[michielonline]

Eigenlijk wordt nu de betrouwbaarheid van certificaten op voorhand in twijfel gebracht wat opgelost zou moeten worden door een kortere geldigheid.

Daarmee verleg je de betrouwbaarheid van het certificaat naar de betrouwbaarheid van het renewal mechanisme. Een certificaat stelen heeft straks nog maar beperkte waarde, maar met toegang tot DNS ben je meteen koning.

ik ben benieuwd hoe vaak een certificaat gestolen en misbruikt wordt, oftewel heeft deze maatregel ook een praktisch nut of is het een hypothetisch risico?

[vrow]

Het gaat erom hoe lang een certificaat geldig blijft dat is uitgegeven aan iemand die het niet had moeten hebben, volgens mij.

Dat kan op 2 manieren: iemand hackt je server en steelt het certificaat.

Of: iemand hackt 'iets' en krijgt op die manier een certificaat in handen wat hij niet had horen te krijgen. En 'hacken' is dan heel breed natuurlijk - het kan zijn dat iemand de DNS-provider hackt en dan de DNS-TXT aanpast zodat hij het certificaat 'legitiem' in handen krijgt. Het kan ook zijn dat iemand Let's Encrypt hackt en op die manier vele certificaten krijgt die hij niet hoort te krijgen.

Let's Encrypt of jijzelf komt dan achter de hack (bijv van de DNS) en dan vervallen de certificaten in elk geval snel. En al jij achter de DNS-hack bent gekomen en het record aanpast, kan de aanvaller in elk geval niet meer het certificaat vernieuwen.

Dus volgens mij is deze manier wel veiliger.

[swhnld]

De authorization reuse period, de periode waarin certificaten kunnen worden verlengd of aangevraagd zonder domeincontrole te hoeven uitvoeren, wordt daarbij vanaf 10 februari 2027 verkort naar tien dagen en vanaf 16 februari 2028 naar zeven uur.

Vanuit een puur beveiligingsperspectief snap ik de kortere tijden, maar vanuit beschikbaarheid denk ik dan, een DoS aanval kan prima die 7 uur de boel platleggen, en dan ga je problemen krijgen met foutmeldingen op legitieme websites met verlopen certificaten.

Daarnaast met de kortere geldigheid moeten mensen vaker hun certificaten verlengen, dus krijg je daar ook weer meer verkeer door op de backend wat dan weer ergens uit betaald moet worden. Nu worden ze nog bekostigd uit sponsoring, maar blijft de sponsoring in de pas bij oplopende kosten, of gaan ze toch kosten moeten berekenen?

[GertMenkel]

Dit gaat over de authorisatie tussen je IT en de certificaatboer, het is niet dat je certificaten maar een paar uur geldig zijn. Je kunt nu aan Let's Encrypt bewijzen dat je eigenaar bent van een domijn en met dat account pas een maand later een certificaat aanvragen. Straks mag je je bewijs van eigenaarschap maximaal 7 uur van tevoren doen. Ik weet niet welke tool jij gebruikt, maar mijn eigenaarschapsbewijs wordt over het algemeen binnen vijf seconden (HTTP) of vijf minuten (DNS) gebruikt voor een nieuw certificaat.

Aangezien certificaten straks zo'n anderhalve maand geldig zijn, zul je een DDoS van ongeveer een halve maand aan moeten kunnen voor je hier problemen mee gaat krijgen.

Qua kosten zal het wel meevallen, een DNS-lookup is niet zo heel duur.

Wat je voor de kortere geldigheid terugkrijgt, is dat de CRL's veel kleiner worden (die continu moeten worden gedownloaded om ingetrokken certificaten te zoeken). Ja, je hebt OCSP stapling, maar dat wordt in de praktijk standaard maar weinig gebruikt. Kleine CRL's schelen weer hostingkosten en minder intrekkingen van gelekte/kapotte oude certificaten leiden tot minder handwerk, dus er zitten ook kostenvoordelen aan.

[Reactie gewijzigd door GertMenkel op 3 december 2025 16:49]

[Jamie4242]

Firefox heeft tegenwoordig een oplossing voor dit probleem: CRLite. Een normale volledige CRL is rond de 300 MB, terwijl de CRLite implementatie af kan met een 4 MB snapshot elke 45 dagen en een 300 kB update file elke dag. Deze blogpost hierover is zeer interessant om te lezen.

Chrome gebruikt CRLSets, wat maar ongeveer 1% van de revocations bevat en alsnog 600 kB per dag is.

[GertMenkel]

Hoewel CRLite een mooie oplossing is, denk ik niet dat het veel verschil gaat maken met het marktaandeel van Firefox. Firefox was ook een van de weinig die volop inzette op OCSP Stapling en de verbeteringen aan het OCSP-protocol terwijl Chrome meer richting uitfaseren ging, en nu zal Firefox wel moeten aangezien (nieuwe) CA's geen OCSP-servers hoeven aan te bieden.

Toch wel interessant hoe Firefox zo snel kon wisselen nadat het nieuws van het begin van het einde van OCSP werd aangekondigd.

Als uiteindelijk (in 2030?) de certificaatlevensduur naar een dag of 7 afzakt, zijn normale CRL's in de praktijk ook al voldoende. Ik denk dat Chrome en de meeste andere browsers daarom liever nog een paar jaar vasthouden aan hun oude implementatie dan aan het omwisselen naar CRLite.

[Reactie gewijzigd door GertMenkel op 4 december 2025 10:31]

[NielsFL]

Dit was inderdaad ook direct mijn gedachte na het lezen van het artikel. Ik snap dat ze gelekte certificaten liever snel laten verlopen dan intrekken. Maar daar staat tegenover dat je de continuiteit van je website wil waarborgen en vanuit die optiek wil je eigenlijk een zo lang mogelijke geldigheidstermijn.

Lets Encrypt kan platliggen of tijdelijk onbereikbaar zijn. Ook aan de client kan kunnen zich bugs of problemen voordoen waardoor een geplande verversing faalt en je meer tijd nodig hebt.

Het is uiteraard een balans, maar persoonlijk vind ik het wel heel kort worden allemaal zo.

[Blokker_1999]

Maar dan snap je niet waar het over gaat.

Een certificaat is vandaag 90 dagen geldig en wordt vandaag vernieuwd wanneer er een levensduur is van ergens tussen de 7 en de 30 dagen aan geldigheid van het certificaat. Als er dan problemen zijn op het moment dat je dat certificaat wenst te vernieuwen is er dus nog niet direct een probleem want je hebt dan alsnog meerdere dagen om een oplossing te zoeken.

En ook in de toekomst, wanneer de levensduur verkort wordt naar 45 dagen verwacht ik dat de meesten zichzelf alsnog enkele weken voor het vervallen veilig willen stellen en dus vernieuwen met voldoende tijd in geval van problemen.

De geldigheid die naar 7 uur gebracht zal worden is net de optie om zonder verificatie of je wel eigenaar bent van het domein een nieuw certificaat aan te vragen voor dat domein. Dat kan in sommige gevallen nadelig zijn al zou het in de meeste gevallen geen verschil moeten maken.

[HollowGamer]

Het probleem vind ik wel de rate limits. Ik weet niet of ze daar iets aan hebben gedaan, maar dacht iets van 3-5 verkeerde requests, en je mag pas de volgende dag weer proberen.

Dan heb je dus al mindere dagen over. Gelukkig heb je allemaal tools tegenwoordig, zoals Caddy die het ook kan doen.

[Reactie gewijzigd door HollowGamer op 3 december 2025 20:31]

[PaulHelper]

Toevallig laatst een domme configuratie fout gemaakt en daardoor erg vaak geprobeerd andere certificaten te maken. Was nog verrassend veel maar inderdaad na een stuk of 10-15 moest ik een tijd wachten. Gelukkig kwam ik toen tot de conclusie dat ik de juiste al had.

Zoals in het zie valt het best mee Up to 10 accounts can be created from a single IP address every 3 hours. The ability to create new accounts refills at a rate of 1 account every 18 minutes.

[Reactie gewijzigd door PaulHelper op 3 december 2025 22:36]

[HollowGamer]

Hopelijk is het verbetert, gelukkig hoef ik niets meer te doen met Let's Encrypt.

Dat is ook wel wat ik wil aangeven. Je moet echt weten wat je doet, als je eigenlijk een wildcard wilde hebben, dan duurt het weer even voordat je weer kan vernieuwen.

[peter___]

If you’re using Certbot, you can use our staging environment with the --test-cert or --dry-run flag.

Toen het bij mij foutging qua rate limits heb ik geïmplementeerd dat eerst altijd --dry-run wordt gebruikt en als dat slaagt pas zonder.

[.oisyn]

maar dacht iets van 3-5 verkeerde requests, en je mag pas de volgende dag weer proberen.

Dat is vooral een probleem tijdens de initiele setup, dan doe je nog wel eens een keer wat verkeerd of staan de timeouts te strak. Als het eenmaal loopt dan boeit die ratelimiet natuurlijk helemaal niets

[mcyh]

Als let’s encrypt zelf plat ligt of gekaapt wordt, lijkt me dat een reëel scenario.

[laurxp]

Een langdurige wereldwijde DoS-aanval op je DNS servers? Succes daarmee, want in de praktijk komt dat neer op "we gaan Microsoft/Amazon/Google/Cloudflare DoSsen" - en dan is het ook nog eens redelijk triviaal om over te stappen op een andere provider...

De backend kosten voor LetsEncrypt zijn verwaarloosbaar. In 2017 hadden ze bijvoorbeeld een budget van $2.9M, waarvan slechts $200k naar hardware ging: een verdubbeling van het aantal requests (en daarmee een verdubbeling van de hardwarekosten) heeft dus geen noemenswaardige impact op het totale budget, en er is geen reden om aan te nemen dat ze met kortere geldigheid ineens een budget van honderden miljoenen per jaar nodig hebben.

LetsEncrypt geeft in 2025 700 miljoen certificaten uit. Uitgaande van een gemiddelde renewal na 60 dagen, is dat slechts 135 requests per seconde - dat zou je haast met een Raspberry Pi kunnen doen!

Daarnaast is LE actief bezig om de infrastructuur zo simpel mogelijk te houden. Zo zorgde OCSP Stapling voor enorm veel verkeer terwijl het eigenlijk weinig beveiliging toevoegde, dus daar zijn ze mee gestopt. Hetzelfde met CT logs: traditioneel moesten deze allemaal van één complexe en dure server komen, maar door het protocol opnieuw uit te werken is het triviaal schaalbaar gemaakt - waardoor de hostingkosten véél lager zijn geworden. Of het stoppen met expiration warning email, en preventief suspenden van zombie clients.

[lolgast]

Ik miste het in de tekst want volgens mij is een nadeel van TXT-record authenticatie nu dat je geen wildcard certificaten kan gebruiken. Dat kan dus wel bij het gebruik van een DNS-Persist-01 record. Mits je de juiste parameter meegeeft in het TXT-record

[Barryvdh]

Dat kan nu al wel met de DNS-01 Challenge:

https://letsencrypt.org/docs/faq/#does-let-s-encrypt-issue-wildcard-certificates

Does Let’s Encrypt issue wildcard certificates?

Yes. Wildcard issuance must use the DNS-01 challenge. See this post for more technical information.

[- peter -]

Juist nu is TXT verificatie wel de manier voor wildcards. Je moet een dynamisch TXT record aanmaken via een DNS plugin voor certbot. Gewone certificaten gaan via de .acme-challenge folder via http request en dus geen DNS nodig.

[mrwiggs]

Je kunt prima de DNS challenge gebruiken voor non-wildcard certificaten hoor, ik doe nooit een HTTP challenge.

[indigo79]

Het is niet nodig om de DNS challenge te gebruiken, maar het kan inderdaad wel. Voor wildcard certificaten is DNS de enige manier (en dus wel nodig).

[witchdoc]

maar doe je hetr voor je eigen DNS servers? Mijn ervaring is dat het serieus achter loopt behalve voor externe DNS providers?

[RobertMe]

De enige manier om nu wildcard certificaten te krijgen is juist via de DNS challenge omdat je juist daarmee aantoont de DNS en dus het domein te beheren. In de andere gevallen (HTTP, ALPN) is het namelijk prima mogelijk dat één subdomein verwijst naar de server maar je vervolgens als hoster van dat subdomein niet de eigenaar bent (denk bv aan een hosted FAQ/helpdesk pakket dat bereikbaar is op faq.<bedrijf>. De SAAS aanbieder van dat pakket wordt met DNS naar verwezen maar is niet de eigenaar van het domein).

Maar het "probleem" dat de DNS challenge momenteel heeft is dat je de ACME client (certbot, of bv een reverse proxy als Traefik met ACME / lets encrypt support ingebakken) toegang moet geven tot je DNS omgeving / API. Immers moet die elke zoveel dagen dat TXT record kunnen aanmaken. En dat is onwenselijk omdat de credentials (/API key) zou kunnen uitlekken en iemand alle DNS records kan aanpassen (dus bv ook A/AAAA of MX), maar ook dat buggy software natuurlijk de DNS kan slopen.

En met deze DNS Persist challenge zal er geen DNS toegang nodig zijn voor de ACME client. Dus als eigenaar zul je eenmalig (met de hand) een DNS record aanmaken en die is dan oneindig geldig.

[.oisyn]

Zo fijn dit, het onderhouden van die DNS verificatie vond ik altijd een ramp. Dan ging het weer mis omdat je nameserver host er te lang over doet om wijzigingen door te voeren en dan timed de boel weer out (ik kijk naar jou, TransIP - ja I know, ik heb de overstap naar Cloudflare nog niet gemaakt). Hiermee hoef je ook geen plugin meer te gebruiken voor jouw specifieke hoster, en dat maakt het maken van een cert weer een stuk makkelijker voor devices die niet per se met een webserver aan het internet hoeven te hangen.

[Reactie gewijzigd door .oisyn op 4 december 2025 00:17]

[tistjendop]

je kan met de DNS-01 challenge (die dus een TXT record schrijft in je DNS en die verifiëert) wel gewoon wildcard certificaten maken. Bij de HTTP-01 challenge die een tekstbestand op je webserver zet kan je dan weer geen wildcard certificaat krijgen,

[Scriptkid]

Kunnen we aub stoppen met txt record validatie. We zijn ver buiten de supported 512byt udp en nogsteeds kunnen veel servers niet goed met tcp overweg.

Nieuwe validatie zou altijd op subdomein moeten om je root txt zuiver te houden.

[thenob]

Helemaal mee eens.
Als je ziet welke rommel er nu in DNS-zones staan dan zie je door de bomen het bos niet meer.
Heb net even gechecked en zie zones met meer dan 50 TXT-records.
SPF, DKIM, DMARC, ze moeten allemaal TXT-records hebben, en dan wil MS, Google, Facebook, Mailchimp etc, dat ook nog eens een eigen TXT-record.
De overhead is wel iets te, zeker wanneer je je zones met DNSsec ook nog eens tekent.

[ralphm]

Is dat niet precies wat DNS-Persist-01 doet? Het TXT record zit nu op het te verifiëren domein, dus `_acme-challenge.example.org`, en `_acme-challenge.tweede-san.example.org`. Dan kom je toch niet over die 512 bytes heen?

[deadinspace]

Kunnen we aub stoppen met txt record validatie. We zijn ver buiten de supported 512byt udp en nogsteeds kunnen veel servers niet goed met tcp overweg.

ACME DNS-01 validatie vereist een TXT record op _acme-challenge.domain.tld, niet op domain.tld zelf.

DNS-01 kost geen extra ruimte op je root TXT record, dus je kritiek is simpelweg niet van toepassing hierop.

[Reactie gewijzigd door deadinspace op 4 december 2025 13:57]

[- peter -]

Zou idd wel fijn zijn als je gewoon handmatig een DNS TXT record eenmalig kan opzetten ipv DNS plugins te gebruiken. Dan hoef je dat maar 1x te regelen en kan je meerdere servers wildcards laten opvragen ipv daar alles weer te configureren.
Maar vraag me dan wel af hoe je je dan authenticeert?

[Reactie gewijzigd door - peter - op 3 december 2025 15:56]

[zenlord]

Zelf vind ik die DNS plugins net zo eenvoudig met certbot en acme.sh (en ze bestaan voor zo goed als iedere DNS registrar vermoed ik zo). Met Caddy moest ik inderdaad ooit wel eens wat prullen met xcaddy op Debian stable (enige tijd terug), maar ook dat bleek achteraf niet zoveel om het lijf te hebben.

[eborn]

Het grote nadeel van DNS plugins, helemaal op remote server systemen, is dat je jezelf in allerlei bochten moet wringen om dit veilig te krijgen. Je wilt namelijk niet dat een server toegang heeft tot de DNS, al is het maar heel specifiek om een TXT record te updaten. In veel gevallen kun je niet zo specifiek targetten, omdat het hostname deel van het DNS record dynamisch is. Dus effectief moet je een ACME DNS client dan volledige schrijfrechten geven op de TXT records van een zone.

[Eärendil]

Je kan _acme-challenge.hetdomein.nl ook een CNAME maken naar een andere zone, dan kan het domein waar je een certificaat voor aanvraagt een ander domein zijn dan waar je schrijfrechten op geeft.

[Polderdijk]

Ik gebruik hiervoor een eigen server met https://github.com/joohoi/acme-dns erop. Op je primaire DNS server maak je per certificaat éénmalig een CNAME aan naar je ACME-DNS server (_acme-challenge), aan de 'client' kant stel je je eigen acme-dns server in om de challenge te regelen en dan is het set and forget.

Zonder security issues.

[HollowGamer]

Met systemd hoeft dat dacht ik niet meer. Zo deed ik het voorheen, en je kun het hardenen. Ik dacht dat de Arch Linux package dat met acme.sh daemon zo had gedaan.

Ik heb geen idee of het tegenwoordig ook kan met Podman Quadlet bijvoorbeeld of Docker eventueel. Tegenwoordig doe ik het met externe tools van de hoster of via de proxy als Caddy/treafic.

[zenlord]

In mijn situatie beheer ik volledig zelf mijn infrastructuur, dus certificaten via certbot en DNS via bind9. Wat is er dan onveilig aan als ik certbot configureer op machine A, een certificaat toewijs aan machine A en op machine B bind9 instrueer om TXT updates toe te laten vanaf machine A?

(oprechte curiositeit, want veiligheid primeert!)

[eborn]

Als je inderdaad enkel TXT updates toelaat is het risico klein (los van het feit dat iemand die machine A hacked ook namens jou SSL certificaten kan aanvragen).

Maar in veel gevallen heeft machine A volledige DNS rechten en dan kan een hacker van machine A je domein effectief overnemen.

[zenlord]

Dank je!

[Barryvdh]

Zo te zien is het gekoppeld aan je account van de certificaat provider (zoals Let's Encrypt), dus zal je daar inloggen en een TXT record krijgen dat gekoppeld is aan jouw account + domein.

[Yggdrasil]

Ik denk niet dat je inlogt bij LE via een web interface of zo. Het zal waarschijnlijk gewoon via de huidige ACME API gaan.

[laurxp]

Maar vraag me dan wel af hoe je je dan authenticeert?

Eigenlijk heel simpel: je zet je LetsEncrypt username in het DNS record!

Op dit moment heeft ACME/LetsEncrypt al gebruikersaccounts. Hier merk je echter niets van, omdat deze 1) niet zijn gekoppeld aan je emailadres, 2) geen wachtwoord hebben maar een keypair, en 3) zonder gebruikersinteractie dynamisch worden aangemaakt bij het eerste gebruik.

Je ACME-client kán zich dus al veilig authenticeren naar de CA. Om een dns-persist-01 record aan te maken, hoef je alleen maar je ACME-client te vragen wat het aangemaakte account id is.

[HollowGamer]

Ik vind het maar erg lastig. Heb liever dat browsers komen met LE by default, en dan hebben we eigenlijk hetzelfde.

Wat is nu de meerwaarde ervan? Ben blij dat TLS nu de standaard is, maar het is nog altijd zo lastig, zeker voor lokaal gebruik.

[ArnoldSmit]

Je kan een reverse proxy er tussen zetten Ngix Proxy Manager of Traefik.
En anders Cloudfare tunnels, dan heb je zelfs geen port forwarding nodig in je firewall.
Met bovenstaande oplossingen, is het 1 X instellen en hoef je er niet echt meer naar om te kijken.

[HollowGamer]

Maar snap je dat het eigenlijk nergens over gaat? (Algemene vraag)

Het idee van een certificaat was vooral om te weten of je veilig met een site deed communiceren. Wat is nu precies de meerwaarde? Kunnen we niet gewoon standaard over TLS gaan met of zonder certificaat?

[pennywiser]

Wie controleert dat dan?

[HollowGamer]

Let's Encrypt nu toch ook niet? Het enige is dat het een certificaat geeft (heel kort door de bocht gezegd).

[indigo79]

Let's Encrypt controleert dat de aanvrager van een certificaat controle heeft over de machine (of het domein in het geval van wildcard certificaten) waarvoor een certificaat wordt aangevraagd. Dat sluit een man in the middle attack uit.

Stel dat je inlogt bij je bank via een gecompromitteerd wifi netwerk. Als jij gecontroleerd hebt dat je hostname klopt, kan de aanvaller niet zomaar ongemerkt je verkeer onderscheppen en aanpassen, want hij heeft geen vertrouwd certificaat (en dus geen vertrouwde private key die bruikbaar is met dat domein). Als hij een certificaat van een ander domein gebruikt, krijg jij van je browser een melding dat de domeinnaam niet overeen komt.

Als we geen eigendomscontrole doen of geen domeinnamen toevoegen aan het certificaat, kan de hacker gewoon een certificaat aanmaken. Jij verbindt met de hacker, je hebt geen mogelijkheid om te weten of dat de hacker of je bank is, dus de hacker kan je verkeer lezen of zelfs aanpassen (even eigen bankrekeningnummer invullen bij een overschrijving en verder doorsturen naar bank en bij het terug ontvangen van het antwoord van de bank terug het rekeningnummer invullen dat jij had ingevuld vooraleer de data verder naar jou gestuurd wordt). Dan kunnen we niet meer vertrouwen dat we communiceren met wie we denken te communiceren.

Het klopt dat Let's Encrypt geen identiteit van de persoon controleert, maar ze controleren wel waterdicht of je toegang hebt tot het domein. Als dat gehackt wordt, heb je dus wel een probleem, maar dat heb je dan zonder Let's Encrypt ook.

Er bestaan alternatieven voor CA's: PGP/GPG gebruikt bijvoorbeeld een web of trust, waarbij mensen keys van mensen die ze kennen ondertekenen met een mate van vertrouwen in die persoon dat die keys zorgvuldig behandelt. Werkt gedistribueerd, maar is omslachtiger.

[pennywiser]

Kort antwoord: Jawel, want Letsencrypt is een trusted party of CA. Je kan het beste even vanaf het begin uitzoeken hoe SSL werkt in browsers. En public/private keys etc.

"A CA is an outside organization, a trusted third party, that generates and gives out SSL certificates. The CA will also digitally sign the certificate with their own private key, allowing client devices to verify it."

[Wafeltje]

Het gaat niet om veilig te praten met de webserver (Want TLS versleuteld het netjes), maar hoe weet jij dat je met de juiste server communiceert? Dat is wat het certificaat aantoont.

TLS zonder certificaat zou kunnen betekenen dat je een versleutelde verbinding hebt met de hacker (man-in-the-middle)

[HollowGamer]

Maar is dat nog altijd het geval? Ik ben geen expert, dus sta open om erover te leren.

Met de dynamische servers tegenwoordig, heb je toch niet meer èèn punt? De TXT record wordt geüpdatet, maar dat kan toch een willekeurige proxy zijn? Je kunt dacht ik een LE certificaat updaten d.m.v. een andere server.

Ik vind natuurlijk wel dat LE goed is. Ik had het meer over lokale toepassingen. Het is nu best veel gedoe om je self signed certificaat te managen. Met LE kan je bijvoorbeeld geen lokaal certificaat aanvragen.

En ja, ik weet dat ik het niet weet waarover het heb. Er zijn mensen die je daarvoor uitlachen, die zou ik niet als collega of vriend willen hebben.

[Reactie gewijzigd door HollowGamer op 3 december 2025 20:40]

[.oisyn]

Met LE kan je bijvoorbeeld geen lokaal certificaat aanvragen

Maakt dat uit dan? Ik heb voor mijn NAS en router gewoon LE certificatent terwijl die niet van buitenaf te benaderen zijn, met subdomeinnamen die verwijzen naar lokale IPs.

[ArnoldSmit]

Jij gaf aan:

maar het is nog altijd zo lastig, zeker voor lokaal gebruik.


Daar heb ik je een aantal oplossingen voor gegeven ;)

En je geeft verderop aan zonder certificaten te willen werken?

Heel ironisch dat je tegen mij de opmerking maakt, weet je wel waarover het gaat, bedankt voor het lachen.

[Reactie gewijzigd door ArnoldSmit op 3 december 2025 18:59]

[HollowGamer]

Jammer dat je zo reageert.

Ik vind het nog altijd veel gedoe om lokaal iets te encrypten van verkeer. Het zal vast mogelijk kunnen, maar het is nog altijd 3rd parties die je gebruikt. Zelf gebruik ik nu Caddy ervoor, maar self signed.

Mijn gedachten ging meer over (lokale) sites gewoon dat proces (nog) eenvoudiger maken. Certbot is nog altijd vervelend, zeker als je per ongelijk de limiet krijgt bij verkeerd instellen. En ook dat is nog altijd veel gedoe.

Mijn vraag was dus in het algemeen bedoelt, dat zei ik er ook bij. Jammer nogmaals dat je zo antwoord, maar als je kleineren van mensen je goed doet, so be it.

[Reactie gewijzigd door HollowGamer op 3 december 2025 20:26]

[The Zep Man]

Let's Encrypt erkent dat het aantonen van domeincontrole 'het moeilijkste onderdeel' is van het automatisch uitgeven van certificaten. Dit wordt nog moeilijker door de kortere geldigheidsduur van certificaten en de kortere authorization reuse period.

Valt wel mee. Verificatie via HTTP gaat prima als er al een webserver draait om argeloze browsers door te verwijzen naar HTTPS. Met een kleine (statische) toevoeging aan de configuratie van de webserver hoeft Certbot enkel de challenge te plaatsen in de juiste lokale directory zonder verdere acties.

Dit werkt uiteraard niet voor wildcard certificaten, die op andere vormen van verificatie steunen.

[Blokker_1999]

Op 1 server is dat inderdaad niet moeilijk, maar van zodra je met clustering begint waarbij verschillende nodes in essentie een certificaat moeten gaan delen, of op zijn minst alle nodes in de SAN lijst hebben steken, dan wordt het ineens wel een feestje.

[DDX]

Maar hoe zit de verkorte validatie geldigheid :

De authorization reuse period, de periode waarin certificaten kunnen worden verlengd of aangevraagd zonder domeincontrole te hoeven uitvoeren, wordt daarbij vanaf 10 februari 2027 verkort naar tien dagen en vanaf 16 februari 2028 naar zeven uur.

Als de acme-dns-persist juist weer langer geldig is ?

[laurxp]

De challenge is langer geldig, de validatie niet.

De CA is verplicht om de controle van het DNS-record uiterlijk 10 dagen / 7 uur voor aanmaak van het certificaat uit te voeren. Dus als je 14 dagen later een tweede certificaat aanvraagt, moet het opnieuw het DNS-record controleren. Dit voorkomt dat een aanvaller met tijdelijke toegang tot je DNS-infrastructuur langdurig in jouw naam certificaten kan aanvragen.

Dat er in het DNS-record met dns-persist-01 bij iedere validatie precies dezelfde data staat, is daar compleet los van. Het is alsof je bij je werk steeds hetzelfde toegangspasje moet laten zien, in plaats van dat de beveiliging je binnenlaat omdat ze je hoofd herkennen - ook als je inmiddels bent ontslagen...

[yevgeny]

Hoe vaak komt het eigenlijk voor dat certs worden gestolen of op andere manier misbruikt worden ?

[SuperDre]

Juist, dat vraag ik me ook af, want zidra je wert dat iets gestolen is en dus misbruik wordt gemaakt van jouw certificaat kun je die toch zelf intrekken.

Overigens is het natuurlijk alleen maar veilig als jij zelf ook echt het einddoel controleert of het die is die je wilde. Want fugiemugiesites met bv een nul voor een O kan voor jou in de browser er nog steeds betrouwbaar uit zien, en dan heeft een certificaat geen drol zin.

[Blokker_1999]

En het punt is net dat dat intrekken vaak niet gebeurt. Vele gestolen certificaten worden nooit op een CRL gezet. Maar het wordt nog erger, want zowat alle browsers kijken die CRLs niet eens meer na want als een CRL niet bereikbaar is willen ze toegang tot die website niet blokkeren.

Door nu dus de levensduur te verkorten, waarbij je ook iedereen dwingt om het vernieuwen van certificaten te automatiseren, zorg je er voor dat een gestolen certificaat maar voor een beperkte periode misbruikt kan worden.

[markg85]

Ja, ehh... Gratis of niet, het wordt nu toch wel irritant.

Ik gebruik een wildcard certificaat en elke 90 dagen de dns challenge bijwerken (en een bestandje op de host) en dat over een paar servers is al geen pretje. Het werkt, ja. Maar sommige registrars (argeweb in mijn geval) hebben simpelweg geen optie voor DNS aanpassingen via een API waarmee het toch best wel vervelend is. Nou is dit maar voor een paar domeinen dus makkelijk te overzien. Maar als die 90 dagen naar 45 gaat wordt het nog een stapje minder leuk.

Mss toch maar weer is gewoon een 1-jarig certificaatje kopen. Die "beveiliging" van dit is ook alleen maar bezigheidstherapie.

[bonyuri]

Maar is dat niet precies wat dns-persist-01 oplost? Je hoeft dan dus niet meer handmatig steeds de DNS challenge aan te passen.

[PaulHelper]

Handmatig doen toch echt weinig mensen. En welke registrars heb je dan als ik vragen mag. Acme.sh heeft er echt heel veel, anders kun je nog overwegen hiervoor een cloudflare of iets dergelijks ertussen te zetten.

[HollowGamer]

Worden we niet te veel afhankelijk van Cloudflare? Maar deel zeker je mening, ik deed het Digital Ocean ook zo.

[markg85]

En welke registrars heb je dan als ik vragen mag.

Ik quote mezelf:

Maar sommige registrars (argeweb in mijn geval) hebben simpelweg geen optie voor DNS aanpassingen via een API

Cloudflare is voor mij een absolute no-go. Ik, als dev, heb juist een vreselijke hekel aan hun. Maar ja, een andere partij is een optie.

[PaulHelper]

Sorry ik had over het hoofd gezien dat je argeweb zei. Als ze echt de meest klantvriendelijke zijn dan helpen ze daarbij. Als in dan zorgen ze dat een API komt of iets van een script, in het beste geval zelfs beschikbaar via hun management portal. Zoals ik het zie schieten ze hunzelf alleen daarmee in de voet want je moet 14 euro betalen voor hun managed ssl met subdomeinen. Echt een grap als je het mij vraagt.

Maar zoals ik zeg anders blijft een derde dns management partij zeker een optie, mijn suggestie voor cloudflare was maar een voorbeeld ik zag al aankomen dat jij of iemand anders hier tegenin zou gaan.

[deadinspace]

Mss toch maar weer is gewoon een 1-jarig certificaatje kopen.

Daar koop je maar een paar jaar uitstel voor, want alle CAs gaan uiterlijk 2029 naar 47 dagen. Let's Encrypt loopt alleen voorop met dit initiatief (zoals wel vaker).