Let's Encrypt biedt vanaf volgend jaar kortdurende certificaten aan

Let's Encrypt gaat vanaf 2025 ook kortdurende TLS-certificaten aanbieden. Deze nieuwe certificaten zijn slechts zes dagen geldig, wat op het gebied van cybersecurity voordelen moet bieden. Wanneer de kortdurende certificaten precies beschikbaar worden, is niet bekendgemaakt.

De gebruikelijke TLS-certificaten van Let's Encrypt zijn negentig dagen geldig, waarna ze vervangen of hernieuwd moeten worden. Dat heeft echter als nadeel dat een aanvaller ook negentig dagen de tijd heeft om een certificaat te compromitteren. Door die tijd te verkleinen wordt de kans op misbruik ook kleiner. Mocht een aanvaller het certificaat toch weten te compromitteren, dan heeft deze persoon ook maar een korte periode om daarvan misbruik te maken. Daarna wordt het certificaat hernieuwd en moet de aanvaller helemaal opnieuw beginnen.

Deze securityvoordelen zijn voor Let's Encrypt reden om in 2025 kortdurende certificaten te introduceren, vertelt executive director Josh Aas. De organisatie heeft zoveel mogelijk werk rondom certificaten geautomatiseerd, waardoor gebruikers tegen die tijd weinig hoeven te doen om over te stappen naar een kortdurend certificaat, zegt de topman. "Maar wij moeten na gaan denken over de mogelijkheid dat we twintig keer zoveel certificaten moeten gaan uitgeven als dat we nu doen", zegt Aas.

Op dit moment worden de gratis TLS-certificaten die negentig dagen geldig zijn door ruim 500 miljoen websites gebruikt en worden zo'n 5 miljoen certificaten per dag uitgegeven. "Het is niet ondenkbaar dat we ergens in het komende decennium in staat moeten zijn om 100 miljoen certificaten per dag uit te geven." Wanneer de kortdurende certificaten precies beschikbaar worden en hoe gebruikers dan kunnen overstappen, is nog niet bekendgemaakt.

Reacties (158)

[pimlie]

Bedenk wel dat elke keer als je een certificaat aanmaakt dit certificaat wordt opgenomen in verschillende Certificate Transparency logs. Deze logs worden actief gemonitord door verschillende partijen.

Als je een daadwerkelijk publieke website hebt dan maakt dat niet veel uit, maar als jij als tweaker een certificaat aanmaakt voor een prive domein eigenlijk alleen bedoeld voor eigen gebruik dan wordt dat certificaat inclusief domein naam dus ook in de publieke CT logs geregistreerd. Alhoewel security-through-obscurity geen beveiliging is, zou er dus wel iets voor te zeggen kunnen zijn om in die gevallen een wildcard certificate aan te maken zodat je niet meteen aan de hele wereld vertelt welke websites je allemaal intern host (zoals bv home-automation websites).

Omdat elke keer als je een certificaat renewed deze ook naar de CT logs wordt gestuurd, zou je met deze nieuwe wijziging dus elke 6 dagen een ping geven van 'Ja, ik gebruik deze website nog voor intern gebruik'. Bedenk dus goed of je dat wilt doen

[DataGhost]

Je zegt het zelf al, security through obscurity is geen beveiliging. Het kan mij roesten dat iemand kan zien welke certificaten ik allemaal heb aangevraagd. Degene die bedoeld zijn voor privé-dingen, zoals o.a. mijn home automation inderdaad, kom je niet bij zonder correct client-certificaat, en vervolgens moet je nog inloggen. Als je dat gewoon goed in orde maakt van tevoren hoef je je er verder nooit meer zorgen over te maken.

Overigens heb je geen CT-log nodig om te zien of iets nog actief is of niet. Dat kan je zien aan het feit dat het certificaat nog geldig is, met de huidige geldigheidsduur van 90 dagen is het al redelijk duidelijk. En als je nog kan verbinden met de host is dat ook wel een behoorlijke hint.

[kftnl]

Je zegt het zelf al, security through obscurity is geen beveiliging.

Correct uitgevoerd is het gewoon een "something you know" als een authenticatiefactor. Je moet altijd meerdere factoren gebruiken, maar het kan een legitieme factor zijn.

Als een aanvaller een hostname moet weten als een beveiligingslaag, dan is dat niet per sé obscurity. Het is in lijn met wat een wachtwoord is. Een wachtwoord haalt zijn beveiliging niet uit dat het onbekend is dat er een wachtwoord gebruikt wordt, het haalt de beveiliging uit complexiteit. Je kunt hetzelfde doen met een domein. Het technische verschil tussen deze twee request is miniem:

POST /resource HTTP/1.1
Host: example.com
password=95886bc0-ccb0-49c0-852a-7a68b99f9b1f.example.com


GET /resource HTTP/1.1
Host: 95886bc0-ccb0-49c0-852a-7a68b99f9b1f.example.com

Het voordeel van host beveiliging boven password beveiliging is dat het triviaal op te zetten is dat je hele systeem nooit bereikt wordt als iemand het domein niet kent. Dat is een leuke laag beveiliging want dan heeft de aanvaller niet eens een systeem om aanvalsvectoren op te ontdekken.

Bij alleen een wachtwoord of cert ben je vaak alsnog afhankelijk van kwetsbaarheden in de code die soms gewoon daaromheen kunnen gaan. Je kunt dat wel opzetten dat met die dingen het systeem in zijn geheel niet bereikbaar is natuurlijk, maar dat is vaak wel complexer.

Voor de duidelijkheid, security moet je altijd in lagen doen, en 1 laag als dit is niet voldoende, maar ik zou een correct uitgevoerde onraadbare hostname niet direct 'obscurity' noemen. Net zoals alleen een wachtwoord niet genoeg is, is alleen een geheime host ook niet genoeg, maar het voegt wel wat toe.

Wat hier wel belangrijk is, is dat je DNS server kan zien welke domein je opvraagt, dus dat maakt het net wat minder veilig dan een wachtwoord in sommige opstellingen. Maar dat maakt het niet minder geldig als 1 van je beveiligingslagen.

[Reactie gewijzigd door kftnl op 12 december 2024 13:07]

[DataGhost]

Uh, tsja, DNS gebeurt over het algemeen nog steeds niet-versleuteld over UDP 53 en is daarmee behoorlijk sniffbaar. Ook al kan je het als soort van wachtwoord gebruiken, beter behandel je hostnames gewoon als volledig openbare, uitgelekte en publiek algemeen bekende informatie, dan sta je ook nooit raar te kijken als er ooit iets mee gedaan wordt. Er bestaan echt zat beveiligingsmaatregelen die wel gewoon werken en waarbij je niet afhankelijk bent van obscure zaken.

[kftnl]

beter behandel je hostnames gewoon als volledig openbare, uitgelekte en publiek algemeen bekende informatie

Ok, geef eens die URL van jouw home automation systeem? Gaan we even kijken of het goed is opgezet.

Edit: Om mijn DNS te sniffen (als ik geen DoH gebruikte) moet je wel eerst even mijn lokale netwerk inkomen natuurlijk... en dan even ARP spoofing doen op een router die daartegen resistentie heeft. Ik wens meneer de random hacker die toevallig langskomt succes. Hele punt van onbekende DNS name was nou juist dat het veel lastiger te vinden is en dat doet het gewoon.

[Reactie gewijzigd door kftnl op 12 december 2024 14:41]

[DataGhost]

Die kan je echt triviaal vinden in de CT logs op crt.sh. Verbinden moet nog lukken, maar veel succes met überhaupt een request kunnen doen

[kftnl]

Zo je hebt aardig wat open staan en ook niet allemaal up to date? Weleens iets als een zero trust access systeem overwogen?

[DataGhost]

DM maar wat je denkt dat er niet up-to-date is, geen idee of je op de juiste plek kijkt. Van de meeste dingen kan je de versie niet eens zien. En up-to-date betekent niet bleeding-edge he?

[kftnl]

Via scan.nextcloud.com, die loopt een paar versies achter met een (hier niet exploitable) vulnerability. Nou heb jij zo te zien wel vaardigheden in security, maar deze stijl van setup zou ik de meeste bedrijven en consumenten in principe niet aanraden.

Mocht er nou toevallig een keer een serieuze zero day komen van bijv. nextcloud dan zou je wel gebaat zijn als die host niet in de transparancy reports staat, IMHO.

[locke960]

Dit gaat niet om dat soort beveiliging. Dit gaat erom dat door dit soort logs een groot deel van je interne IT Architectuur, en daardoor ook je Enterprise Architectuur op straat komt te liggen. Dat kan zakelijk gevoelige informatie zijn.

Denk aan namen van hosts die een nieuwe dienst die je aan het ontwikkelen bent verraden. Of het aantal hosts wat met een dienst verbonden is. enz.

[Blokker_1999]

Hier is een oude hostname, niet langer in gebruik, mag jij van mij eens ontcijferen:

E2LN13RH.company.tld

En als ik in onze remote access oplossing kijk naar de hostnamen die onze klanten geven aan de machines waar de software van mijn huidige werkgever op draait, dan zie ik dat vele bedrijven, zeker grotere, altijd cryptische benamingen hebben waar ongetwijfeld een logica achter zit, maar ik hem meestal niet zie.

[locke960]

Flauw. In de werkelijkheid heb je alle namen waar een certificaat voor bestaat (host en anderszins). Inclusief de domein naam.

Daar kun je allerlei analyses op los laten die soms wel en soms niet een inzicht in het bedrijf zullen geven. Een gemotiveerde aanvaller zal daarnaast deze informatie met nog veel meer informatie combineren en analyseren. Big data + AI = een b*tch.

[Blokker_1999]

Natuurlijk heb je alle namen, maar opnieuw, dat hoeft niet noodzakelijk ernstig te zijn. Het hangt er maar net van af hoe je naamgeving in elkaar zit. Zo heb ik jarenlang al mijn systemen in huis vernoemd naar schepen uit Star Trek. Veel plezier om te achterhalen wat ik met Defiant deed, of met Enterprise.

En als een aanvaller eenmaal op je interne netwerk zit, kan deze ook gewoon even de reverse DNS proberen af te lopen voor je netwerk om zo IP adressen aan hostnames te mappen, en als je DNS onbeschermd is, kan je een DNS walk gaan doen om hetzelfde te bekomen.

Simpelweg schrik hebben omdat wat interne hostnames bekend zijn is gewoon schrik hebben voor iets waar je geen schrik van mag hebben.

[locke960]

Nogmaals, ik heb het niet over het inbreken in systemen.
De relevante zin in mijn eerste reactie is "Dat kan zakelijk gevoelige informatie zijn."

Alleen al het aantal hosts kan al gevoelige informatie zijn waarvan je liever niet hebt dat de concurrentie dat weet.

[vrow]

Dat is niet zo moeilijk.
De Defiant had je neergezet tegen de Borg, maar heb je uiteindelijk vooral gebruikt tegen de Dominion. En je had een goeie firewall erop waardoor die server eigenlijk helemaal onzichtbaar werd.
Met de Enterprise ben je vooral op ontdekking gegaan op het Wereld Wijde Web.

[lenwar]

Het voornaamste probleem zit in patronen.

Als jij Star Fleet namen voor RHEL gebruikt en Klingon namen voor Windows gebruikt en Vulcan namen voor netwerk-apparaten, (of zo), dan geef je informatie weg.

Als iemand door een brakke webservice kan achterhalen wat de hostname van de server is, en die hostnaam is IKSQuVat is, dan weet iedereen dat deze server met een themanaam van een Vor'cha-class attack cruiser, een Windows server is (wanneer bovenstaande eenmaal is uitgevogeld door de betreffende kwaadwillende natuurlijk.)

[To_Tall]

Ik gebruik zelf vw of vu inc een volg nummer. Een hiernaar hoeft niet te vertellen wat de dienst is die je gebruikt. Succes met je analytics om vu1001 te ontcijferen.

Kijk ook eens naar de server benamingen van tweakers. Deze zijn of waren altijd openbaar. Die zeggen niets over de dienst die ze draaide.

Zo zijn er veel verschillende host benamingen die je kan gebruiken zonder een onderleggende dienst zichtbaar te maken voor het publiek.

[Reactie gewijzigd door To_Tall op 12 december 2024 15:53]

[wica]

endpoint 2, linux network 13 met redhat?

[Blokker_1999]

Dat is dan 1 op 4, de Red Hat is juist. Om dus maar aan te geven dat hostnames ook niet noodzakelijk veel zeggen. Ik denk dat een portscan op zo een moment meer zou vertellen over waarvoor een server gebruikt wordt en wat er mogelijks aan software te vinden is dan puur afgaan op de naam.

[Concept8]

Een port scan kan pas als ik een ip of domeinnaam van je weet. Dus bewijs van een gebruikte domeinnaam is wel degelijk een stukje informatie dat iemand met kwade bedoelingen een stapje verder zou kunnen helpen.
Daarmee is diegene nog lang niet binnen natuurlijk (tenzij je open of verkeerd geconfigureerde services hebt draaien), maar dat was het punt ook niet.

[wica]

Laten we maar geen hostname schema war beginnen

[lenwar]

Toch is er een best practice dat je geen 'logische' namen moet gebruiken. Nou moet ik zeggen dat ik nog nooit een bedrijf heb gezien dat echt alleen maar willekeurige strings gebruikt, hoor, maar toch is het best practice.

Het voornaamste 'probleem' met logische namen, is dat als je de sleutel eenmaal weet dat het dan wel ineens een boel informatie geeft. Zoals je zelf zegt, kom je mogelijk met een portscan al verder voor één individuele server. Maar als je dus je voorbeeld hebt ontcijfert, dan is de rest een stuk makkelijker. Die RH laat Red Hat zien. Het had ook SUSE kunnen zijn. (geen idee of SUSE zich anders gedraagt met een standaard portscan, maar even voor het idee )

Aan de andere kant. Veel bedrijven zetten ook heel veel informatie op LinkedIn. Je kunt heel makkelijk zien welke bedrijven RHEL gebruiken. Ga gewoon naar de RHEL-community en kijk welke bedrijfsnamen daar zitten te spammen. Als je wilt weten wat voor producten een bedrijf als Ahold, KLM, ASML, enz, enz, enz, gebruiken, zoek naar mensen die er werken en kijk in welke LinkedIn-communities ze zitten, en wat ze allemaal posten. Daar haal je echt heel erg veel info vandaan.

Dit is precies waar (spear)phishers en hackers beginnen met zoeken. Dat kunnen ze op hun eigen tempo doen en volledig anoniem (want ze maken gewoon even een nep-account en het verdwijnt in de grote bulk.)
Zo ziet de kwaadwillende dus, dat het bedrijf Red Hat gebruikt. Dat in combinatie met je hostname (die RH was al een inkopper natuurlijk, maar dit bevestigd.) En ze kunnen al makkelijker naar RHEL-specifieke exploits zoeken. En ditzelfde geldt voor meerdere tools (Splunk, Databases, NetApp, enz, enz, enz.)
Je snapt waar ik naartoe wil.

[timeraider]

Als ik kijk in mijn it msp portal zie ik dat bijna elk mkb bedrijf in Breda iig superduidelijke benamingen heeft.. van app01 tot rds01 etc. en ik kan mij niet voorstellen dat dit in de rest van Nederland anders is

[FrankHe]

De oplossing is simpel, gebruik een andere domeinnaam die niet direct te herleiden is tot je onderneming.

[wica]

Hoever moet je gaan?
Andere domeinnaam, andere eigenaar, andere nameservers, etc. Er bijna altijd wel een lijntje te volgens, die naar het bedrijf lijd.
Als je het wilt voorkomen, dan gebruik je, je eigen CA binnen je netwerk, voor je interne systemen.

[FrankHe]

Sommige ondernemingen hebben geen 'interne systemen', in veel gevallen staat alles op het publieke internet, uiteraard wel met hele goede toegangscontrole, dus niet bereikbaar voor 'het publiek'. Voor de 'interne infra' is het inderdaad geen gek idee om je eigen certificaten te brouwen al zou ik in dat geval wellicht en wildcard certificaat in overweging willen geven.

[wica]

Je kan ook wildcard certificates gebruiken. Moet je enkel zelfs deployen over je servers. En dat staat er nog weinig in de CT log

[FrankHe]

Dat is allemaal redelijk gemakkelijk te automatiseren.

[wica]

Klopt, allemaal mogelijkheden, om niet je hele infra te openbaren.

[lenwar]

Voor intern zal een enterprise een eigen CA hebben en niet een publieke.
Die interne CA gaat niet opgenomen worden in die CT-logs. Tenzij je dat als enterprise zo hebt geregeld.

[Wobblier]

Nou is een client certificaat nou typisch een type certificate usage waarvan die je niet door een publiek CA laat tekenen. Omdat je liever niet wil laten enumereren hoeveel en wat voor users je aangelegd hebt in je applicatie.

Nu is dat evident .. maar botst wel een beetje met je "het kan mij roesten of iemand kan zien welke certificaten ik heb aangevraagd".

[DataGhost]

Eh, nee. Een client-certificaat maak je gewoon zelf, de enige aanvraag die daarbij komt kijken is naar mijn eigen CA. Het heet toevallig een certificaat (omdat het dat ook is) maar het heeft redelijk weinig te maken met de server-certificaten waar het hier over gaat. Maar ik kan jou prima een lijst geven van welke client-certificaten ik heb als je dat wilt, ik kan die lijst ook in de krant zetten (als jij betaalt), maar daar heb je zonder de client-certificaten zelf nog steeds niks aan. Het enige wat je daarmee te weten komt is welke namen ik die certificaten heb gegeven, en die zijn (in mijn geval) ook niet naar iets noemenswaardigs herleidbaar.

Als je het over gebruikers binnen een bedrijfs-context hebt heb je aan een lijst met uitgegeven client certs nog steeds niet zoveel. Zelfs al gebruikten ze herleidbare namen, dan weet je bijv. dat Jan Jansen bij Dinges B.V. werkt en een certificaat heeft. Dikke kans dat je dat allang hebt kunnen zien aan z'n LinkedIn ofzo. Het is geen nieuwe attack vector.

Het hele idee achter client-certificaten is dat je daarmee voorkomt dat iemand bij je (wellicht exploitable) service kan komen en wachtwoorden kan bruteforcen. Verder niet zoveel. Ook is het natuurlijk niet je enige security-laag. Dus in mijn geval ben je zelfs als ik je een client-certificaat geef nog steeds niet binnen tenzij je een user+pw of een exploit voor de service erachter hebt.

[Wobblier]

Eh .. ja .. nou. Client certificaten kan je ook extern laten signen. Dit is eigenlijk heel gangbaar. KPN levert deze dienst voor o.a. de overheid voor loonaangifte etc. Zie: https://certificaat.kpn.com/. Het hele idee is dat distributie van identificatie zonder secrets te lekken. Je weet wel .. de private key.

Ook met client certificaten kan je kiezen, eigen CA, publiek CA .. etc. Met eigen CA combineer je vaak de client certificaat met een naam/wachtwoord. PKI zie je ook wel passwordless (zoals bij de overheid).

Leuk voordeeltje wat je misschien gemist hebt. Wanneer je client niet matched wijst het protocol je af. Dit behoorlijk secure gezien je traffic nooit de applicatie kan raken.

[DataGhost]

Ik weet hoe certificaten signen werkt ja. Bij het signen gaat inderdaad je private key niet over de lijn. Voor client-dingen kan je dat helemaal prima zelf doen, alleen jouw services hoeven jouw CA te vertrouwen, in tegenstelling tot bij server-certificaten je devices je CA moeten vertrouwen wat een stuk onhandiger is. Je kan het ook uitbesteden inderdaad. Volgens mij wordt in beide gevallen niet publiek gemaakt welke client certificaten je allemaal hebt uitgegeven, maar het punt was een beetje dat dat dus niet echt uitmaakt omdat dat doorgaans geen bruikbare informatie is. Je kan doorgaans (itt bij een server-certificaat) niet "verbinden" naar de CN in een client-certificaat dus het enige wat je te weten komt is een naam die al dan niet enige betekenis heeft.

Leuk voordeeltje wat je misschien gemist hebt. Wanneer je client niet matched wijst het protocol je af. Dit behoorlijk secure gezien je traffic nooit de applicatie kan raken.

Dit is juist precies waar ik client certs voor gebruik. Als je daarna bij de applicatie bent aangekomen moet je nog steeds normaal inloggen met user/pw, alleen is het nu niet meer mogelijk voor iemand om te bruteforcen of met een exploit binnen te komen. Ik dacht dat dat duidelijk was uit mijn originele

kom je niet bij zonder correct client-certificaat, en vervolgens moet je nog inloggen

Dus voor de volledigheid terug naar waar het om ging: service X heeft certificaat X.example.com, dat is publieke informatie, maar door een client-certificaat te vereisen maakt het niet meer uit dat iedereen weet dat X.example.com bestaat, want ze kunnen er niet mee verbinden.

[Wobblier]

Snap ik. Ik snap dat dit voor jou situatie prima is. Maar jouw home automation is toch niet de casus. Maar als we daar van uit gaan: stel je draait je home automation voor je hele familie over meerdere instances in cloud. En je staat je familieleden toe in te loggen via client certificaat. Per persoon, per device. Want: geen private key copies en ook niet via username en password (dat is onnodig dubbelop). Super secure!

Je doet PKI met je eigen CA. Prima leuk. Maar een van je familie lekt perongelijk zijn private key. AI. Maar geen probleem, je gebruikt een certificate revocation service. En dat is de attack vector die pimli aangeeft.

En daar heeft hij een punt. Nu geef jij aan dat het allemaal wel meevalt en het prima is alle informatie te delen. Het lijk mij volledig onnodig te weten hoeveel devices je familie gebruikt om in te loggen.

[DataGhost]

Hoe is een CRL (certificate revocation list) een attack vector? En dat is niet waar pimlie (en ik) het over had, die had het over Certificate Transparency logs, CT dus niet CRL. Dus een log van elk uitgegeven certificaat, niet van elk ingetrokken certificaat, gewoon twee compleet verschillende dingen. En daar staan alleen server-certificaten in. Voor uitgegeven server-certificaten is de CN een FQDN waarmee je over het algemeen verbinding kan maken, dus daarmee is het bestaan van het certificaat (en het opnemen ervan in een CT log (niet CRL)) een "attack vector" in de zin van het bestaan ervan is bekend, dus als je enige security rust op het feit dat niemand die naam weet doe je iets fout. Maar als het goed is is dat je enige security niet dus vanaf dat moment boeit het eigenlijk niet zo heel veel of het wel of niet bekend is. Bijvoorbeeld kan je in zo'n CT log zien dat er een certificaat is uitgegeven voor pg.tweakers.net wat duidelijk geen publiek ding lijkt te zijn, maar zo te zien kan je met alleen die informatie nog niet zo heel veel.

Maar client-certificaten komen over het algemeen helemaal niet in zulke logs terecht, en nogmaals, dat is geen attack vector omdat je geen verbinding kan maken met de service achter de CN in een bepaald client certificaat, omdat het een client is en de CN bovendien waarschijnlijk niet eens een FQDN bevat waar je heen zou kunnen verbinden. Dus mocht ik bijvoorbeeld mijn eigen CA alle CNs van uitgegeven client-certificaten laten publiceren weet jij alleen dat er een certificaat "pietje" bestaat en dat was het dan. Hoe zie je het voor je dat je iets met deze informatie zou doen?

[Reactie gewijzigd door DataGhost op 12 december 2024 17:24]

[lenwar]

Hoe is een CRL (certificate revocation list) een attack vector?

In de breedste zin. Het biedt informatie. Alle informatie is potentieel te misbruiken of minimaal te gebruiken. Het een wat meer dan het ander natuurlijk. (Zo moet je nooit meedoen op LinkedIn in de Red Hat groepen, enz. Dan weet iedereen dat jouw werkgever, bijvoorbeeld, RHEL gebruikt (ipv SUSE of Ubuntu), en kan de betreffende hacker dus makkelijker op zoek naar bekende RHEL exploits of het gaan gebruiken voor het eerste idee van (spear)phishing daarmee. Idem voor ieder ander softwarepakket natuurlijk. Hoe meer er gepost, hoe gevoeliger het kan worden.)

De CRL biedt informatie over vroegtijdig ingetrokken certificaten.

Dan is er dus 'iets' aan de hand geweest. Dat kan iets simpels zijn als een fuck-up van de beheerder (de bijbehorende key per ongeluk verwijderd of zo), maar ook duiden op een lek van een of ander. Dat er dus 'iets' met betrekking tot het certificaat is gelekt.
Dit kan een extra aanleiding zijn om daar is verder op te smurfen door de kwaadwillende.

Puur en alleen met die CRL kun je niets natuurlijk, maar het kan wel aanleiding zijn om verder te zoeken naar iets. Zeker als het certificaat van 'applicatienaam.mijndomein.ru' was. Dan weet de aanvaller dus dat er iets met het certificaat van die applicatie was, al kun je natuurlijk Oracle Databaseserver, confluence123.mijndomein.ru noemen onder het kopje van 'To confuse the Russians!'


N.B. Uiteraard biedt de CT-lijst ook informatie, maar die informatie is de 'happy flow'. De CRL is over het algemeen de 'niet-happy-flow' en 'kan' dus interessanter zijn.


Edit: Grammatica valt niet mee

[Reactie gewijzigd door lenwar op 13 december 2024 11:59]

[DataGhost]

Zo moet je nooit meedoen op LinkedIn in de Red Hat groepen, enz. Dan weet iedereen dat jouw werkgever, bijvoorbeeld, RHEL gebruikt (ipv SUSE of Ubuntu)

Je kan natuurlijk ook vanuit enige interesse in zo'n groep zitten, of omdat je er vroeger mee gewerkt hebt maar nu niet meer, en dat hoeft helemaal niets te zeggen over welke software daadwerkelijk in gebruik is. De counter hierop is expres een groep joinen van bijv. SUSE als je toch RHEL gebruikt. Nou, staat die hacker even beteuterd te kijken zeg! Als iemand echt binnen wil komen zal die gewoon een (al dan niet geautomatiseerde) toolkit hebben waarbij dat allemaal niet uitmaakt en dan schiet je gewoon en blijf je kijken wat er plakt. En die zal ook weten hoe onbetrouwbaar dat soort groepen-gein kan zijn.

Welk OS en software gebruikt wordt kan je overigens vaak al heel makkelijk vinden en anders zijn er fingerprinting-mogelijkheden die je behoorlijk dicht in de buurt kunnen brengen.

De CRL biedt informatie over vroegtijdig ingetrokken certificaten.

Dan is er dus 'iets' aan de hand geweest. Dat kan iets simpels zijn als een fuck-up van de beheerder (de bijbehorende key per ongeluk verwijderd of zo), maar ook duiden op een lek van een of ander. Dat er dus 'iets' met betrekking tot het certificaat is gelekt.
Dit kan een extra aanleiding zijn om daar is verder op te smurfen door de kwaadwillende.

Aan de andere kant kan je beargumenteren dat een entry in een CRL betekent dat de betreffende entiteit zich bewust is geweest van een probleem en daarop actie heeft genomen. Daarbij is waarschijnlijk de beveiliging verbeterd waar nodig en de procedures zodanig dat er niet nogmaals een certificaat teruggetrokken hoeft te worden. Dus juist bij entiteiten met een lege of ontbrekende CRL verwacht ik dat het "makkelijker" is om ergens binnen te komen.

Maar ik vraag me vooral af hoe jij bij de CRL terecht komt van een Client CA (want dat was de context) die doorgaans privé is, waar verder ook niet per se enige noodzaak is dat deze publiek gemaakt wordt want die hoeft alleen maar bij de interne systemen bekend te zijn. En daarin vind ik het behoorlijk weinig informatie die je daarmee zou krijgen. "Oei er was ooit iets aan de hand met het certificaat van Pietje", waarschijnlijk inderdaad een triviaal technisch iets, maar in het geval van een menselijke fout bij een bedrijf wat zodanig over hun security heeft nagedacht dat ze client-certificaten gebruiken, zal Pietje zo'n flinke uitbrander hebben gehad dat hij de rest van z'n leven alert is op geklooi ermee.

In server-context doet een CRL ook niet zo heel veel. Als je ergens binnen wilt komen heb je credentials of een exploit nodig. Dat een certificaat ooit ingetrokken is zegt niet zoveel over welke software er gebruikt wordt, dus ook niet of er een exploit in de TLS-stack of in de achterliggende service zit. En voor deze twee soorten exploits maakt het niet uit wat er ooit met een server-certificaat gebeurd is zolang jij gewoon met een van deze twee kan communiceren. Server-certificaten zijn alleen maar interessant als je er eentje weet te bemachtigen die nog niet ingetrokken is, om daar een MITM mee op te zetten.

[Reactie gewijzigd door DataGhost op 13 december 2024 14:04]

[lenwar]

Klopt allemaal, en je mag het van mij ook allemaal in twijfel trekken of bagatelliseren, dat snap ik ook wel.

Maar het gaat erom, dat je informatie weggeeft. En informatie kan misbruikt worden. Met alleen de kennis dat bedrijf xyz RHEL of SUSE of weet ik veel wat gebruikt, of dat je ziet dat er een certificaat is ingetrokken, enzovoorts kun je individueel niet zo veel mee natuurlijk. Maar het is wel een eerste begin om gerichter te zoeken.

LinkedIn is echt een goudmijn voor kwaadwillenden. Als je ziet hoeveel erop gezet wordt, tot en met project-informatie aan toe.

[DataGhost]

Nja ondertussen is het redelijk offtopic weggedreven maar mijn originele punt blijft staan, en dat is ook het uitgangspunt waarvanuit ik zelf werk: zorg dat je security zodanig op orde is zodat het niet boeit dat bepaalde informatie openbaar wordt, zeker als het relatief triviaal te vinden informatie is. Je moet altijd werken onder de aanname dat een aanvaller net zoveel of zelfs meer weet over de systemen die je probeert te beveiligen.

Van mij mag je prima van alles weten over mijn systemen/setup en wie er toegang toe heeft maar dat zal het niet noemenswaardig makkelijker maken om binnen te komen ten opzichte van alle informatie die je daar nu openbaar over van kan vinden. Daar is het op ingericht.

[Tozz]

Waar het om gaat is dat als iemand zo'n kortdurend certificaat gaat gebruiken omwille van de verbeterde beveiliging je wel direct een grote neon pijl naar je domein trekt met "Kijk hier! Ik ben super belangrijk!". Daar trek je weer gespuis mee aan

[DataGhost]

Niet echt, zeker niet als het straks gewoon de standaard is. Dan doet iedereen het. In de beginfase zullen het ook juist vooral/alleen onbelangrijke test-hosts zijn die zulke certificaten gebruiken en als daar geen problemen mee zijn gaat gewoon iedereen over.

De redenen voor een lange geldigheidsduur van certificaten zijn tegenwoordig niet meer van toepassing. Vroeger was het een heel gebeuren met fysieke controles en dat kostte veel geld dus dat deed je liever niet elke week, tegenwoordig kan het prima automatisch en dan hoeven ze dus ook niet meer lang geldig te zijn. Zoals hier in de comments al genoemd gaan browsers steigeren als ze certificaten met een lange geldigheidsduur tegenkomen, precies omdat er geen goede reden meer voor is en de lange geldigheidsduur zorgt voor een grotere kans dat er iets onveiligs is gebeurd. Daarom word iedereen gewoon verplicht certificaten met zo'n korte geldigheidsduur te gebruiken en val je niet meer op. Je valt juist op als je een lange geldigheidsduur gebruikt want dan heb je waarschijnlijk je boel niet geautomatiseerd en dus waarschijnlijk ook je security niet op orde.

Certificaten met een korte geldigheidsduur zijn verder niet inherent veiliger of onveiliger dan certificaten met een lange geldigheidsduur, je verkleint alleen de mogelijkheden/tijd die een ander heeft om zich voor te doen als jou.

[init6]

Denk ook dat dat een beetje de doelstelling is voor Lets Encrypt: publieke endpoints veiliger maken. Voor intern spul heb je self signed of van een CA.

Wat je wel kan doen is een wildcard gebruiken voor een intern domein, dat geeft je wat meer voordelen. Let's Encrypt certificaten per http validation kwamen zijn op te vragen, een DNS wildcard ook maar geeft je dezelfde resultaten als een nslookup.

[dasiro]

voor privé dingen draai je dan ook je eigen CA die niet rechtstreeks via het internet bereikbaar is, maar slechts voor je eigen lokale devices.

[Hennie-M]

Mensen die hun eigen CA draaien zijn goed bezig maar wel echt de niche binnen de niche.

Ik werk vanuit de detachering met veel it bedrijven en hun klanten en zelfs die hebben hun PKI niet op orde.
😢

[Guru Evi]

Tegenwoordig met pakketjes zoals step-ca is het echt niet moeilijk, een Docker container en een paar commando’s.

[arianvp]

Niet moeilijk maar qua beveiliging wat inadequaat. Ik heb liever mijn interne domeinnamen in een publieke log en dat LetsEncrypt de root ca netjes in een HSM bewaard, dan dat ik moet klooien met een interne CA en perongeluk de boel verpruts

[kodak]

Zoals ik de reden achter deze certificaten lees is het om het misbruik bij lekken van de privegegevens / sleutel van een certificaat te beperken. Dat lijkt me namelijk een duidelijke key compromise event. Het 'per ongeluk' niet beseffen dat je je domeinnamen in certificaten gebruikt die gepubliceerd worden in publieke logs is geen gebeurtenis waar deze certificaten voor bedoeld zijn.
Je voorstel om wildcards te gebruiken gaat dus ook niet om dit nieuws maar dat je het over een ander probleem hebt: dat beheerders niet beseffen wanneer ze maar beter geen certificaten met publieke transparantie kunnen gebruiken. Wat ook een reden is om geen wildcards toe te passen in dat systeem: er hoort juist zo veel mogelijk duidelijkheid bij de gebruikers te zijn met welk systeem ze precies te maken hebben, in plaats van maar te hopen dat de wildcard niet per ongeluk of door een crimineel in gebruik is voor een systeem waar de beheerder eigenlijk geen certificaat wil of mag gebruiken.

[sumac]

Stel dat je een thuis lokaal domein gebruikt, bv mijnlokaledomein.local (dus niet mijnpubliekedomein.nl), dan weet toch niemand dat dat domein bij jou of jouw ip-adres hoort? Dan is er toch ook geen risico? Tenzij je natuurlijk lokaal.mijnpubliekedomein.nl als domeinnaam voor je thuisnetwerk gebruikt. Of zie ik dat verkeerd?

[lenwar]

Als je dat dan met LE wil doen, dan moet je .local domein wel bij een publieke name server bekend zijn.

En die gegevens staan in in de Whois-gegevens.

[pOZOR jED]

3 maanden valt onder langdurend? 🥸

[laurxp]

Het gebruik van korte certificaten is de standaard aan het worden. Chrome is aan het kijken om alle certificaten te beperken tot maximaal 90 dagen, en Apple wil het in 2027 terugbrengen naar 47 dagen.

Het doel is om de industrie te dwingen het te automatiseren. En als het toch al geautomatiseerd is, maakt het niet zo heel veel meer uit of dat 90 dagen, 30 dagen, of 6 dagen is.

De reden hiervoor is dat de Certificate Authorities keer op keer op keer weigeren om ongeldige certificaten tijdig in te trekken. Als excuus komt er iedere keer een "maar onze klanten zijn belangrijk en hebben kritieke infrastructuur en hebben meer tijd nodig", terwijl in het contract staat dat ze binnen een bepaalde tijd moeten kunnen hernieuwen. De CAs hebben liever ruzie met Microsoft/Google/Mozilla dan dat ze een miljoenenklant kwijt raken, dus blijft het internet bij incidenten onnodig lang kwetsbaar.

Door automatisering vanuit de browsers af te dwingen verliezen deze grote klanten de optie om het niet te automatiseren, en is het dus gegarandeerd dat er bij toekomstige incidenten snel kan worden ingegrepen.

[Sebazzz]

6 dagen is wel erg lastig met monitoring op het automatisch proces. Met 90 dagen weet je dat ongeveer 20 dagen voor verloopdatum je binnen 20 dagen moet handelen, en de automatisering kennelijk tegen een probleem is aangelopen. Bij 6 dagen is elke keer als het certificaat niet wordt vernieuwd het gelijk een kritiek probleem.

[Bezulba]

En dus zal het proces fatsoenlijk geautomatiseerd worden waardoor 6 dagen geen probleem is.

Want die 20 dagen waarschuwing is "Oh, dat kan over een week of 2 toch nog wel" en dan is het opeens 2 dagen voor verloop (of zelfs erna...) paniek in de tent en moet het alsnog snel.

[rbr320]

Onzin. Als het geautomatiseerd aanvragen van het certificaat succesvol was en het automatisch vernieuwen ook werkt en gedegen getest is, dan kan je dit proces toch gewoon monitoren? Een standaard certbot installatie controleert nu al 2 keer per dag of je certificaten vervangen moeten worden. Als het certificaat maar 6 dagen geldig is zal je dan een dag of 2 van tevoren moeten ingrijpen als er iets mis gaat, in plaats van dat je een paar weken de tijd hebt.

[Reactie gewijzigd door rbr320 op 12 december 2024 11:04]

[Blokker_1999]

Ja, en elke keer het mislukt, want 100% success haal je nooit, heb je weer een dringende karwij erbij ipv dat je het binnen 1 of 2 weken kunt inplannen om naar te kijken.

En niet alles ondersteund certbot en automatisatie. Voldoende appliances waar het wel degelijk handwerk is. Leuk als je elke week een hoop systemen mag gaan aflopen.

[Reactie gewijzigd door Blokker_1999 op 12 december 2024 11:50]

[DDX]

Mooi voorbeeld waar wij tegaan liepen recent;
klant had een CAA record opgenomen in hun dns records waardoor de request van lets encrypt denied was.
Gelukkig heb je dan 2 weken (oid) om dit op te lossen.
Als je dit in 1 of 2 dagen moet oplossen en er zit dan ook nog een weekend tussen en daarna moet jouw marketing contactpersoon intern een ticket inschieten om juiste persoon te bereiken....

[rbr320]

Ja, en elke keer het mislukt, want 100% success haal je nooit, heb je weer een dringende karwij erbij ipv dat je het binnen 1 of 2 weken kunt inplannen om naar te kijken.

Ik heb met Let's Encrypt wel degelijk een 100% succes rate. In de vele jaren dat ik het nu gebruik is het misschien 1 of 2 keer gebeurd dat een certificaat niet meteen verlengd kon worden, maar dan ging het 12 uur later alsnog goed.

En niet alles ondersteund certbot en automatisatie. Voldoende appliances waar het wel degelijk handwerk is. Leuk als je elke week een hoop systemen mag gaan aflopen.

Als certificaten vervangen handwerk is dan is Let's Encrypt niet geschikt, daar zijn we het toch hopelijk wel over eens. Zet er dan eventueel een TLS-terminerende proxy voor waarop automatisering wel mogelijk is.

[Reactie gewijzigd door rbr320 op 12 december 2024 14:29]

[lenwar]

(Reverse) proxies zijn niet altijd handig voor appliances. Printen is al typisch iets dat je over https (of een ander versleuteld kanaal) wilt doen in je (bedrijfs)netwerk. Als je printer niet op een geautomatiseerde manier een certificaat kan krijgen, is dat, als je dat om de maand (iedere 60 dagen dus) moet regelen, nog tot daar aan toe. Iedere week gaat toch wel snel vervelen .

En er zijn natuurlijk ook zat andere apparaten waar dit voor geldt. (liftmachines, camera's, brandmelders, enz.) Nou zien we natuurlijk wel, dat steeds meer bedrijfsspullen de certificaten gepushed kunnen krijgen, dus dan is je probleem ook opgelost, maar lang niet bij alles is dat het geval.

Aan de andere kant, zul je waarschijnlijk op je interne apparaten je eigen CA gebruiken, en daar langere certificaten voor gebruiken

[pOZOR jED]

Dit gaat leuk worden, genoeg bedrijven en overheden dit nu al de grootst mogelijke moeite hebben hun certificaten tijdig te vervangen, omdat ze ze bij een 3e partij moeten aanvragen etc. Die vinden eens per (2) jaar al een drama...

[EraYaN]

Nouja hoog tijd dat die dus helemaal uit te lucht vallen dan, moet jij eens opletten wat er allemaal mogelijk is als niets het meer doet. Dan zijn de executives ineens helemaal van de partij.

[Umbrah]

Sorry dat ik het zeg, maar als iemand die ook ICT-dingen bij de overheid doet, zijn er meestal beleidstukken, en referentiecomponenten die gebruikt moeten worden. Hiervoor bestaat juist zoiets als de NORA (Nederlandse Overheidsreferentie architectuur): https://www.noraonline.nl...platformen_(IAAS_en_PAAS)

Er wordt juist nadruk gelegd op zaken als CI/CD en automatisering, en dit zit allemaal in de hele PAAS, SAAS, en IAAS inkoop besluiten.

Als er een leverancier is die alles 'click-ops' doet, dan is dat een uitzondering, en niet de regel: het risico wat de overheid loopt door zaken als excessieve workflows om handmatig certificaten te updaten niet bij de overheid hoort te liggen, en bij de vernieuwing/aanschaf van een platform of voorziening zelfs een eliminatiecriteria kan zijn.

Niemand zit er op te wachten om een PFX file te moeten bestellen via een of ander topdesk systeem, wat pas binnen 20 dagen binnen is, en dan met de hand dat in een of andere tomcat keystore te soepen via een RDP verbinding terwijl copy-paste wil je niet meer, terwijl een of andere halfgare met service.txt aan de gang gaat om het ding vervolgens op poort 443 te krijgen. Zelfs al heb je dit soort legacy, zijn gateways alsnog een optie.

Dat organisaties de moeite doen om zo'n proces in stand te houden, en zichzelf werk te verschaffen, daar mag een collega-techneut bij zo'n organisatie zichzelf wel eens vragen over gaan stellen, want dat is kapitaalvernietiging naar de belastingbetaler, én een risico.

Ik juig de stap naar client applicaties, zoals browsers, die de grens op 47 dagen zetten, en deze beweging naar 6 dagen juist toe. Zelfs al verknoei je het en laat je een wildcard met veel te brede scope jatten, de impact is minder extreem dan 3 maanden of zelfs een jaar. Bovendien geeft de NORA al terecht aan dat om fouten te reduceren JUIST overheden (ook naar hun toeleveranciers) automatisering moeten aanmoedigen.

[Dinoxl]

precies,

amen ik werk zelf bij de overheid in IT- en probeer ook steeds slimmer om te gaan met dit soort zaken.
te vaak dit doen we al jaren zo en oude applicaties maar niet vervangen door slechte besluitvorming.

de kaders zijn helder en duidelijk en bieden genoeg ruimte.

[pOZOR jED]

NORA ken ik niet eens, bij geen van de afdelingen waar ik zat gehoord in het oerwoud aan termen.
En ja, we automatiseren veel, maar voor iets simpels als een certificaat kun je dus vaak "gewoon" een topdesk ticket aanmaken en geduld hebben
Waarschijnlijk loop je eerst nog tegen wat mensen aan die er hun plasje over moeten doen, want veiligheid en mag jij dat wel...

[Umbrah]

De NORA heeft veel zusjes. Elke gemeente hoort GEMMA (https://vng.nl/projecten/...-model-architectuur-gemma), waterschappen de WILMA (https://www.wilmaonline.nl/index.php/Hoofdpagina), en de provincies hebben PETRA (https://www.noraonline.nl...e_ReferentieArchitectuur)).

Sommige begrippen, zoals enkelvoudig inwinnen/veelvoudig gebruik, zie je vanuit daar weer terugvloeien uit initiatieven als Common Ground (https://commonground.nl/), die natuurlijk óók weer raking hebben met initiatieven als SIDO (https://www.gofairfoundation.org/ienw-projects/sido-project/), wat weer als gevolg heeft dat organisaties data uitwisselen op zo'n manier dat niet elke paar weken elke straat voor één reden open moet, maar dat meer dingen tegelijk gaan gebeuren.

[jaenster]

Dit gaat er juist voor zorgen dat het geautomatiseerd word

[Oon]

Ook de certificaten waar iemand van een of ander bedrijf je belt en vraagt om terug te bellen om te bevestigen dat jij het bent zodat ze je naam op het certificaat kunnen zetten?
Volgens mij is dat proces niet te automatiseren..

[Jeoh]

Dat proces is toch geen knip voor de neus waard.

[Oon]

Ben ik het helemaal 100% mee eens, maar toch zijn er genoeg partijen die nog zo werken en genoeg bedrijven die hier voor vallen.

[FrankHe]

Het controleren of de partij nog steeds de partij is kan eens per jaar gebeuren. Het certificaat kan vervolgens 100 maal per jaar worden vernieuwd. Een kwestie van ontkoppelen en automatiseren, zo moeilijk is dat niet.

[iPadBoi]

Ik heb dan toch slecht nieuws voor je, veel certificaten mogen niet automatisch afgegeven worden vanwege de gevoeligheid van informatie die over de verbindingen gaat waar deze voor zijn.
Raad je aan je in te lezen in PKIoverheid en hoe lastig het aanvragen van zulke certificaten is.
Als je je afvraagt waarom dit nog niet allemaal automatisch is, raad ik je aan het bedrijf Diginotar eens op te zoeken, en te kijken wat daar mee is gebeurd.

Er zijn hele goede redenen waarom Lets Encrypt en andere zelfgetekende certificaten automatisch afgewezen worden en specifiek per stuk vertrouwd moeten worden, en zelfs dan is het niet best practice en kan je beter je eigen interne CA opzetten als je voor je interne netwerk certificaten wilt afgeven.

[Reactie gewijzigd door iPadBoi op 12 december 2024 10:49]

[glennoo]

En dat baseer je op...?

[pOZOR jED]

Ervaring! Ik zit regelmatig bij overheden en dit is een veelvoorkomend probleem.

[DinX]

En waarom zou dat niet lukken om een simpel certificaat te vernieuwen? Of is dat louter de onderbuik die hier spreekt bij het woord "overheid" ?

Iets als Manageengine Key Manager Plus aankopen en installeren (niet zo duur eigenlijk).
Koppelen met de API van je favoriete SSL-boer en ze worden volautomatisch vernieuwd en gedeployed.

[Cilph]

Ze zullen wel moeten als de rest van de wereld geen certs meer pikt >47 dagen.

[lenwar]

Op zich een prima idee. De enige beer die ik zie is voor appliances. In 2027 is menig printer/camera/kassa/enz/enz nog gewoon in gebruik (en terecht).
Die certificaten zijn lang niet altijd goed automatisch te vernieuwen.

Het zou fijn zijn als Chrome dan wel een optie biedt om het voor bepaalde ip-ranges op te rekken, waar nodig.

[watercoolertje]

Want er zit niks tussen lang en kort?

[pOZOR jED]

Bedoel meer dat 3 maanden al vrij kort is (tuurlijk, kun je automagisch vernieuwen...)

[watercoolertje]

Mijn punt is: het kan toch beide kort zijn

Overigens wordt ik hier niet enorm vrolijk van, nu worden de certificaten elke 60 dagen vernieuwd, dus 30 dagen speling mocht het vernieuwen niet lukken, dat is al 5x langer dan de geldigheid van deze certificaten

En als je hier nog speling over wilt houden blijft er van die 6 dagen helemaal niks over.

Als het optioneel is en de 90 dagen versie blijft bestaan is er dan weer niks aan de hand.

[Reactie gewijzigd door watercoolertje op 12 december 2024 10:04]

[oef!]

Je kan het ook automatiseren en in je monitoring hangen. Om de 4 dagen renewen en gaan.

[iqcgubon]

Ondertussen, bij de klant, het domain root certificate geldig tot 2048.

[Jeoh]

Let's Encrypt root certificates zijn ook gewoon 15 jaar geldig, daar gaat het niet om.

[Blokker_1999]

Je root certificate mag lang leven. Dat hoort op een offlince certificate store te staan die ergens in een kluis is opgeborgen en waarbij 1 enkele persoon nooit toegang kan krijgen tot de private key.

[lenwar]

Ja, vind ik wel. We hebben het hier over een certificaat dat ondertekende versleuteling faciliteert, in een tijd waar dagelijks exploits worden gevonden in apps, besturingssystemen, server-applicaties, enzovoorts.

Het verbaasd me eigenlijk dat ze die 3 maanden niet al tijden geleden hebben teruggebracht naar 1 maand.

Ik heb vroeger bij een bedrijf gewerkt dat voor bepaalde interlokale diensten, dagelijks de TLS-certificaten verving. (Dit waren "extralokale" certificaten - Dus met een "eigen CA" die werd gedeeld door een handje vol andere organisaties.)

Goede kans dat bijvoorbeeld cloud-providers of organisaties als META dit intern ook doen.

(( Ik heb dit overigens alleen maar bij dat ene bedrijf gezien, daarna nooit meer, dus ik wil niet suggereren dat het 'common practice' is. ))


edit: typo

[Reactie gewijzigd door lenwar op 12 december 2024 10:49]

[FiscBiker]

Op zich een goed idee, maar zes dagen is wel heel kort, dat past niet in een wekelijkse LCM-workflow.

[Jay-v]

Tuurlijk wel, dit kan makkelijk volledig geautomatiseerd worden via certbot, cert-manager oid.

Ik heb al menige outage meegemaakt omdat mensen vergeten te vernieuwen of expiry te monitoren.

Ik juig dit wel toe, prima bruikbaar voor veel web apps.

[Paul]

Het kan geautomatiseerd worden, eens, maar "makkelijk"? Voor veel systemen is het relatief simpel als je admin-toegang hebt tot de server, maar voor een aantal zeker niet (Citrix Netscaler bijvoorbeeld).

En dat is als je weet wat je doet, en erbij kunt. Dat geldt voor veel beheerders al niet eens, maar als gebruiker ben je al helemaal overgeleverd aan de goden; "hosters" genoeg die een .crt, een .key en een .cabundle-bestand willen, in de stress schieten als je key encrypted is, en in paniek uitbreken als je ze een .pfx-bestand stuurt.

De hostingwereld zit vol cowboys die geen **** snappen van TLS (of zelfs maar DNS). Gelukkig kunnen de meeste "script kiddy" "build your own hostingplatform"-pakketten wel met ACME overweg, dus dat beperkt de schade nog enigszins.

[The Zep Man]

Het kan geautomatiseerd worden, eens, maar "makkelijk"? Voor veel systemen is het relatief simpel als je admin-toegang hebt tot de server, maar voor een aantal zeker niet (Citrix Netscaler bijvoorbeeld).

Voor Citrix Netscaler is er gewoon een REST API waarmee certificaten beheerd kunnen worden. Dat sluit je aan op je PKI-beheersysteem.

Anno 2024 dit handmatig doen is een verspilling van mankracht en een verhoogd risico voor je productiesystemen.

[Paul]

Ik zeg ook niet dat het niet kan, ik zeg dat het niet makkelijk is.

`certbot renew` in /etc/crontab zetten is makkelijk. Een aparte server optuigen (of je zelfbouw-scripts co-hosten op een ander systeem), bijhouden / opvragen welke certs je hebt, deze op een of andere manier renewen, en dan allemaal REST calls uitvoeren is dat niet.

[walteij]

Voor 1 netscaler en 1 certificaat is een aparte server optuigen inderdaad geen goede oplossing.
Er zijn prima (bijna kant en klare) powershell en/of python scripts beschikbaar die dit voor je regelen.
Als je overigens iets als Certify The Web voor Windows gebruikt, maakt deze effectief ook gewoon een scheduled task aan om de vernieuwing te regelen, dus feitelijk op dezelfde manier als een linux certbot die gewoon een crontab gebruikt om het check script af te trappen.

Maar als je meerdere servers, certificaten/hostnamen hebt die je wilt beschermen is het juist wel een goede oplossing, omdat je dan een plek hebt waar je je certificaten vanuit beheerd ipv 12 servers die ieder dat beheer voor zichzelf doen.

En als je toch een server hebt waar je geautomatiseerde processen vandaan trapt, kun je die server eventueel ook voor andere automatiseringen gebruiken. Een dedicated server voor scheduled tasks is soms helemaal geen gek idee

[Paul]

Helemaal mee eens, en die hebben we ook. Maar het gaat hier over "makkelijk", en ik heb nog geen argumenten gezien die me ervan overtuigen dat zelf allerlei API's aan elkaar knutselen "makkelijk" is (in de context van: bij heel veel andere producten is het zo simpel als `certbot renew` schedulen).

En dan heb ik het tot dusver eigenlijk alleen over het plaatsen van de certificaten op de Netscaler gehad / over nagedacht, als ik dan na ga denken over de HTTP of DNS-challenge die bij ACME hoort (iig als je het bij Let's Encrypt doet; volgens mij heeft Sectigo bijvoorbeeld ook API keys) dan komt er weer een lading complexiteit bij. Ga je requests naar ".well-known/acme-challenge/{token}" op al je VIPs reverse proxy-en naar die scripting host? Ga je kijken of je DNS registrar toevallig ondersteund wordt? Iets anders?

Bottom line is gewoon dat als er geen native ondersteuning voor certbot is, het toch verre van makkelijk is.

[walteij]

Makkelijk is relatief.
Voor 1 of 2 certificaten is op de aparte machines makkelijk.
Bij 10 wordt het al lastiger, want waar moet je nou zijn om te troubleshooten. De oplossing is dan dus om het zoveel mogelijk te documenteren, standaardiseren en automatiseren.

Ik ken bedrijven die bijna 100 externe domeinnamen hebben waar een certificaat aan hangt, als je dat allemaal op die specifieke machines met letsencrypt zou doen, is dat onbeheerbaar.
Alles door een netscaler op laten vangen die die lekker laten letsencrypten is al wat makkelijker en er zijn echt wel oplossingen voor dit soort grootschaligere oplossingen.

[MrFloppy]

Er zijn enorm veel toepassingen te bedenken waarin certificaten automatisch vernieuwd kunnen worden. Ik denk dat als iemand er gebruik van maakt/gaat maken, dit bij voorkeur alleen geautomatiseerd zou moeten willen doen.

Eigenlijk voor alle vergelijkbare zaken zou je dit naar mijn menigen moeten willen doen (wachtwoord rotatie, configuratie, certs,etc).

Wat ik mij wel afvraag is welke afhankelijkheden van allerlei diensten geintroduceerd worden. 6 dagen is niet heel erg lang en wat als lets encrypt eruit ligt omdat dat ineens interessant wordt voor kwaadwillenden.

6 dagen lijkt mij persoonlijk dan weer niet heel erg lang....

[Jay-v]

90 dagen blijft ook gewoon een optie. Wil je langer, dan zijn er veel andere oplossingen.

[MGutker]

Dit automatiseer je toch? Of ben ik dan dom?

[The Zep Man]

Automatische vernieuwing met automatische testing. Je wilt niet afhankelijk zijn van menselijk handwerk waarbij tijd een kritisch aspect is.

[Haribo112]

Klinkt leuk. In de praktijk heb je altijd 1 of 2 die mis gaan doordat er iets niet goed in DNS staat.

[FiscBiker]

Het hele proces is zeker geautomatiseerd maar wordt wekelijks met de hand afgetrapt, anders weet je op een gegeven moment niet meer welke automatisering je had draaien en hoe die werkte. Daarnaast wordt e.e.a. natuurlijk strikt in de gaten gehouden met monitoring.

[12_0_13]

Als je automatische processen hebt waarvan je niet kan vertellen hoe die werkte en wanneer heb je een groot probleem.

[batjes]

Er draait in bijna elke organisatie wel ergens een houtje-touwtje oplossing script dat tijdens 1 of andere storing ingezet is om 3 uur 's nachts en nooit vervangen of deftig gedocumenteerd is.

Of een 1-3de lijns support medewerker die een powershelscriptje in elkaar flanst, ergens in een opstart mapje zet, om die gare obscure matrix printer maar elke reboot weer werkend te krijgen.

Er zullen organisaties zijn waar ook dit soort randgevallen netjes gedocumenteerd worden, maar de eerste moet ik nog tegenkomen.

[Samoerai]

Nee, niet dom. Meer wat naïef.
Certificaten worden echt niet alleen gebruikt binnen standaard LAMP installaties op servers waar je ff een scriptje kunt installeren. Er zijn genoeg appliances, devices en software waarbij je dit echt handmatig moet doen. Deze zijn ook nog lang niet afgeschreven of kunnen zomaar vervangen worden.

Tot nu kun je dit nog opvangen met commerciële certificaten, maar als de browsers ook max 90 dagen gaan ondersteunen heb je wel een aardig probleem.

[The Zep Man]

Er zijn genoeg appliances, devices en software waarbij je dit echt handmatig moet doen. Deze zijn ook nog lang niet afgeschreven of kunnen zomaar vervangen worden.

Als die geen expliciete ondersteuning voor LE of een API hebben om certificaatbeheer extern te kunnen beleggen, dan is het al zo oud dat je het niet meer zou moeten gebruiken. Zet er in dat geval een moderne TLS offloader voor die het regelt.

[Samoerai]

Tjonge.... ik denk niet dat ze er hier, en het nederlandse publiek in het algemeen, blij van zullen worden om nu ff alles wat geen LE of een API heeft in 1 keer af te schrijven. Als er al vervanging beschikbaar is.

Sorry hoor, maar er is echt meer dan een beetje Plesk of DirectAdmin of whatever webhosting dat afhankelijk is van certificaten. Ik moet hier al een firefox 34 achter de hand hebben om oudere switches te kunnen beheren. En nee, dat is niet per definitie onveilig omdat die switches op geen enkele wijze extern benaderbaar zijn. Als straks browsers alleen nog maar certificaten ondersteunen die nieuwer zijn dan 90 dagen zal ik ook daarvoor weer een oude browser achter de hand moeten houden.

[Strebor]

Dit automatiseer je inderdaad. Zo ook de monitoring op elk uitgegeven certificaat, zodat je weet dat het vernieuwen en uitrollen goed gaat.

Maar, met slechts 6 dagen, is de periode om het te fixen wel een flink stuk korter geworden.
Bij ons vernieuwen en vervangen we 30 dagen van te voren. Mocht er iets niet goed gaan tijdens de vervanging (en met heel veel domeinen en certificaten gebeurt dat helaas wel eens), dan hebben we ca 28 dagen om dat te fixen. We staan niet elke minuut klaar om dit soort glitches te fixen en met 30 dagen de tijd hoeft dat ook niet.

Mooier zou zijn als je zelf een certificaatduur kon bepalen. Bijvoorbeeld 14 dagen of 30 dagen.

[watercoolertje]

Dit is volledig te automatiseren dus ik zie het probleem niet helemaal. Daarnaast verwacht ik dat het een optie wordt naast de bestaande van 90 dagen, maar dat is niet heel duidelijk in het artikel.

[Reactie gewijzigd door watercoolertje op 12 december 2024 10:03]

[servies]

Aan jouw kant is het geen probleem...
Aan de kant van Let's Encrypt worden er nu ruim 5 miljoen certificaten per dag uitgegeven.
Stel iedereen gaat over naar die kortdurende certificaten. Uitgaande dat de uitgifte van die certificaten gelijkmatig is verdeeld over de 6 dagen komt het er op neer dat 500 / 6 = 83.33 miljoen certificaten per dag moeten worden uitgegeven...
Ik kan me voorstellen dat dat bij Let's Encrypt wel wat problemen oplevert....
Overigens worden de certificaten 'renewed' voor ze zijn verlopen... dus dan kom je eigenlijk al op 500 / 5 = 100 miljoen certificaten....

[Reactie gewijzigd door servies op 12 december 2024 10:06]

[watercoolertje]

Ik denk dat ze daar wel rekening mee (moeten) houden, maar niet perse een probleem is, immers komen ze zelf met deze functie. Die zet je toch niet live als je backend het helemaal niet aan kan?

[servies]

Dat doen ze ook

"Maar wij moeten na gaan denken over de mogelijkheid dat we twintig keer zoveel certificaten moeten gaan uitgeven als dat we nu doen", zegt Aas.

Deze opmerking geeft wel aan dat ze wel ergens nog een uitdaging hebben...

[lenwar]

Ja, het is wel even een dingetje
Er zijn uiteraard zat oplossingen te bedenken, maar die moeten wel gebouwd worden.

Denk alleen maar aan die transparancy-lijsten. Die blazen dan ook aardig op. Waar nu iedere ongeveer twee maanden een entry voor een certificaat erbij komt, krijgen ze nu iedere paar dagen een entry erbij.

Maar goed. Ze weten best wel wat ze doen daar. Dus komt wel goed

[GertMenkel]

Als dit een probleem zou zijn, zouden ze toch nooit met het idee op de proppen zijn gekomen? Het is niet alsof iemand ze verplicht dit te doen.

100 miljoen requests per dag is nou niet echt een onhaalbaar getal. Als hier consequenties aan zitten, denk ik dat ze eerder aan de kant van de certificate transparency logs zullen zitten, al zitten die voor zover ik weet ook bij grote cloudproviders waar meer dan genoeg ruimte moet zijn.

[xorpd]

Ach, een certificaat is maar een kilobyte of zo, dus hostingkosten zal het probleem niet zijn.

[MrMonkE]

En als je ipv elke 90 dagen elke 6 dagen doet kan het 15x vaker mis gaan.

[moonlander]

Zeker valt dit te automatiseren! Maar heb in het verleden grote problemen gehad met Plesk en LetsEncrypt certificaten. Letsencrypt had iets aangepast, maar had plesk niet gezien. Dus certificaten updaten mislukte.
Van probleem melding tot oplossing heeft het 3 weken geduurd. Dat was nog geen probleem met mijn sites omdat het een maand van te voren al geupdate wordt en de certificaten dus nog geldig waren in die periode. Maar 6 dagen wordt wel een issue dan!

[kozue]

Ik weet niet wat een LCM workflow is, maar het hele idee achter Let’s Encrypt is dat je het automatiseert met een dagelijkse job die kijkt of certificaten vervangen moeten worden en deze zelf vernieuwd wanneer nodig. Vaak gebeurt dit met certbot, maar je kunt ook je eigen client bouwen, want het ACME protocol is open. Je hoeft dus geen wekelijkse taken in te plannen om de certificaten te vervangen. Ik mag hopen dat je dat niet nu ook al doet met de 90-dagen versie?

[locke960]

Ik vermoed dat dat met opzet gedaan is. Dat voorkomt dat iedereen het inregelt op een vast wekelijks "maintenance window", natuurlijk allemaal tegelijk op zondag nacht, want dat geeft het laagste business risico.

Ten eerste gaat dat compleet tegen het idee van automatisch vernieuwen in. Dat moet gewoon goed en betrouwbaar op de achtergrond kunnen werken. Ten tweede sou dat de servers van Let's Encrypt overbelasten.

[init6]

Waarschijnlijk kan elke tool die de go acme library gebruikt op redelijke termijn gebruik maken van deze oplossing.

[Paul]

Mijn knee-jerk-reactie op de titel was: "Kortdurend? Ze zijn nu al maar 90 dagen geldig..."

Gelukkig is er voor veel systemen certbot / ACME, maar helaas nog teveel systemen waar dat niet (of met flinke omwegen) werkt. Wat zal ik blij zijn als Citrix Netscaler native ACME ondersteunt, nu is het nog prutsen met scripts en API's.

[3raser]

Dit zal niet de standaard worden, maar een optie. Voor de meeste website heeft een certificaat van 6 dagen geen enkele zin. Zij willen gewoon een beveiligde verbinding hanteren voor wat eenvoudige zaken en dan is 90 dagen prima. Maar voor websites die met zeer gevoelige data werken (medisch, financieel) zou 6 dagen een optie kunnen zijn.

[sniker]

de reactie van lets encrypt waarin ze verwachten naar 100mil per dag te gaan implceert toch echt dat zij al ervan uitgaan dat 6 dagen de standaard word. aangezien zij bepalen wat de standaaard is kan je ervan uitgaan dat dat een "wanneer" niet een "of" vraag is

[kodak]

Voor de een is een geldigheid van een jaar kort, voor de ander 90 dagen, weer een ander een week en er zullen ook systeemeigenaren zijn die een dag nog te lang vinden. De vraag lijkt me dan vooral waarop de standaard geldigheidsduur gebaseerd is als acceptabel.

De standaard 90 dagen gaat om een periode waarin je snel genoeg kan vertrouwen op toepassen van revocation lists en ondertussen je genoeg tijd hebt een nieuw certificaat te regelen zelfs als dat niet helemaal foutloos verloopt voor het oude certificaat vervalt.

Als een systeemeigenaar meer vertrouwen in een standaard kortere geldigheidsduur dan in revocation lijsten heeft, en dan ook nog garant wil staan dat wekelijks vernieuwen niet te veel extra risico voor het gebruik geeft dan vermoed ik dat daar al andere oplossingen voor in gebruik zijn dan wat lets encrypt kan bieden.

[Yucko]

mja, DSM (synology) zou het automatisch moeten doen maar in mijn geval is dat dus niet zo, dus zou niet blij worden als ik wekelijks mijn certificaten handmatig moet gaan vernieuwen zoals ik nu dus doe.

Ik mag dus hopen dat je zelf mag bepalen of je op certificaten met 6 dagen geldigheid wil overstappen, of dat je de 90 dagen variant wil blijven gebruiken.

[Octopuz]

Als je poort 80/443 niet van buitenaf open hebt staan (voor de US) werkt het automatisch vernieuwen niet. Daar zijn wel workarounds voor

[lenwar]

De DNS-Challenge is toch geen workaround? Het is gewoon een van de gedocumenteerde manieren om een certificaat aan te vragen bij LE.

Ik gebruik dit persoonlijk om certificaten aan te vragen voor fqdns die niet op internet bekend zijn.

Home Assistant heeft er een standaard addon voor. Ik gebruik het zelf op wat andere dingetjes. Ik mag toch hopen dat alle modernere NAS’sen dit ook standaard ondersteunen? (Als in gewoon in hun webinterface beschikbaar hebben?)

[Octopuz]

Het is een workaround voor het niet automatisch vernieuwen van certificaten op Synology als je de ingebouwde methode niet kunt gebruiken omdat je firewallregels hebt gemaakt om je poorten af te schermen.

[lenwar]

Ik heb zelf bijvoorbeeld een Home Assistant instance draaien en een Unifi Network Application op een losse pi (dus niet als HA-addon). Die zijn beiden niet via internet bereikbaar.

Beide gebruiken certbot (HA als add-on), Die certbot-installaties maken verbinding met mijn Name Server provider (in mijn geval Cloudflare) om de boel te regelen.

Wat het onder water doet. is het volgende:

- Certbot vraagt een certificaat aan bij LE met als controle Name Server records. (LE noemt dit DNS-01 challenge)
- LE zegt "Is goed, doe je ding met de Name Server record, maak dit TXT-record voor mij aan"
- Certbot maakt het TXT-record bij Cloudflare
- Certbot zegt tegen LE "Het TXT-record staat er, doe mijn certificaatjes maar."
- LE controleert het TXT-record bij Cloudflare
- Certbot ontvangt na positieve controle de certificaten
- Certbot verwijderd het TXT-record bij Cloudflare.
- Certbot doet wat housekeeping (herstarten processen, enz.)

Zoals je hierboven ziet, is er dus geen controle op de gevraagde fqdn. Ik kan aanvragen wat ik wil voor m'n domein. Al het verkeer is 'outbound' (Ik heb überhaupt geen port-forwarding aan staan op m'n router). Ik heb zo dus een aantal certificaten die ik puur-en-alleen in m'n eigen netwerk gebruik. Die DNS-records zijn niet op internet bekend. (als in dat ze niet in de name servers van cloudflare staan. Ze staan natuurlijk wel in de Transparancy Catalogues, want daar staan alle certificaten in)

Die controle op het TXT-record, toont 'slechts' aan, dat ik controle heb over m'n domeinnaam. (Waar je met een bestandje in je webserver aantoont, dat je controle hebt over de content van je webserver. Even goed of slecht. Gewoon een andere methode.)

Dit is standaardfunctionaliteit van certbot en de API's van LE. Daar heb ik niks bijzonders voor hoeven doen. (alleen een token aanmaken bij Cloudflare en die in de configfile van certbot zetten dus )
https://letsencrypt.org/docs/challenge-types/ <-- De DNS-01 challenge methode dus

Als ik je link lees, zet je handmatig op wat hierboven staat.

Maar die Synology-functie kan dus niet gewoon zelf met die standaard DNS-functie van LE/certbot werken? Indien dat het geval is, zou ik een feature request doen bij Synology , want dat komt dan een beetje knullig over. Dat zou ik toch niet verwachten van een club als Synology. Want het zou toch niet ingewikkelder moeten zijn dan noodzakelijk. en port-fowarding richting een NAS, lijkt me zeker niet altijd wenselijk.

[Octopuz]

Synology DSM ondersteunt DNS-01 alleen voor hun eigen Dynamic DNS-hostnames. Als je eigen hostname wil gebruiken wordt alleen HTTP-01 ondersteund.
Het idee om een centrale certbot voor je interne netwerk te gebruiken vind ik interessant!

[Reactie gewijzigd door Octopuz op 19 december 2024 14:03]

[Mit-46]

Ik gebruik dit voor Home Assistant zodat ik kan verbinden via een dns naam en niet het IP adres.

Ik heb het ooit ingesteld en nooit meer naar hoeven omkijken. Fijn om te lezen dat zoiets actief onderhouden wordt.

[Polderviking]

Met het risico geridiculiseerd te worden, wat zijn de security voordelen (van de korte levensduur) concreet?

Volgens mij leeft de gemiddelde phishing pagina bijvoorbeeld sowieso niet zo lang voordat die links en rechts geblacklist wordt en browsers weten dat het niet pluis is ondanks het geldige certificaat.
En let's encrypt controleert alleen maar of je controle hebt over 't domein waarvoor je een certificaat aanvraagt, niet wie je bent en wat je gaat doen.
Of liever, ze doen de aanname van controle over het domein omdat het verzoek van een server ip komt die in de DNS geconfigureerd staat.

[Reactie gewijzigd door Polderviking op 12 december 2024 10:54]

[xorpd]

Stel je voor dat RSA kraakbaar wordt, maar het kost een maand om het te kraken op de krachtigste supercomputer. Dan zijn Let's Encrypt certificaten nog steeds relatief veilig (in het heden).
Phishing sites e.d. worden niet geblacklist, dat zijn er teveel en het wijzigt te snel. Er is wel een blacklist, op provider niveau, maar dat zijn maar een handjevol sites, en geen phishing sites.

[kodak]

Je stelt juist een heel terechte vraag. Dat een kortere geldigheid van een certificaat voordelen kan hebben zegt namelijk niet over de nadelen en dus of het wel of niet een effectievere keuze is.
Het middel van het verkorten van de geldigheid is dus alleen een oplossing onder de juiste omstandigheden. Maar die zijn er niet zomaar. En dit middel is ook geen duidelijke oplossing die omstandigheden meer te laten ontstaan.

Als je sleutels niet meer volledig onder je eigen controle zijn dan gaat dat ook niet zomaar om omstandigheden waarbij de geldigheidsduur relevanter is dan waar een ander allemaal controle over kan hebben, zoals onopvallend er gebruik van maken of zelfs certificaten met een langere geldigheid aan vragen. Natuurlijk kan het standaard verkorten als alles mee zit dan wel extra helpen, maar als je als beheerders al te weinig controle over je sleutels hebt en je gebruikers vooral afhankelijk zijn van de standaard geldigheid van een certificaat ipv de revocation lijsten dan zit het waarschijnlijk al te veel tegen.

[Reactie gewijzigd door kodak op 12 december 2024 16:19]

[jdvmanen]

Lekker dan; in de stand-alone industrie (niet verbonden met internet) worden we nu ook (en terecht) gedwongen om van certificaten gebruik te maken. Maar aangezien het een off-grid netwerk is (ook uit safety overwegingen) stellen wij onze certificaten in op een geldigheid van 30 jaar. Aangezien een industriële applicatie (Cel met 1 PLC en een HMI en field I/O) in theorie qua software een set-and-forget installatie is. Komt bij dat het niet geïntegreerd is in het klantnetwerk, en het laden van een nieuw certificaat een hardware stop benodigd. Dus; cel stilleggen.

Ik zeg; dit is promoten dat de certificaten weer uitgeschakeld worden in een aantal gevallen.
Voor website's en API's die over internet benaderdbaar zijn lijkt me een sterk gereduceerde geldigheid zeer relevant. Ik kan mij voorstellen dat we over 10 jaar een geldigheid van een aantal uren gaan zien.

[stuiterveer]

Als jullie een geldigheid van 30 jaar instellen maken jullie uberhaupt geen gebruik van Let's Encrypt voor deze certificaten, wat dus ook mooi zorgt dat jullie hier totaal niks van merken.

[sprankel]

Je root CA kan 30 jaar geldig zijn maar de uitgegeven certificaten zullen normaal max 2 jaar zijn.

Maar aangezien het een off-grid netwerk is (ook uit safety overwegingen) stellen wij onze certificaten in op

Nee dat is niet de reden

in theorie qua software een set-and-forget installatie is.

Bingo, ik ben blij dat je het zelf aangeeft, je zit in een sector die gewoon is om iets te bouwen en er 30 jaar niet meer naar te kijken. Ik zit in dezelfde sector als die van jou dus ik ken de situatie maar al te goed.

Als jij aan security moet gaan doen, set-and-forget bestaat niet meer, je moet actief gaan beheren en dat is een bocht van 180 graden die de sector nog altijd niet goed begrepen heeft.

En ik ken het wel, afkomen wel self signed certificaten die automatisch in een foldertje rejected komen op de disk die je dan moet verplaatsen naar een folder accepted. Oja, je hebt enkel user rechten nodig om dat te doen.

Mijn antwoord daarop is, jongens, als je op die manier denkt aan "security" te doen, dan hoeft het voor mij niet. Dat heel het eco systeem er niet op voorzien is om nog maar een certificaat te vervangen zonder door een hard stop te gaan, ga terug naar de ontwikkelaar en zoek het maar uit.

[bartje]

mijn systeem vernieuwd de certificaten 10 dagen voor ze verlopen.
in dit geval zou dat een infinite loop betekenen.
Ik neem aan dat het een instelling wordt, maar dat zie ik niet terug in het artikel.
zou natuurlijk ook mooi zijn als je dan bijvoorbeeld kunt kiezen voor 30 dagen.

[bmwgozer]

Het is ook niet bedoeld voor elke toepassing, daarnaast als jouw systeem is kun je die 10 dagen toch zelf aanpassen. Snap deze hele reactie niet.

[glennoo]

Dan maak je er 1 dag van ipv 10 dagen. Probleem opgelost. Daarnaast is het ook wel echt een "IK heb zus en zo en dat kan niet" leuk voor je maar je kunt je ook aanpassen naar de rest van de wereld.

[hoepstoep]

Het is niet ondenkbaar dat we ergens in het komende decennium in staat moeten zijn om 100 miljoen certificaten per dag uit te geven

Wanneer alle 500 miljoen overgaan op zesdaagse certificaten komt dat natuurlijk dicht in de buurt. Dan gaan ze zonder groei er al overheen.

Ik zal in ieder geval niet wachten tot de zesde dag met het verversen van mijn certificaten. Sterker nog, ik zal het doen met drie dagen of misschien zelfs wel dagelijks. Dan heb ik vervolgens nog voldoende tijd om handmatig problemen te verhelpen. Het blijven voor mij hobbyprojecten, maar de boel moet natuurlijk wel goed blijven draaien.

[docdigit]

Met Let's Encrypt voldoet een dagelijks scriptje (dehydrated -c) om de geldigheidstermijn te controleren en zonodig te verzien van een verlenging.
Vergeet daarna niet om in de DNS gegevens van je domein het DANE record aan te passen.