Let's Encrypt-certificaten van 64 dagen zijn vanaf oktober te testen

Let's Encrypt begint volgende week met de eerste tests van SSL-certificaten die geen 90, maar 64 dagen geldig zijn. Site- en serverbeheerders kunnen vanaf 14 oktober proefdraaien met die korter geldende certificaten.

Dit nieuws in het kort

• Let's Encrypt-certificaten hebben standaard een geldigheid van 90 dagen, maar Let's Encrypt verlaagt dat vanaf 2028 naar 45 dagen.
• Vanaf 2027 volgt een tussenstap met certificaten die 64 dagen geldig zijn.
• De tijd om zonder nieuwe autorisatie een certificaat nogmaals te vernieuwen wordt korter.

Let's Encrypt schrijft dat het de standaardduur van SSL-certificaten vanaf 10 februari 2027 inkort. Vanaf die datum duren alle certificaten standaard 64 dagen. Daarvoor verlopen de laatste 90-dagencertificaten op 11 mei 2027. Dat gebeurt vanzelf, zegt Let's Encrypt. Het bedrijf gaat certificaten niet zelf intrekken.

De veranderingen zijn vanaf 14 oktober te testen in de stagingomgeving, zegt het bedrijf.

Gebruikers kunnen nog steeds kiezen voor certificaten met een kortere levensduur. Het bedrijf biedt bijvoorbeeld sinds begin dit jaar certificaten aan met een levensduur van een week. Het blijft mogelijk zulke korte certificaten te gebruiken, maar beheerders moeten dan zelf daarvoor kiezen.

Het gaat om een tussenstap naar verkorting van de levensduur van certificaten naar 45 dagen. Dat moet vanaf 2028 gebeuren. Let's Encrypt zei bij de aankondiging daarvan al dat het eerder een kortere certificaatduur van 64 dagen zou introduceren. Daarvoor waarschuwt het bedrijf beheerders nu nog eens.

Let's Encrypt zegt dat beheerders hardcoded verloopdatums zelf moeten aanpassen. Als beheerders clients gebruiken die het ACME Renewal Info-protocol ondersteunen, worden nieuw uitgegeven certificaten in de stagingomgeving vanzelf korter.

Autorisatiechallenge

Let's Encrypt maakt ook de periode korter waarin gebruikers een autorisatiechallenge kunnen hergebruiken. Nu heeft een challenge zoals HTTP-01, DNS-01 of TLS-ALPN-01 nog een hergebruikperiode van 30 dagen. Beheerders die hebben aangetoond dat ze gemachtigd zijn om een certificaat te vernieuwen, kunnen dat 30 dagen lang nogmaals vernieuwen zonder volgende autorisatie.

Vanaf februari 2027 verkort Let's Encrypt die periode eerst stapsgewijs van 30 naar 10 dagen. In 2028 neemt die verder af tot 7 uur. Let's Encrypt zegt dat dat geen invloed heeft op de rate limits van de api.

Reacties (49)

[Miglow]

Waarom doen ze dat eigenlijk?

[Tjidde]

Omdat korter minder risico vol is. Want mocht iemand je certificaat jatten heb je minder lang gezeik. Je kunt een certificaat wel intrekken maar sommige browser checken dat niet voldoende.

Dus als je certificaten gewoon minder lang geldig zijn, zal een browser zeggen certificaat verlopen bij diefstal.

En je zou en theorie elke dag een nieuw certificaat kunnen aanvragen. Bij een goed ingestelde webserver is hier de impact bijna 0 van.

[michaelkamen]

Hoe vaak komt het eigenlijk echt voor dat certificaten worden gestolen? Of wordt er nu van alles opgetuigd / op de hals gehaald voor iets wat eigenlijk een fictief probleem is?
(en dan bedoel ik niet het scenario dat een CA plotseling stopt ofzo)

[Keypunchie]

Denk eerder dat ze bang zijn dat de Intermediates 'compromised' kunnen raken, dan dat het probleem nou echt om het certificaatje van Jan's Webshop gaat. Dan heb je gewoon een langlopend (publiek) probleem, als de uitgegeven certificaten 1-3 jaar geldig zijn.

Persoonlijk vind ik het wel wat overtrokken om (met stappen) naar 47 dagen te gaan. Voor een webserver is het allemaal geen centje pijn, maar er zijn ook andere systemen met certificaten die net iets meer impact ervaren.

[Blokker_1999]

Er zijn 2 risico's

• Inbraak bij een bedrijf en dat diens certificaten gestolen worden om daarna een MITM aanval op te zetten en alle verkeer met klanten te kunnen afluisteren
• Inbraak bij een CA waarna er willekeurige certificaten gegenereerd kunnen worden die daarna misbruikt kunnen worden.

De reductie van levensduur is jaren terug al ingezet. Eerst naar 2 jaar, dan naar 1 jaar, vandaag een half jaar, vanaf April nog 3 maanden om in 2029 naar 1,5 maand te gaan. Iedereen heeft tijd genoeg om oplossingen te zoeken. Zij het integratie door het ACME protocol, zij het op een andere manier afhankelijk van de CA. Het vernieuwen van certificaten op een geautomatiseerde manier is ook niet nieuw. Microsoft's CA heeft al heel lang de nodige APIs die je kunt aanspreken bijvoorbeeld.

Vanuit het standpunt van security is het dan ook helemaal niet overtrokken, maar net een goede evolutie. Certificaten moeten mee evolueren op als veilig bestempeld te kunnen blijven worden. Als we vandaag nog toestonden dat een certificaat 10 jaar geldig mag zijn, dan hadden we vandaag ook vele websites met certificaten die onveilig zijn.

En misschien nog het belangrijkste wat vaak over het hoofd wordt gezien: dit is enkel van toepassing op certificaten uitgegeven via een publieke CA. Genereer je je eigen certificaten en installleer je je eigen, vertrouwde root certificaat op je computer om daarmee alles te ondetekenen? Dan mag je gerust nog altijd certificaten generen die 10 jaar lang geldig zijn.

[Keypunchie]

Ja, maar 45 dagen blijft ook wat arbitrair.

47 days = 1 maximal month (31 days) + 1/2 30-day month (15 days) + 1 day wiggle room

Schiet mij maar lek.

Het CA/B Forum heeft inderdaad goede redenen om de duur te verkorten, maar tot nog toe was Let's Encrypt degene die de kar daadwerkelijk trok. Die heeft ooit 90 dagen gekozen (wat ik een heel redelijke termijn vind) en wordt pas nu door het CA/B ingehaald.

En dat allemaal omdat Apple het wilde. Die nauwelijks enige rol van betekenis heeft in online diensten...

We overleven het wel, ik vind het vooral irritant dat ik mijn "renewBefores" moet gaan aanpassen.

[laurxp]

ik vind het vooral irritant dat ik mijn "renewBefores" moet gaan aanpassen.

Je kan het natuurlijk ook zo instellen dat het een renewal doet als het op 2/3e van de geldigheidsduur zit, dan hoef je het nooit meer aan te passen. Of je maakt gebruik van ACME ARI, dan heb je er helemáál geen omkijken meer naar.

[Keypunchie]

Zie andere thread. Certificaten zitten niet alleen in webservers. Niet elk systeem kan zomaar op elk moment nieuw certficaat inladen zonder impact.

Sommige SLA's zijn heel specifiek qua tijdstippen.

[laurxp]

er zijn ook andere systemen met certificaten die net iets meer impact ervaren

En die zijn nou precies de reden dat ze het terug brengen. Het hele doel is om de makers van zulke systemen te dwingen om automatische vernieuwing net zo pijnloos te maken als bij webservers. Als de enige manier van vernieuwing een handmatige ingreep is bij duizenden individuele apparaten via een Java-applet die alleen nog in IE 6 werkt, dan kan je het óók niet snel vervangen als er een keer een serieus incident is.

[Keypunchie]

Het gaat niet om moeilijk, het gaat om performance/uptime. Ik heb sommige diensten die niet supersnel opstarten, mTLS gebruiken (dus proxy ervoor is ook niet trviaal) en een herstart nodig hebben bij nieuw certificaat.

Dus, als ik 2x zo vaak moet opstarten, dan wordt mijn SLA wel geraakt...

Maar gelukkig heb ik nog onderhoudswindows... Maar dan moet ik dus slim spelen met renewbefore (of renewbefore heel laag zetten en een eigen renewal trigger automatiseren... Kortom, het kan allemaal wel, het is alleen veel gedoe, voor weinig winst voor mij.

[Reactie gewijzigd door Keypunchie op 9 oktober 2026 23:23]

[gorgi_19]

Het gaat er niet om hoe vaak.
ALS het gebeurd, wil je de schade zo klein en beperkt mogelijk hebben.

[dasiro]

certificaten zijn een validatiemethode waarop systemen kunnen vertrouwen of zelfs afhankelijk zijn. Als je een certificaat nodig hebt om een vpn-tunnel te leggen, dan zal dat niet meer lukken als dat verlopen is en wordt het nutteloos, maar als je dat in handen hebt dan zit je alweer wacht dichter bij de toegang. Tegenwoordig zijn er zoveel supply-chain en proxy-aanvallen dat je er echt wel aandachtig moet zijn voor sporen van pogingen of probes, want ook een mislukte poging kan een hint zijn naar hoe je dan wél zou kunnen binnen/verder raken.

[SuperDre]

Zelden. En aangezien iedereen gewoon automatisch deze certificaten kan aanvragen heeft het eigenlijk geen echt toegevoegde waarde meer, want ja, de verbinding mag dan redelijk veilig zijn, maar er is niemand die handmatig controleert of degene waar die mee communiceert wel degene is met wie ze wilden communiceren.

[CAPSLOCK2000]

Hoe vaak komt het eigenlijk echt voor dat certificaten worden gestolen? Of wordt er nu van alles opgetuigd / op de hals gehaald voor iets wat eigenlijk een fictief probleem is?
(en dan bedoel ik niet het scenario dat een CA plotseling stopt ofzo)

Het komt niet vaak voor, maar als het gebeurt kan de impact enorm zijn, zeker als het een certificaat is van een grote partij als MS of Google (en dat is echt voorgekomen).

Dat we er niet vaak over horen komt mede doordat we al jaren bezig zijn met dit probleem en er een hoop maatregelen zijn getroffen om diefstal tegen te gaan, te detecteren en er op te reageren waardoor het minder makkelijk en aantrekkelijk is geworden om die certificaten te stelen.

[laurxp]

Dit doen ze niet voor de directe veiligheid! Bij een incident met een gestolen certificaat is iedere dag dat het geldig blijft catastrofaal, dus een certificaat dat na een incident twee maanden geldig blijft is net zo onacceptabel als een certificaat dat nog een jaar geldig is.

Denk maar aan een partij als de ING: zou jij nog online bankieren als er de komende twee maanden een realistische kans is dat iemand de verbinding aan het MitMen is?

Het daadwerkelijke doel is dat veel grote organisaties een enorme laag van bureaucratie rond het certificaatvervangingsproces hebben gebouwd. Als een certificaat een jaar geldig is, is het niet héél problematisch om eerst vijf stakeholder meetings te hebben, en om de uitrol over de kerst deployment freeze heen te tillen. Je weet een jaar van tevoren wanneer het vervangen moet worden, dus een proces dat een maand of drie duurt is geen enkel probleem.

Totdat er een keer een veiligheidsincident is. Zoals eerder genoemd: iedere dag dat een gestolen certificaat bruikbaar blijft is er één te veel, dus je moet zo'n certificaat direct intrekken. Maar dan is het certificaat ook voor de legitieme eigenaar onbruikbaar, dus die willen het intrekken uitstellen totdat de certificaten vervangen zijn. Wat dus maanden kan duren...

Door de geldigheidsduur te verkorten dwingen de CAs hun afnemers om het vervangingsproces te stroomlijnen - en zelfs volledig te automatiseren. Een proces met drie maanden aan bureaucratie is onmogelijk als het certificaat maar twee maanden geldig is, en een proces met één maand aan bureaucratie is héél pijnlijk als ze binnenkort maar 45 dagen geldig zijn.

De kortere geldigheidsduur was niet nodig geweest als iedereen gewoon gelijk vrijwillig was overgestapt naar volautomatische vervanging via ACME. Maar blijkbaar luisteren grote organisaties niet naar een vriendelijk verzoek, dus moeten ze gedwongen worden.

[BlaTieBla]

Totdat er een keer een veiligheidsincident is. Zoals eerder genoemd: iedere dag dat een gestolen certificaat bruikbaar blijft is er één te veel, dus je moet zo'n certificaat direct intrekken.

Hoeveel browsers ken jij die standaard de CRL (of OCSP) controleren op ingetrokken certificaten? Voor zover ik weet doet niet 1 moderne browser dat. Hoogstens is er een ingebouwde lijst met ingetrokken Root/intermediate CA's die de browser controleert.

Dat intrekken heeft alleen zin als je hele ecosysteem ook daadwerkelijk er gebruik van maakt. Er zijn omgevingen waarbij je eerst moet intrekken om uberhaupt een certificaat te kunnen krijgen op basis van hetzelfde certificate subject, maar dat is niet overal het geval.

[The Zep Man]

Er zijn geen perfecte manieren om certificate revocation te implementeren. Iedere oplossing die geïntroduceerd is over de jaren heen heeft wel problemen. Het is niet overal uniform toe te passen.

Certificaten met een kortere levensduur beperken het veiligheidsrisico. Of een certificaat ingetrokken is kan men een hele discussie over voeren (gebaseerd op wat, hoe verifieer je die constatering, etc.). Of een certificaat verlopen is kan iedereen voor zichzelf als feit vaststellen, omdat van een verifiërend systeem geacht wordt dat die een gesynchroniseerde klok heeft. De hele wereld draait onderhuids op UTC, dus de klokken staan overal gelijk. Daar is geen ruimte voor discussie.

[Reactie gewijzigd door The Zep Man op 9 oktober 2026 16:15]

[Roberto4646]

"De hele wereld draait onderhuids op UTC, dus de klokken staan overal gelijk. Daar is geen ruimte voor discussie. :)"

Was het maar zo'n feestje. Eigenlijk is het permanent niet waar zelfs. Als eerste draait een groot deel van de wereld op Epoch en NIET op UTC. Veel ICT'ers halen die 2 inderdaad heel gemakkelijk door elkaar.

UTC is een tijdsysteem/tijdzone systeem met afspraken maar geen tijd, terwijl Epoch een nulpunt en telling is, dat zijn echt 2 verschillende referenties.

Uiteindelijk is de referentie Epoch en vanuit daar kunnen we een UTC tijdzone offset doorvoeren en dan kom je uiteindelijk op een tijd uit. Maar UTC zelf draagt geen tijd-referentie, alleen een offset referentie die refereert aan een tijdzone.

Ik vermoed dat hier weinig discussie over mogelijk is.

[elmuerte]

[UNIX/POSIX] Epoch is alleen een nulpunt, gedefinieerd als 1970-01-01T00:00:00.000 UTC (toen nog GMT). Je kan tijd uitdrukken in units sinds epoch (veel voorkomende units zijn secondes en milisecondes, met en zonder fracties), en dat wordt [UNIX/POSIX] Time genoemd. Subtiel detail, [UNIX/POSIX] Time is tijd zonder schrikkelseconde, dus je kan er nog wel eens een beetje naast zitten met een conversie: Wikipedia: Unix time

We hebben wel veel meer epochs in de computer wereld: Wikipedia: Epoch (computing)

Verder heeft UTC wel degelijk een tijdreferentie, bouwt voort op de TAI: Wikipedia: International Atomic Time

Maar ongeacht wat je gebruikt

klokken staan overal gelijk

is in ieder geval niet waar, en een hele gevaarlijke aanname als je met meerdere systemen werkt. Het is hopelijk "ongeveer" gelijk. Als tijd echt belangrijk is in een een gedistribueerd systeem dan gebruikt men een Lamport klok of iets vergelijkbaar. Dat is geen klok die tijd aangeeft, alleen dat er een verandering in gebeurtenissen is geweest.

[CH4OS]

Oef, gedurfde uitspraak wel, hele wereld over op UTC tijdzones (al dan niet onderhuids)... Was het maar zo'n feest.

[Reactie gewijzigd door CH4OS op 9 oktober 2026 16:19]

[zalazar]

Het gaat er om dat de revocation van certificaten niet goed of niet betrouwbaar werkt (CRL en OSCP). Vandaar dat ze de tijd zo kort mogelijk willen houden.
Als een certificaat gelekt is dan kan het maar een beperkte termijn gebruikt worden.

De korte termijn van 47 dagen geldigheid gaat gelden voor alle certificaten, dus ook die van andere CA's. Het probleem is wel dat ze hiermee organisaties dwingen om het te automatiseren maar het zijn vaak niet alleen webservers maar ook veel andere applicaties die certificaten gebruiken.
De software en het hele implementatietraject dat hiervoor nodig is kan ontzettend in de kosten gaan lopen.

Het CA/Browser Forum heeft dit zo besloten en het zijn vooral Google, Mozilla en Apple die dit er doorheen gedrukt hebben. Maar dat zijn uiteraard niet de partijen die de factuur hiervoor gaan betalen. Dat is wel heel makkelijk beslissen zo.

[Reactie gewijzigd door zalazar op 9 oktober 2026 16:29]

[Nibblebit]

Door Quantum Computing is het sneller mogelijk om certificaten te kraken. Door de geldigheidsduur van certificaten te verkorten, geef je de nieuwe technologie minder tijd om dit te doen. Handmatig certificatenwisselen wordt steeds arbeidsintensiever en daarom wordt over gestapt op certificaat automation waar dat nog niet is gebeurt.

[BlaTieBla]

Als je 'gewoon' alle versleutelde data afvangt heb je tijd genoeg om op je gemak de encryptie te kraken. Het is niet altijd noodzakelijk om de data in (near) real-time te ontsleutelen.

[eagle00789]

dat wordt wel erg kort voor die DNS authorisatie van slechts 7 uur, gezien het feit dat het soms toch 24 uur kan duren...... ook al staat de TTL van je DNS records erg laag.....

[laurxp]

Als dat een probleem is in jouw omgeving kan je er ook voor kiezen om de authorisatie via DNS-PERSIST-01 te doen: dat is een DNS record dat je niet iedere keer aan hoeft te passen.

[lenwar]

Die DNS-authorisatie maakt een nieuw record aan. (een TXT-record). Dat moet 'vrijwel direct' (30-40 seconden max) beschikbaar zijn, aangezien de status van die records niet gecached kan zijn.

Van 30 dagen naar 7 uur betekend in de praktijk dat dit 'geautomatiseerd' gedaan moet worden. (dus niet met de hand in een web-interface records in elkaar copy-pasten.)

[ZinloosGeweldig]

De DNS-authorisatie hergebruikt elke keer hetzelfde subdomein: _acme-challenge. Die is dus niet altijd nieuw.

TTL zou daarbij dus wel van toepassing zijn, ware het niet dat de DNS-01 challenge standaard de authorative nameservers bevraagd. En daar heb je enkel te maken met de propagatie tijd over (meestal anycasted) DNS servers van je DNS provider. TTL is er als instructie voor niet-authorative resolvers.

[Blokker_1999]

Het zijn bijkomende records onder de _acme-challenge voor zover ik mij kan herinneren, dus elke keer heb je wel degelijk andere records. Caching is geen probleem.

[ZinloosGeweldig]

De challenge zelf is telkens verschillend, en je kan er meerdere tegelijk hebben, maar het domein is altijd _acme-challenge en het type TXT en TTL is van toepassing op een RRset (dat is domein+type) en niet op individuele records. Daarom kun je ook geen verschillende TTL geven aan records van hetzelfde subdomein+type.

Caching is geen probleem omdat de authorative nameservers bevraagd worden, niet omdat het een nieuw record is, want het is een record in een bestaande RRset.

[Reactie gewijzigd door ZinloosGeweldig op 10 oktober 2026 12:36]

[Aftansert]

TTL heeft hier niets mee te maken. De TTL van een DNS-record bepaalt hoe lang tussenliggende DNS servers (bijvoorbeeld die van ISPs) het record cachen. Niet hoe lang het duurt voor de authoritative server om een wijziging toe te passen. Overigens wordt de TTL vaak genegeerd.

LetsEncrypt bevraagt altijd de authoritative server, niet een cache. Als je DNS-provider er meer dan 7 uur over doet om een wijziging door te voeren lijkt me dat wel een probleem. Ik kan me eigenlijk niet voorstellen dat dat überhaupt bestaat. Als het tegenwoordig meer dan 30 seconden duurt vind ik dat al vervelend.

[Reactie gewijzigd door Aftansert op 9 oktober 2026 15:12]

[ThaStealth]

Zijn letsencrypt certificaten vergelijkbaar qua veiligheid/aanzien als certificaten van de grote boeren zoals Sectigo bijvoorbeeld? Voor thuis gooi ik alles op LetsEncrypt, maar is dit ook voor productieomgevingen?

[Blokker_1999]

Tuurlijk? Het is identiek dezelfde technologie die er onder zit.

[laurxp]

De techniek is wellicht hetzelfde, maar dat zegt natuurlijk niks over de interne procedures. Een certificaat van Honest Achmed's Used Cars and Certificates is weldegelijk een stuk minder veilig, en je wil liever wel iets van een partij waarbij de zaakjes iets beter op orde zijn dan "Trust me, bro!".

[Blokker_1999]

Dat is letterlijk hoe heel de certificaatwereld werkt. Vertrouwen dat de root CA zich goed gedraagd en dat elke sub CA netjes de regels volgt. Er is vanaf dat moment geen enkel verschil tussen een Globalsign of Achmed. Als die een chain of trust hebben naar een root CA is het veilig. Punt.

En ja, soms loopt het mis, denken we maar aan Diginotar. En ja, er zijn al root CAs omgevallen omdat ze uiteindelijk niet te vertrouwen waren. Maar op het einde van de dag worden er beslissingen genomen en werkt heel de CA wereld net op dat vertrouwen, wat nooit 100% objectief is.

[Nibblebit]

Goeie vraag - het hangt vooral van de eigen CA-organisatie af en hoe goed ze alles voor elkaar hebben (beschikbaarheid, tooling en niet in de laatste plaats beveiliging). Als je het verpest lig je er uit. Zoek nog even op DigiNotar.

[laurxp]

Ja, technisch is er geen enkel verschil. Sterker nog, omdat bij LetsEncrypt alles volledig automatisch en open is, is de kans kleiner dat er iets mis gaat door handmatig broddelwerk - zoals in de praktijk met enige regelmaat het geval is bij de "professionele" partijen.

Qua aanzien is er nog wel een verschil, maar sinds browsers geen groot groen logo meer gebruiken voor EV certs is dat langzaam aan het verdwijnen. Bedrijven als Sectigo zullen natuurlijk een hoop aan FUD blijven doen om managers te overtuigen dat hun businessmodel nog bestaansrecht heeft, maar over de jaren heen begint dat steeds minder geloofwaardig te worden.

[deadinspace]

Zijn letsencrypt certificaten vergelijkbaar qua veiligheid/aanzien als certificaten van de grote boeren zoals Sectigo bijvoorbeeld?

Het korte antwoord is: ja.

De certificaten zelf valt niet veel aan te verprutsen, die voldoen aan de zelfde cryptografische voorwaarden als andere certificaten, en Let's Encrypt kan jouw certificaat niet lekken (of eigenlijk: ze kunnen het certificaat wel lekken maar dat heeft geen gevolg, de private key kunnen ze niet lekken).

De belangrijkste vraag is of Let's Encrypt hun controles wel goed doet en niet een certificaat voor jouw domein aan iemand anders geeft. Maar dat probleem is door jou niet te voorkomen door een andere certificaatboer te gebruiken.

Op Stack Exchange kun je dit uitgebreide antwoord lezen waarin in detail uitgelegd wordt hoe certificaten werken, en hoe Let's Encrypt daarin past.

[ZinloosGeweldig]

- Als ik, als server, een Let's Encrypt certificaat gebruik, zijn de TLS sessies die ik hiermee start even vertrouwelijk als met een certificaat van Sectigo?

Zolang je goed omgaat met je private key, ja.

- Als ik, als client, een certificaat zie voor domeinnaam example.com uitgegeven door Let's Encrypt, heb ik dan evenveel zekerheid dat ik echt met de eigenaar van example.com te maken heb, als wanneer ik een OV certificaat van Sectigo zie?

Waarschijnlijk niet nee.

[BlaTieBla]

Qua techniek zijn ze hetzelfde. Het verschil zit 'm in de garanties e.d. Bij een commerciele certificaat leverancier is er vaak een verzekerd bedrag in het geval er zaken fout gaan (bij de certificaat leverancier). Ook kunnen ze bij bepaalde diensten een helpdesk hebben die je kan bellen. Het verschil zit 'm dus vooral in het circus er om heen.

En vroegah gaf het gebruik van bepaalde CA's ook nog iets extra's in de vorm van speciaal gekleurde URL balken in een browser.

Voor een oplossing als Let's Encrypt/ACME is dat allemaal overhead.

[Tjidde]

Met het verkorten van certificaten, wanneer gaan ze 6 dagen forceren? En komt er een punt er zelfs een certificaat is die nog korter is?

Want als je certificaten lekken wil je natuurlijk zo'n kort mogelijke lifecycle.

[Reactie gewijzigd door Tjidde op 9 oktober 2026 15:54]

[ocn]

Uiteindelijk zullen we er gewoon naartoe gaan dat certificaten steeds korter geldig zijn. 6 dagen of korter is uiteraard beter. Nog beter zou zijn om de afhankelijkheid van certificaatproviders helemaal af te bouwen door over te gaan op technieken zoals DANE.

De combinatie van ultra-korte certificaten + ACME-automatisering en DANE via DNSSEC is technisch gezien het meest robuuste en gedecentraliseerde model. Maar zolang de grote browserleveranciers vasthouden aan het CA-model met Certificate Transparency, blijft DANE voor de reguliere HTTPS-website een belofte, terwijl het in de e-mailwereld al werkelijkheid is.

http://stats.sidnlabs.nl/nl/mail.html#dane

[Reactie gewijzigd door ocn op 9 oktober 2026 16:21]

[CH4OS]

Mooiere oplossing is om persoonlijke TLS certificaten te hebben die ook nog eens kort geldig zijn. Maar dat is niet te implementeren vanwege de aard van HTTP (wat vooral een zend medium is).

[ocn]

Voor email werkt dat dus zo, self-signed TLS certificaten. Met DANE. Alleen zijn ze doorgaans niet kort geldig :-) Als de browsers ondersteuning voor DANE zouden implementeren werkt dat ook prima voor web.

[Bleak]

Je kan met letsencrypt ook al gebruik maken van shortlived certicates deze zijn 6 dagen geldig. https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability Heb dit nu zelf via SWAG docker draaien en werkt perfect.

[ibmpc]

Waarom 64 dagen en niet gewoon 1 uur of 1 minuut? Je wil toch juist de certificaatgeldigheid op de kortst mogelijke tijd?

[pixelsnader]

Omdat je dan als er een outage of vertraging is bij 1 van de 3 tussenliggende servers, of jouw specifieke aanvraag loopt spaak, geen nieuw certificaat gegenereerd kan worden en je site dus binnen no-time onveilig wordt verklaard.

[mr.sky]

We gebruiken Certify The Web met 45-daagse certificaten die automatisch worden vernieuwd en via een API naar de WAF/firewall worden uitgerold. Als je certificaatbeheer goed hebt geautomatiseerd, maken 90, 64 of 45 dagen in de praktijk weinig verschil.

[laurxp]

Klopt, maar jij bent een kleine vis in een grote zee. Jouw certificaat leeft in hetzelfde ecosysteem als een certificaat voor een partij als de ING. In jouw geval is het niet zo héél erg als iemand de verbinding naar je persoonlijke blog-website kan MitMen of als die blog er door een revocation een paar dagen uit ligt, maar dat is daar een héél ander verhaal.

Bedrijven gaan (uiteraard) shoppen naar de CA die het minst moeilijk doet, dus de enige manier om het voor iedereen veilig te houden is door dezelfde regels voor iedereen toe te passen - en dus jouw website te behandelen alsof die net zo kritiek is als die van de ING.

En als er grote dingen op het spel staan, blijkt dat het ineens wél nodig te zijn om het handje vast te houden van zulke bedrijven, want als ze moeten kiezen tussen gegarandeerde reputatieschade of een potentieel veiligheidsincident blijkt dat ze vaak kiezen voor de onveilige optie. Zelfde met grote investeringen versus een potentieel veiligheidsincident.