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 (9)

[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.

[The Zep Man]

Er zijn geen perfecte middelen 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:05]

[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.....

[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]

[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.

[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]