Let's Encrypt heeft voor het eerst TLS-certificaat van zes dagen uitgegeven

Let's Encrypt heeft voor het eerst een kortdurend certificaat uitgebracht. Het gaat om een certificaat dat het bedrijf voor zichzelf uitgaf en direct weer introk. Let's Encrypt wil de uitgifte vanaf april ook voor testers beschikbaar maken.

Let's Encrypt zegt dat het zijn eerste certificaat heeft uitgegeven dat slechts zes dagen geldig was. Het bedrijf verwijst naar de logfiles waarin het certificaat te zien is. Het is het eerste kortdurende certificaat dat het bedrijf heeft gemaakt. Normale TLS-certificaten van Let's Encrypt hebben een levensduur van negentig dagen, maar Let's Encrypt kondigde in 2024 aan dat het ook kortdurende certificaten gaat aanbieden. Het bedrijf zei later al dat het de eerste interne certificaten in februari wilde aanbieden.

Het eerste certificaat werd uitgegeven op Let's Encrypts eigen systemen en 'direct weer ingetrokken', zegt het bedrijf. "Zo kunnen we de hele levenscyclus van het certificaat observeren." Let's Encrypt noemt het de eerste stap richting het beschikbaar maken van kortdurende certificaten aan alle gebruikers.

Het bedrijf wil vanaf het tweede kwartaal van 2025 de eerste kortdurende certificaten beschikbaar maken voor 'een kleine groep gebruikers'. Het bedrijf zei eerder al dat het eind 2025 de kortdurende certificaten breed beschikbaar wil maken. Die komen overigens naast bestaande certificaten te bestaan en zullen geen vervanging worden van certificaten met een levensduur van negentig dagen.

Reacties (78)

[Pathogen]

Ik begrijp nog steeds niet waarom het veiliger is om elke keer een ander certificaat voor je neus te krijgen... Alles leuk en aardig dat je een geldig certificaat presenteert, maar ik heb een week later eigenlijk geen zekerheid meer dat ik met dezelfde partij aan het praten ben.
En tegen de tijd dat het probleem boven water is, wéér een ander certificaat.

Eigenlijk promoot dit vooral blind vertrouwen in het systeem, want geen mens die dit gaat bijhouden. Als er dan iets tussen glipt, niemand die het meer weet of kan identificeren.

[laurxp]

ik heb een week later eigenlijk geen zekerheid meer dat ik met dezelfde partij aan het praten ben.

Oftewel, precies hetzelfde als nu. In theorie kan ieder domein op ieder moment verkocht worden aan een andere partij en - volstrekt legitiem - een andere server opzetten en nieuwe certificaten aanvragen. De duur van de certificaten is daarvoor irrelevant.

Eigenlijk promoot dit vooral blind vertrouwen in het systeem, want geen mens die dit gaat bijhouden.

Hou jij momenteel dan handmatig de certificaten bij van alle websites die je bezoekt? Er is niemand die dat doet, dat is juist het hele punt van een CA als trusted third party.

In de praktijk zijn kortdurende certificaten juist veiliger, want bij iedere renewal zal de CA controleren dat jij nog steeds de eigenaar bent van dat domein. Mis-issuance is te voorkomen met technieken als CAA en verplichte registratie in onafhankelijke CT logs, en met kortdurende certificaten zijn er óók nog eens minder risico's van gestolen certificaten.

[fastedje]

Ik maak me altijd veel meer zorgen over de CA private key: deze zijn niet langer of veiliger dan keys die aanvragers gebruiken, maar zijn wel altijd jaren geldig. Als een aanvaller al quantum computer tijd inhuurt dan kan deze het best besteed worden aan het kraken van CA keys.

[Yzord]

Leg mij eens uit welk vertrouwen (die je zoekt) wel had bij de 90 dagen certs? Je weet nog steeds niet of het bedrijf genuine is. Want het vertrouwen ligt volledig bij LE en die vertrouwde je al, toch?

Ik vind het ook onzin hoor, een 6 dagen cert, maar ze zullen er wel over nagedacht hebben. Als het maar niet de huidige vervangt want ik heb geen behoefte aan een wekelijkse cert (en dus wekelijks de mogelijkheid dat er iets mis gaat met renewen).

[Frame164]

Hoe korter het geldig is hoe veiliger. Als jij ieder dag het slot van je huis vervangt kan iemand stiekem een afdruk maken van jouw sleutel maar tegen de tijd dat die nagemaakt is heb jij al een ander slot. Precies hetzelfde met kortlopende certificaten.

[xSNAKEX]

De vergelijking met het slot gaat sowieso mank. Het gaat namelijk om vertrouwen en vertrouwen groeit meestal juist met de tijd. Ook al gaat die vergelijking niet helemaal op sluit het denk ik wel beter aan bij zowel de werkelijkheid als bij het gevoel wat @Pathogen heeft.
Ik zou liever langer lopende en niet direct werkende, beter gecontroleerde certificaten zien dan een simpele vaak herhaalde snelle procedure die geautomatiseerd is.

[goosehunt]

Ok bij een fysiek slot gaat het om vertrouwen. Je kijkt daar namelijk toch ook aan wie je de sleutel geeft?

Maar je wil dus zekerheid dat de rechtmatige sleutel gebruikt wordt door de rechtmatige houder ervan.
En niet een kopie door een onbevoegde.

Daar is dus de CA voor. En het regelmatig wisselen met controle op de eigenaar zorg je ervoor dat een eventueel gestolen sleutel niet lang te misbruiken is.

[xSNAKEX]

Maar die controle bestaat dus uit bijna niets, dus het voegt niet echt iets toe. En als een bedrijf elke week van naam veranderd al dan niet met een veilig thuiswinkel kenmerk, dan kan ik me zo voorstellen dat je twijfels hebt bij de legitimiteit van het bedrijf.

[Antiloop]

Jullie praten over verschillende dingen, het (geldige) SSL certificaat zegt niets over de betrouwbaarheid van het bedrijf an sich, het zegt alleen iets over de betrouwbaarheid van de verbinding

[xSNAKEX]

Het zegt ook niets over de betrouwbaarheid van een slot. Dat noemen we een vergelijking om iets duidelijk te maken betreffende je standpunt in een discussie.
En mijn punt is dat de regelmatige vernieuwing gezien de simplistische procedure geen extra zekerheid geeft.

[Yzord]

Ik snap het idee wel. Als ik elke dag mijn ww op al mijn accounts kon veranderen en dus kon automatiseren (hmm, er bespringt me een idee) dan voelde ik me ook een stuk veiliger.

[fastedje]

Er is niemand die controleert dat je daadwerkelijk een nieuwe sleutel gebruikt, alleen dat je een nieuw certificaat hebt aangevraagd. Dus heel veel veiliger gaat niet altijd op.

[xFeverr]

Die korte certificaten zullen de standaard worden verwacht ik. En het vernieuwen van certificaten zal een dag of 2/3 vantevoren al beginnen zodat je een buffer hebt voor als er iets fout zou gaan.

Alles is zo goed geautomatiseerd dat ik me er niet druk om maak.

[ZinloosGeweldig]

Ik begrijp nog steeds niet waarom het veiliger is om elke keer een ander certificaat voor je neus te krijgen... Alles leuk en aardig dat je een geldig certificaat presenteert, maar ik heb een week later eigenlijk geen zekerheid meer dat ik met dezelfde partij aan het praten ben.

In principe zijn short-lived secrets (of dit nu een token of een private key is) altijd robuuster tegen heimelijke ontvreming hiervan.

Het gaat niet zozeer om een hogere mate van zekerheid voor u als bezoeker, Maar er is wél "iets" meer zekerheid voor de bezoeker. Een certificaat dat in de afgelopen 6 dagen is uitgegeven vertelt mij dat ik óf met de legitieme eigenaar van het domein te maken heb, óf dat er een AITM aanval met een in de afgelopen 6 dagen uitgelekte PK wordt uitgevoerd.

Een certificaat dat in de afgelopen 90 dagen is uitgegeven vertelt mij dat ik óf met de legitieme eigenaar van het domein te maken heb, óf er een AITM aanval met een in de afgelopen 90 dagen uitgelekte PK wordt uitgevoerd.

In het tweede geval is het scenario waarin er tóch een aanval uitgevoerd net iets waarschijnlijker. Vergelijken of het certificaat dat je aantreft op een website dezelfde is als de vorige keer is een zinloze exercitie. Enkel een specifiek certificaat accepteren heet certificate pinning en doe je enkel in situaties waar je controle hebt over zowel client als server (en dus certificaat).

[Reactie gewijzigd door ZinloosGeweldig op 22 februari 2025 11:36]

[Nightan]

Er is een achterliggende reden waarom certificaten een steeds kortere levensduur hebben: de mogelijke dreigingen van een CRQC (Cryptographic Relevant Quantum Computer). Deze tendens faciliteert namelijk 'crypto agility' om in principe automation via ACME te forceren.

Als websites namelijk eenvoudig en automatisch van certs kunnen switchen, dan zijn de onderliggende cryprografische primitieven eenvoudig te veranderen van bijvoorbeeld klassiek ECDSA/RSA naar PQC-proof ML-DSA.

Microsoft heeft deze week een aankondiging gedaan met hun Majorana-1 chip in navolging van Google's Willow. Daar zitten nog veel haken en ogen aan, maar geeft wel aan dat de wereld zich moet voorbereiden voor de steeds realistischer wordende quantumdreiging.

[tjanssen]

Waarom dan geen 7 dagen? Dan valt de renewal tenminste altijd op een vaste (werk)dag.

[himlims_]

nofi - maakt dat ook maar iets uit? loopt toch volledig geautomatiseerd. of nu 3-7-30-90 dagen is [..] doe je toch niet handmatig?

//edit;
misschien is mijn insteek wat kort door de bocht; maar voor zakelijk projecten, essentiële diensten of “belangrijke klanten” kies je toch al snel gebruik van een (commerciële) certificaat boer(?) die investering valt mee, daarbij zelden issues ervaren.

Voor particulieren/hobbyproject/low budget pagina (zzp)/lokale bridge-vereniging is een certificaat via LetsEnceypt toch perfect?

Ligt die er een keertje uit omdat automatisch vernieuwen op een zondag faalt, is de impact toch beperkt? Dan los dat later wel op.

Handmatig certificaten koppelen, activeren is toch niet meer van deze tijd? Heb dat vaak uitbesteed aan tools/scripta/cron job, zoals “nginx reverse proxy manager”

Althans, zo ervaar ik het. Misschien wat te kort door de bocht?

[Reactie gewijzigd door himlims_ op 21 februari 2025 18:50]

[SlasZ]

Ik gebruik letsencrypt thuis samen met een domein van noip, en die moet ik handmatig updaten. Als ze geen certificaten van 3 maand meer gaan aanbieden moet ik uitkijken naar iets anders

[Hatsjoe]

Je kan met noip gewoon de HTTP-01 challenge gebruiken om je validatie te automatiseren. Je hoeft dan niks met de hand te doen.

[Paul]

Alleen als die website open staat naar het internet Of misschien juister, als er een website op die naam benaderbaar is vanaf het internet (je kunt de challenge-response op een ander systeem doen dan waar het certificaat uiteindelijk op terecht komt, als je dat zou willen).

Het voordeel van LE in je home lab gebruiken is dat je niet alle computers af hoeft om je eigen root te installeren. Het nadeel is dat de automatische processen je domeinnaam willen challengen.

[Hatsjoe]

Wanneer je zaken waarvoor je LE gebruikt niet publiekelijk benaderbaar wilt maken, dan is de oplossing ook simpel. Koop een goedkoop domein en gebruik de DNS-01 challenge ipv HTTP-01. Die 5-10 euro per jaar wat een domein kost is mij het dubbel en dwars waard om niet handmatig om de X tijd mijn certificaten te updaten.

[Barsonax]

DNS-01 is idd de manier. Ik gebruik dat om vanuit een k3s cluster automatisch de certificaten te updaten. Geen omkijken meer naar.

Maar goed kom zelfs grote bedrijven tegen waar men denkt dat HTTP-01 de enige mogelijkheid is. Zo zie je maar dat een eigen homelab opzetten je nog wel eens van kennis kan voorzien die je anders op werk niet zomaar krijgt.

[InjecTioN]

Een HTTP-01 validatie is minstens net zo effectief en veilig als een DNS-01 validatie. Daarnaast heb je er geen eigen betaalde domeinnaam voor nodig, wat voor een home lab erg interessant kan zijn. duckdns.org biedt daarbij ook een prima gratis alternatief als Dynamic DNS.

Poort 80 open zetten voor unencrypted HTTP verkeer is absoluut geen goede oplossing. Als er echter geen dienst op poort 80 luistert buiten de certificaatvernieuwing voor Let's Encrypt (certbot), is er geen risico op ongeautoriseerde toegang. Zonder een actieve luisterende service wordt een verbindingspoging simpelweg geweigerd, wat betekent dat er niets is om aan te vallen.

Dit is veilig omdat:

• Geen luisterend proces = geen aanvalsvector: Er is geen server-applicatie die een request kan verwerken of misbruikt kan worden.
• Poortscans laten poort 80 als 'closed' zien: Omdat er niets luistert, wordt de poort als "gesloten" gerapporteerd in netwerktools zoals nmap.
• Geen exploitbare service: Veel beveiligingsrisico’s (zoals exploits of brute-force aanvallen) richten zich op kwetsbaarheden in actieve webservers, wat hier niet het geval is.

Er zijn een paar randgevallen waarin een firewallregel nog steeds nuttig kan zijn:

• Verminderen van poortscans: Sommige scanners kunnen je IP vaker scannen als poort 80 af en toe open lijkt te staan.
• Misconfiguratie voorkomen: Als er per ongeluk een webserver start en blijft draaien, is poort 80 niet meteen toegankelijk.
• Logreductie: Je voorkomt dat je netwerklogs onnodig gevuld worden met scanpogingen.

Maar functioneel gezien ben je net zo veilig zonder extra maatregelen, zolang er geen service actief is buiten de korte periode waarin Certbot draait. Als je extra paranoia wilt inbouwen, zou je alsnog met Fail2Ban of een firewallregel kunnen zorgen dat verkeer op poort 80 standaard wordt geblokkeerd en alleen geopend wordt wanneer Certbot draait. Maar dat is meer een "better safe than sorry"-aanpak dan een echte noodzaak.

[xFeverr]

Is het niet zo dat de http-challenge alleen bij de eerste keer over poort 80 loopt en daarna gewoon over SSL?

[InjecTioN]

Dat klopt deels. Je kan een verlenging uitvoeren met gebruik van een TLS-ALPN-01 challenge. De reverse proxy (nginx) zal dit daarbij wel moeten ondersteunen. Wanneer je bij het aanmaken van een nieuw certificaat `domain=example.tld ; certbot --tls-alpn-01 --nginx -d $domain -d www.$domain` als command gebruikt, dan zou certbot aanpassingen moeten maken aan de nginx configuratie. Zonder de `--tls-alpn-01` switch te gebruiken, dan gaat het simpelweg over poort 80 met nginx. Config wordt daar ook op aangepast.

Volgens mij kan je dit overigens ook simpelweg met TLS-ALPN-01 doen. Echter heb ik dat nog niet (hoeven) doen.

[monstertje.xyz]

HTTP-01 Kan ook super handig zijn overigens. *.domain.tld cname naar een well known ingress en je hebt dns + le zero config(le geeft dan natuurlijk geen wildcard maar per domein specifieke certs uit)

Soms is dns-01 beter maar voor beide oplossingen is wat te zeggen

[InjecTioN]

Een wildcard is eigenlijk alleen gemaakt voor gemak. Gemak zorgt echter juist voor een veiligheidsrisico. Een certificaat is namelijk een veiligheidsmaatregel die we gebruiken. Dat gebruiken we niet uit gemakzucht, maar uit noodzaak. Om in een certificaat niet specifiek af te vangen wat er nodig is, en daarmee de rest van de subdomeinen simpelweg niet uit te sluiten, creeer je juist een risico wat je initieel af wilt vangen: gebrek aan controle.

Wanneer je certbot gebruikt, is er namelijk geen noodzaak meer voor een wildcard. Iedere tennant/app/whatever die je aanmaakt, kan geautomatiseerd voorzien worden van een eigen certificaat. Zolang je dat maar bij laat houden.

[Reactie gewijzigd door InjecTioN op 21 februari 2025 18:35]

[monstertje.xyz]

Als je even leest wat ik schrijf... Ik heb het over een wildcard domain en juist niet een wildcard certificaat

[LOTG]

Ik gebruik de zelfde structuur met een DNS challenge maar dan moet ik dus elke keer bij mijn DNS provider met de hand die records aanmaken want ze supporten dat niet geautomatiseerd.

Het is jammer dat er voor dit soort lokale opties niet iets makkelijker is.

[carlpls]

acme-dns kan een oplossing bieden:

https://github.com/joohoi/acme-dns

Daarmee maak je eenmalig per (sub)domein waar je certificaten voor wil aanvragen een CNAME aan bij je DNS provider en handel je vervolgens de DNS-01 verzoeken zelf af via acme-dns.

Wel een kanttekening: het project is momenteel niet direct in een werkende staat, je moet wat PR's van Github zelf mergen om e.e.a. aan de gang te krijgen.

[maevian]

Zet je nameservers naar cloudflare, kost je niets en die hebben een goede API om alles te automatiseren.

[Hatsjoe]

Dan gebruik je Cloudflare of een andere gratis DNS provider welke een API heeft welke ondersteund wordt door certbot. Dan hoef je ook niet met de hand DNS records aan te maken.

[sfranken]

Iets als dogtag, of is dat te enterprise focused? (hier heb ik FreeIPA draaien, dus komt dat automatisch mee)

[synoniem]

Je kan een gratis dynamisch adres bij https://www.dynu.com/en-US/ nemen en je domeinen met een _acmechallenge naar dat adres verwijzen. Ik gebruik daar zelf de docker container van https://hub.docker.com/r/goacme/lego voor DNS-01 challenge maar TLS en HTTP worden ook ondersteund.

[Mirano]

DNS challenge, als je je domein bij cloudflare heb krijg je een gratis wildcard cert

[Rolfie]

Andere DNS provider nemen?

duckdns zou je naar kunnen kijken.

[moonlander]

Tot dat het niet meer werkt, zit je op zondag weer te hannissen.

[Waswat]

Als er iets mis gaat wil je het op een werkdag hebben.

[TomONeill]

Maar met die instelling: waarom dan niet elke dag? Dat is dan toch nog veel veiliger?

[joost00719]

Je renewed een aantal dagen van tevoren, zodat als het fout gaat, je nog handmatig kunt ingrijpen voordat alles offline gaat.

[RobertMe]

Ook met een aantal dagen van tevoren zijn er natuurlijk "risico's". In deze zul je dan een dag of 3 van tevoren renewen. Even een lang weekend (Pasen, Pinksteren, Kerst op donderdag/vrijdag of maandag dinsdag, 90% dat vrij heeft de vrijdag na Hemelvaartsdag) en je komt er na het weekend achter dat het certificaat niet vernieuwd is.

Uiteraard hoor je certificaten dan wel automatisch te vernieuwen. Maar dan nog, iets met wet van Murphy, alles dat fout kan gaan zal een keer fout gaan. Dus ook het hernieuwen van de certificaten, en als het dan in het weekend fout gaat heb je uberhaupt maar weinig tijd om te fixen, als er al tijd is en het geen "lang weekend" is. En ook daarvan zal Murphy dus zeggen dat het een keer voor komt, dat tijdens het weekend het hernieuwen mislukt.

Ergo: naast monitoring die je uiteraard moet hebben, moet je dan ook nog in het weekend acteren op die monitoring.

[Marve79]

Ja ach ik gebruik dit voor wat diensten die ik extern benader zoals Radarr en Sonarr. Als dat even niet werkt staat de wereld niet in brand. Een certificaat kopen en dan elk jaar vervangen vind ik ook niks. Dan kom je er vaak ook door schade en schande weer achter welke verlopen is. Ik zie dat bij bedrijven veel en daar is het vaak een certificaten hel. Opeens werkt er iets niet meer, oh kut certificaatje verlopen!

En je kunt natuurlijk gewoon logging aanzetten. Plus als het elke 6 dagen moet is de kans groter dat het blijft werken dan na 3 maanden of een jaar weer een keertje. Kans dat er tussentijds iets wordt gesloopt is groter.

[bantoo]

De doelgroep van deze certificaten is niet mensen die het met de hand doen

[wildhagen]

Dit soort certificaten vervang je doorgaans niet met de hand maar geautomatiseerd met tooling als die van Venafi bijvoorbeeld, dus dat is helemaal niet gebonden aan een vaste dag.

[bigtree]

Goede vraag, dat wilde ik ook wel weten. Dit is wat ik er over kon vinden:

I think "6 days" is a bit of a shorthand we've been using. We don't have a final value, but it might be 160 hours, which is 6 days, 16 hours. We are aiming to be under the 7-day limit per the CA/B Forum rules about what a "Short Lived" certificate is.(bron)

Het maakt eigenlijk niet uit of het 6 of 7 dagen is. Je zult het vernieuwen hiervan willen automatiseren. En je gaat zo'n certificaat heus niet op de laatste dag vernieuwen. De 90-dagen certificaten die ze nu uitgeven worden normaal gesproken zo'n 30 dagen voor de verloopdatum al verlengd. Dus de 6-dagen certificaten zullen waarschijnlijk na een dag of 3 al worden verlengd. Met dat in het achterhoofd heb je altijd nog wel een werkdag zitten tussen de verloopdatum en de dag waarop het certificaat al vervangen had moeten zijn.

[sfranken]

Sterker nog, certificaten van Lets Encrypt worden vaak helemaal niet handmatig verlengd, maar automatisch (via Certbot, bijvoorbeeld).

Je krijgt sowieso X tijd vooraf netjes een melding dat certificaat Y gaat verlopen.

[DataGhost]

Die meldingen gaan verdwijnen of daar zijn ze ondertussen misschien al mee gestopt. Monitoring moet je toch altijd zelf doen. Bijvoorbeeld als je renewal wel goed gaat maar je service niet het nieuwe certificaat gebruikt. Dan werkt de handel niet en krijg je een certificaatfout, maar had je geen melding gekregen dat het certificaat ging verlopen want die is netjes op tijd vernieuwd.

[sfranken]

Met de meldingen bedoel ik niet de email, die mag van mij vandaag nog de deur uit. Sorry, had ik ff wat duidelijker moeten zeggen.

Ik bedoelde de melding vanuit je monitoring pakket, of vanuit je OS (want timers loggen ook gewoon naar je systeempunt en daar kun je een melding van laten trekken)

[Tales]

Dat zal het doel zijn

Zat mensen die het nog steeds handmatig zullen doen als het elke maandag moet, maar als het elke week een dag eerder moet loop je vanzelf een keer vast.

[lenwar]

Het doel van dit soort certificaten zal ook niet in de renewal zitten, maar op het 'laten verlopen'.

Dit soort certificaten gebruik je primair voor kortlevende diensten. (denk aan een webserver die iedere dag opnieuw opgebouwd wordt met de laatste patches, of dat de instances ter plekke bijgezet worden wanneer het wat drukker wordt, of een testomgeving die 3 dagen moet draaien en dan vernietigd wordt.)

[xFeverr]

Een webserver die steeds opnieuw opgebouwd wordt heeft toch gewoon een stukje vaste configuratie (en ‘secrets’), waar ook het certificaat in staat? Anders begin je steeds zonder certificaat (en dus een korte tijd zonder goed werkende HTTPS) en het aantal aanvragen per dag is ook beperkt.

Dit gaat ook over langlopende diensten. Alles is geautomatiseerd dus het maakt helemaal niet uit dat het kortdurende certificaten zijn. Als er dan ergens iets mis gaat, bij LE of bij jou, dan is de schade behoorlijk beperkt. En dat is veiliger en geeft meer vertrouwen.

[lenwar]

Er zijn vele wegen naar Rome

Iedere dag (of om de dag) een nieuw (container)image met nieuwe certificaten bouwen en die dan naar je 400 webservers sturen of zo. Dat is natuurlijk slechts een idee, maar er zijn er tig te bedenken, waar je juist korte certificaten zou willen hebben. Ook hier zijn natuurlijk andere oplossingen te bedenken.

Uiteraard zou je het ook voor langdurige zaken kunnen gebruiken. Want ook daar zijn use-cases voor te bedenken. Voor als je bijvoorbeeld geen PFS kunt gebruiken, of als het identiteitsvervalsing een extreem groot ding is voor die dienst.

Maar ik denk dat we het er over eens kunnen zijn dat de meeste Tweakers het op hun thuis-spullen niet per se nodig zullen hebben

[sdziscool]

De admin werkt niet op zondag, zoals in de heilige CAO geschreven staat

[laurxp]

Precies, dat is het hele punt. Je wil dat niet op een vaste werkdag laten vallen, want dan bestaat er een (kleine) kans dat iemand dit als maandagmorgen taakje in de agenda krijgt. Door het op 6 dagen te stellen dwing je gebruikers om goede automatisering op te stellen, want de renewal kan dan op ieder moment gebeuren - ook als het even ietsje mindere goed uitkomt.

Gedwongen renewals wegens veiligheidsincidenten gebeuren toch ook niet altijd als iedereen tijd heeft en er klaar voor zit?

[Relaxations]

Geen idee, maar 2^19s is net iets meer dan 6 dagen, terwijl 2^23s net iets meer is dan 90 dagen is. Wellicht puur toeval, maar zou met aantal gealloceerde bits hiervoor te maken kunnen hebben...

[Muncher]

Kan iemand mij uitleggen waarom je deze kortdurende certificaten zou verkiezen boven de langdurende? Wat zijn de veelvoorkomende use-cases?

[wildhagen]

Minder kans op gecompromitteerde certificates (of complete chains). Daardoor minder attack surface.

Zo zijn er nog meer voordelen van dit soort 'short lived' certificates. Zie bijvoorbeeld https://www.appviewx.com/...-help-reinforce-security/ voor enkele voorbeelden

[PdeBie]

ok, maar 6 dagen??? Waarvoor? Voor een marketing-campagne op een "tijdelijke website" ofzo?

[hello123456]

Nee, voor het geval dat de private key van een website uitlekt en er gegevens zijn onderschept, dat de schade beperkt blijft. Op moment dat je het certificaat vernieuwd, is dat om de private key te roteren. Op die manier kan dus maximaal traffic van 6 dagen oud worden ontsleuteld in plaats van 90 dagen of in andere gevallen zelfs een jaar of nog langer.

Omdat tegenwoordig Let's Encrypt veelal door Certbot of Cert-manager geautomatiseerd wordt, zoals aangeraden, maakt het dus voor de hoster niet uit hoe lang een certificaat geldig is. Het script vernieuwd het toch zelf.

[PdeBie]

Aaah. Dank voor de verheldering!

Maar voorwaarde is dan inderdaad wel dat het vervangen geautomatiseerd gebeurt. Anders krijgt de sysadmin het druk

[Barsonax]

Handmatig is ook niet meer van deze tijd. Het gebeurt natuurlijk nog wel her en der.

Laatst nog gezien een certificaat dat tot 2030 geldig is, dat is geen best practice qua security.

Ipv die iedere keer handmatig te updaten met er gewoon tijd in worden gestoken dat te automatiseren. Echter loop je bij grote organisaties wel eens tegen andere (kromme) compliancy regels aan waardoor dat niet kan.

Wat dat betreft mag het ook wel gewoon eens kapot gaan zodat de urgentie wat hoger word.

[harrr]

Weet je nog welke provider dit was? Want bij het bedrijf waar ik werk krijgen we wel eens vraag naar certificaten met een geldigheidsduur van langer dan een jaar, maar wij kunnen ze niet meer krijgen.

We zien de opkomst van Let's Encrypt ook als oorzaak van het niet meer uitgeven van langdurige certificaten. Wat op zich ook een veilige gedachte is. Maar in de praktijk kun je natuurlijk een onderschept certificaat nog revoken.

[Barsonax]

Nee dat zit verborgen achter een ingewikkeld bedrijfsproces, wat eigenlijk ook de reden is dat dit niet automatisch kan. Veel regel gedoe. Het probleem is eigenlijk niet van technische aard.

[Reactie gewijzigd door Barsonax op 21 februari 2025 23:53]

[ZinloosGeweldig]

Want bij het bedrijf waar ik werk krijgen we wel eens vraag naar certificaten met een geldigheidsduur van langer dan een jaar, maar wij kunnen ze niet meer krijgen.

Het is technisch gezien nog steeds mogelijk om een certificaat met een geldigheid langer dan een jaar uit te geven.

Chrome, en sinds Chrome daarmee is begonnen ook veel andere gangbare browsers weigert echter certificaten van publieke CA's met een geldigheid van meer dan 398 dagen en uitgifte na 1 sept 2020.

Daarnaast zullen Chrome browsers die certificaten van publieke CA's die niet aan deze regel voldoen aantreffen dit aan Google terug melden, en kan het gevolgen hebben voor of Chrome die CA in de toekomst nog zal vertrouwen. Dus voor publieke CA's is 1 jaar max. tegenwoordig de standaard.

Voor private CA's zoals een eigen interne CA van een bedrijf, of bijv. PKIO certificaten, gelden deze regels niet.

En ja, de mogelijkheid tot revoken is er natuurlijk, maar er van uitgaan dat je elk security incident onmiddellijk detecteert is een beetje wishful thinking.

[Reactie gewijzigd door ZinloosGeweldig op 22 februari 2025 21:10]

[lenwar]

Maar voor wat je nu beschrijft (het ontsleutelen van 'oude data'), is Perfect Forward Secrecy bedacht. Al heb je private key, dan kun je toch niet de data van 'vroeger' ontsleutelen. (Je kunt je wel voordoen als een ander wanneer je de sleutel hebt.)

Voor iedere (netwerk)sessie, wordt er een nieuwe session key gegenereerd die niet opnieuw gegenereerd kan worden (gezien er ook een factor 'random' in zit aan beide kanten.)

Voor meer info: Wikipedia: Forward secrecy

Anyway
Die korte certificaten zijn in de praktijk primair handig voor tijdelijke diensten. (Een container die maar 1 dag moet leven bijvoorbeeld.) Of een (regressie)testomgeving die even snel wordt opgezet en daarna vernietigd wordt.
Uiteraard kun je ook het vroegtijdig onklaar maken van een certificaat in je flow opnemen, maar dan is dat logischer (en meer voorspelbaar) om te doen met een 7daags certificaat dan een 90daags certificaat.

[hello123456]

Klopt, daarvoor heb je PFS, maar dat is (vooralsnog) niet beschikbaar (voor zover ik weet) voor een https:// verbinding toch? Ik weet dat je het kan toepassen binnen E2EE applicaties en websites, maar ik ben niet bekend met toepassing op de verbinding zelf.

Ook verwacht ik dat PFS een stuk moeilijker is om op te zetten dan een simpel automatisch vernieuwend certificaat. D dus afhankelijk van je threat factor is wellicht een kortlopend certificaat meer dan voldoende.

[lenwar]

PFS is (al een tijdje) primair een ciphersuite-ding (in de praktijk). Het 'opzetten' komt in de praktijk neer op de juiste ciphers kiezen (of eigenlijk de niet-ondersteunde uitzetten). Het wordt al vrij lang gebruikt door de meest gangbare webserversoftware.

OpenSSL ondersteunt het sinds 2012 (in elk geval toen Elliptic-curve Diffie–Hellman populairder werd). En daarmee effectief alle webservers die die ciphers ondersteunen.

(In die tijd werd het concept, grappig genoeg door sommigen, als 'obscuur' bestempeld )

Apache ondersteunt het sinds 2.3.weinig (voor het gemak dus 2.4 als stabiele cycle)
Nginx sinds 1.4.nogwat (voor het gemak 1.5)

Maar goed. Dan zijn we er nog niet.
Firefox ondersteunt het sinds versie 38 (uit 2015). (die moest ik even uitzoeken)
Chromium dacht ik ook in die periode.

[markg85]

Ik heb de link bekeken en echt veel voordeel kan ik nog niet ontdekken in 7-dagen certificaten. De punten die de site noemt (ook 7 toevallig):

Crypto-Agility: Infra, niet direct voordeel.
CA Agility: Infra, niet direct voordeel.
Automation: Infra, niet direct voordeel.
Improved Revocation Handling: Infra, niet direct voordeel.

4 van die 7 "voordelen" is op infra structuur niveau. Zoals dat je flexibel ben in het updaten van je certificaten en makkelijk over kan stappen naar een ander. Dat heeft op zich niets met de veiligheid van je site te maken, oftewel een infra argument. Voor de simpele sites tellen die voordelen niet. Voor de grotere orgs zijn die voordelen eerder een logistiek nadeel.

De 3 andere "voordelen" zijn ook niet echt realistisch.
Reduced Attack Surface, dat gaat over het uitlekken (of gehackt) certificaat. De private key. Daar heb je al het bestaande recovation voor en dat verandert niet. Enige marginale zijdelings voordeel is dat je certificaat na 7 dagen toch al is verlopen en je hele revocation niet meer nodig is, maar dat is dan weer een infra voordeel, niet een beveiliging.

Secure Key Management. Het roteren van je (private) keys. Irrelevant voordeel. Zoals bij "Reduced Attack Surface", als je certificaat is gelekt kan je er vanuit gaan dat er op een hoger niveau dan je certificaat een probleem in je organisatie zit. Je kan je keys roteren tot je een ons weegt, het probleem zit ergens anders. Ja, key rotatie is een voordeel maar niet in deze context betwijfel ik dat.

Zero Trust Alignment. Totaal non argument. Dit gaat over verificatie en encryptie van data. 7 dagen gaat je daarbij niet helpen, ephemeral keys wel.

Oftewel, met de beste wil van de wereld, zie ik nog niet waar een 7-dagen certificaat echt voordeel heeft.

[DataGhost]

Als je je niet bewust bent van het feit dat je key/cert op de een of andere manier zijn uitgelekt, zal je die ook niet revoken natuurlijk. Een kortere geldigheid verkort dan ook de periode waarin het certificaat eventueel misbruikt kan worden.

[locke960]

Als je je niet bewust bent van het feit dat je key is 'gelekt', dan gaat een kortere geldigheid je ook niet helpen want dikke kans dat je key elke 6 dagen op dezelfde manier 'gelekt wordt.

[laurxp]

Het is niet bedoeld voor de gebruiker zelf, maar voor het ecosysteem als geheel.

Volgens de regels moet een CA bij een incident binnen 24 uur de certificaten ongeldig verklaard hebben. Er is geen speling mogelijk, en dit staat óók in het contract dat de klanten met de CA hebben. In het verleden is dit héél lastig gebleven, en keer op keer kwamen CAs met het excuus dat hun klanten "kritieke infrastructuur" beheerden en meer tijd nodig hadden voor het vervangen van hun certificaten - vaak ook nog eens met het excuus dat het "geen serieus incident" was en dat hun klanten wél snel zouden kunnen renewen als het echt nodig was. Oftewel, we kunnen er niet op vertrouwen dat CAs zich aan de regels houden. Best wel een probleem als letterlijk je enige waarde is dat je een betrouwbare partij bent.

Dit is een structureel probleem in de industrie, want geen enkele CA wil onder de klanten een reputatie krijgen als "moeilijk" omdat zij zich wél aan de regels houden. De oplossing is om vanuit de browsers kortere certificaten verplicht te stellen. Als de duur kort genoeg is dwing je de klanten om de vervanging te automatiseren. Bij een kortdurend certificaat is het onmogelijk om er een bureaucratisch proces van vier maanden om heen te bouwen. En als er eenmaal automatisering is, is vervanging bij een incident niks anders dan op een knopje klikken en wachten tot het standaardproces klaar is.

[Heedless]

Waarom is dit zo’n groot nieuws? Is het niet een kwestie van gewoon een vroegere einddatum instellen, of is er technisch iets heel anders aan?

[Barsonax]

Let's encrypt zal nu vele malen meer certificaten moeten uitdelen dus in die zin wel iets meer dan de einddatum ff aanpassen. Ze moeten ook nadenken over scalability.

Vind het dan ook best wel nieuwswaardig, ik ga dit ook zeker gebruiken.

[lenwar]

Nou ja. Het is ook geen 'groot nieuws'. Het komt neer op "Een bedrijf biedt een nieuwe dienst aan". Het is wezenlijk niet groter of kleiner dan toen Apple de tweede versie van haar Airpods (of hoe ze ook heten. In elk geval die oortjes van ze) op de markt zette. Dat was ook 'een bedrijf dat een volgende iteratie van een product op de markt zet'.

Maar goed.
Het is wel, zover ik weet, een uniek product. Volgens mij zijn er (nog) geen andere diensten die zulke kortlevende certificaten aanbieden aan het grote publiek. In elk geval niet gratis.

Voor LetsEncrypt zelf, heeft dit wel gigantisch veel impact als veel gebruikers dit gaan gebruiken. Het maken van certificaten is uiteindelijk best wel belastend werk voor een computer. Als je er eentje maakt, is het geen probleem. Als je er duizenden per minuut worden, is dat best een boel rekenkracht. (niets onoverkomelijks, maar wel een boel.). En er gebeurd natuurlijk van alles voordat en nadat het certificaat is gemaakt.

Er zijn op het moment ongeveer 500.000.000 certificaten actief. Dat zijn dus (uitgaande van 90 dagen) ruim 5,5 miljoen certificaten per dag. Dat is ruim 64 certificaten per seconde. De rekensom naar 7 dagen mag je zelf doen

(Relevante disclaimer: Nou reken ik met het idee dat alle certificaten 90 dagen meegaan, en ze nooit voor die tijd worden vervangen, wat in de praktijk altijd is. Dus de werkelijke getallen zijn veel hoger. ).

[j0057m]

Ze hadden een talk op FOSDEM 2025: https://fosdem.org/2025/s...ed-certificate-authority/ — ik vond het best verrassend dat het grootste deel van hun infra in maar 3 racks past.

[Mitchelllll]

Ik snap hier zo geen hol van.

[beerse]

Vergelijk het met dhcp-lease op je netwerk. Alleen op een omgeving met een stabiel aantal machines zet je die op een lange periode. Maar tegenwoordig met virtualisatie en containers worden systemen nogal snel opgezet en weer afgebroken. Die krijgen eigen netwerk instellingen en waar nodig ook eigen certificaten en zo. Zeker als ook nog gebruik gemaakt gaat worden van diensten van akamai en dergelijke.

Bedenk dan een website voor een bepaald doel. Die gaat 1 keer netjes opgezet worden en als het gebruik groter wordt, zullen meer containers worden opgestart en daarna meer virtuele machines die deze containers gaan draaien. En dat allemaal in meerdere rekencentra. Maar na een paar dagen (of zelfs een paar uur) zijn die niet meer zo nodig en kunnen de meeste allemaal weer worden opgeruimd.

En ja, daar is in voorkomende gevallen een kort lopend certificaat voor nodig. Het moet niet zo zijn dat de web adressen een week later door/voor andere zaken worden gebruikt en de oude certificaten nog bruikbaar zouden kunnen zijn.

[xxs]

Ik gebuik een LetsEncrypt cerificaat voor o.a. mijn RADIUS server die vervolgens gebruikt wordt om een WPA-Enterprise WiFi verbinding op te zetten. Ik heb nu op een aantal apparaten dat er een handmatige aktie vereist is om om het nieuwe certicicaat te accepteren bij het opzetten van de verbinding.
Met name Windows en Apple spul maar ook sommige Linux distributies.
1x in de 3 maanden is nog wel te doen maar iedere 6 dagen lijkt me redelijk irritant worden.

Ook moeten services die een certificaat gebruiken meestal herstart worden bij vernieuwing, dus die interruptie zal bij korte certificaten gigantisch toenemen in frequentie.