Let's Encrypt trekt slechts klein deel certificaten in na bug

Let's Encrypt heeft besloten om na het vinden van een bug een miljoen certificaten toch niet in te trekken. Het intrekken zou wellicht onrust veroorzaken onder bezoekers van de desbetreffende websites. Enkele honderden zijn wel ingetrokken.

Let's Encrypt-topman Josh Aas zegt in een update dat het goed is voor 'de gezondheid van het internet' om de certificaten niet in te trekken. "Let's Encrypt heeft alleen certificaten die negentig dagen geldig blijven, dus mogelijk getroffen certificaten die we niet intrekken, zullen het ecosysteem snel verlaten", aldus Aas.

Vanwege een gevonden bug wilde Let's Encrypt drie miljoen certificaten intrekken. Daaronder waren ook veel certificaten van Nederlandstalige sites. Daarvan blijven uiteindelijk 445 certificaten over, die donderdag door de organisatie worden ingetrokken.

In de afgelopen twee dagen zijn er al meer dan 1,7 miljoen certificaten vervangen. Door de bug die op 29 februari werd ontdekt, kan Let's Encrypt de authenticiteit van een groot aantal certificaten niet meer verifiëren. Het bedrijf beschrijft de fout op een pagina en meldt daar dat de bug waarschijnlijk sinds 25 juli vorig jaar actief was.

Update, vrijdag, 13.10: Titel en lead zijn aangepast op basis van feedback van CyBeR en CH4OS.

Reacties (105)

Let's Encrypt-topman Josh Aas zegt in een update dat het goed is voor 'de gezondheid van het internet' om de certificaten niet in te trekken.

Als we dit in de termen van gezondheid houden zegt men eigenlijk:"We hebben het geneesmiddel, maar we laten iedereen lekker ziek worden"

In mijn beleving krijg je dan een ongezonder internet. Ook al is het maar voor max 90 dagen. Rotte certificaten actief houden brengt alleen schijnveiligheid.

[Reactie gewijzigd door PizZa_CalZone op 5 maart 2020 16:45]

[...]
In mijn beleving krijg je dan een ongezonder internet. Ook al is het maar voor max 90 dagen. Rotte Certificaten actief houden brengt alleen schijnveiligheid.

Het zijn geen rotte certificaten, maar certificaten die uitgegeven zijn gedurende een tijd waar het mogelijk was om onder heel specifieke omstandigheden rotte certificaten uit te laten geven.

Het overgrote deel van die 3 miljoen certs was gewoon goed en zelfs de niet goede certs (die 445) kwamen door de normale validaties heen, alleen verbaden de DNS CAA records op een gegeven moment de uitgifte daarvan en dát werd niet goed gecheckt.

IMO is dit dus de goede actie.

Misschien heb ik dan niet goed de toedracht van het issue begrepen, bij certificaten die ingetrokken worden denk ik al snel aan het uitlekken van keys.

Als je een LE certificaat aanvraagt dan controleren ze meerdere dingen om te checken of ze dat certificaat mogen uitgeven.

Als eerste controleren ze een bestand op je webserver, bereikbaar via dat domein, of een DNS record voor dat domein. Dit is de belangrijkste verificatie (en een die tot voor kort genoeg was).

Daar is recentelijk een tweede verificatie bijgekomen, namelijk een check of zij dat certificaat mogen uitgeven. Dat moet dan in een CAA record staan in de dns van dat domein.

Nu kun je meerdere domeinen opgeven in een certificaat. De bug hier was dat alleen van het eerste domein het CAA record werd gescanned, en voor de andere domeinen werd nogmaals het eerste certificaat gescanned. Dus als je '*.tweakers.net' en '*.google.com' in een aanvraag opgaf, dan werd alleen het CAA record van tweakers.net gechecked. (Dat certificaat zou ik niet krijgen, want de eerste check (op dns record of bestand op de webserver) zou dan falen).

Het is dus niet perse onveilig, maar 1 vd 2 controle mechanismes (waarbij de tweede die faalde pas sinds kort verplicht is) ging niet goed. De 445 zullen waarschijnlijk dat record missen of een andere CA in het record hebben staan. Wat niet wil zeggen dat ze malafide zijn, maar eerder dat het record nooit (goed) gezet is 'want het werkte toch wel'.

[Reactie gewijzigd door Kees op 5 maart 2020 17:45]

Our CA software, Boulder, checks for CAA records at the same time it validates a subscriber’s control of a domain name. Most subscribers issue a certificate immediately after domain control validation, but we consider a validation good for 30 days. That means in some cases we need to check CAA records a second time, just before issuance. Specifically, we have to check CAA within 8 hours prior to issuance (per BRs §3.2.2.8), so any domain name that was validated more than 8 hours ago requires rechecking.

The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.

Hoe ik het begrijp:
De CAA validatie werd wel gedaan, echter werd het resultaat 30 dagen "gecached", terwijl dit maximaal 8 uur had mogen zijn. De code die verantwoordelijk was voor deze rechecking had een bug waardoor er dus een 30 dagen window ontstond waarin de controle niet goed werd uitgevoerd.
Als je in deze 30 dagen een CAA record hebt toegevoegd dat de uitgifte door letsencrypt moet beperken, dan was het toch mogelijk om een certificaat aan te vragen via letsencrypt.

when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times

Volgens mij staat hier toch echt dat voor een cert met bijv. 10 domeinnamen, de eerste naam 10x opnieuw gecheckt werd i.p.v. elke individuele naam 1x. Als er voor die overige 9 dus in de tussentijd een CAA record is aangemaakt/bijgewerkt wat issuance door LE niet (meer) toestond, werd dat vanwege de bug niet gecontroleerd. Dat van die 30 dagen is puur dat LE vindt dat zo'n authorisation 30 dagen geldig mag zijn, maar ze moeten wel in de laatste 8 uur vóór daadwerkelijke uitgifte nogmaals deze records checken.

Dus het is mogelijk dat er mensen zijn met certificaten die geldig zijn voor google.com?

Lijkt me dat ze dan beter scannen naar malifide certificaten ipv certificaten die tijdens deze periode werden aangemaakt.

Nee, want die komen niet door de eerste check heen. Alleen iemand met de mogelijkheid die checks te doorstaan (dns toegang is De meest logische optie) zou dat kunnen. Die kan dan overigens ook meteen de CAA records aanpassen maar ok.

Overigens heeft LE afaik een blacklist van high-profile domeinen en Google zal daar allicht op staan.

Bedoel je de file check?

Want voor DNS werd alleen het eerste domein gecheckt.

Dat betreft een ándere dns check.

Je hebt er twee: of je het beheer hebt over een domein en op CAA records. Alleen die tweede ging fout.

volgens de uitleg die @Jimbolino hierboven zet, worden wel degelijk alle domeinen gecontroleerd maar zat er, voor de tweede controle, 30 dagen tussen ipv 8 uur

Ja dat kan in theorie. Vervolgens zul je alleen wel ook het domein moeten kapen om er daadwerkelijk misbruik van te kunnen maken. Dat certificaat is namelijk niet geldig op andere domeinen. Daar prikt een browser zo doorheen.

Je kan dus een spoofing attack op potenzetten.
OF een MITM ... (ISP met foute gedachten) of de oorzaak van het diginotar debacle: Iran had geldige certificaten van high profile sites nodig om verkeer te kunnen onderscheppen via een landelijke transparante proxy. Liefst zonder dat het opviel.

Als respons is er het Certificate Transparency project opgetuigd. Een klant kan zelf met CAA records aangeven wie de signer van het domain certificaat hoort te zijn. (dat is meer om te voorkomen dat de verkeerde CA's per ongeluk een verkeerd certificaat uitgeven).

Ja en dat laatste ging dus niet goed. Hierdoor kon er dus een goed certificaat worden uitgegeven door de verkeerde CA. Echter was er nog steeds domein validatie. Dus in theorie kan er een domein bijzitten wat toevallig net ook voor verlenging ging en de domein verificatie bestanden op de server had staan, maar ook daarvoor geldt volgens mij dat dit een speciaal geprepareerde payload is. Dus per ongeluk een correct certificaat krijgen zit er niet bij. Je had op de hoogte moeten zijn van deze bug en er actief op moeten acteren had je ook maar iets willen kunnen bereiken.

In theorie dus allemaal leuk, maar praktisch onhaalbaar.

Sterker nog bij een klant die geen CAA records heeft kan dit altijd overkomen. Sterker nog. Veel meer dan domein validatie wordt door andere Ca’s ook niet gedaan.

Dan heb je inderdaad de toedracht niet goed begrepen.

Het zijn geen rotte certificaten, maar certificaten die uitgegeven zijn gedurende een tijd waar het mogelijk was om onder heel specifieke omstandigheden rotte certificaten uit te laten geven.

Tot op grote hoogte ben ik het met je eens.

Maar.... LE bood veiligheid en kunnen die voor een deel van hun certificaten niet garanderen. Het is een beetje een fabrikant van een remsysteem dat zegt ze weten van een probleem en dat het soms niet zal werken. 'You had one job......"

Als jouw site niet echt belangrijk is, niet echt een probleem. Ik ken echter sites die user input vragen die gewoon niet correct beveiligd zijn. Dat is voor iedereen een probleem en gewoon een nieuwe attack vector voor boevies. Het toelaten van certificaten die gewoon NIET veilig zijn is voor het internet een slechte zaak. Als jij een site beveiligd met een dergelijk certificaat vertrouwd omdat de kans dat het fout is wil vertrouwen, hebben we een ander idee over wat een certificaat doet.

[Reactie gewijzigd door falconhunter op 5 maart 2020 18:27]

[...]
Als jouw site niet echt belangrijk is, niet echt een probleem. Ik ken echter sites die user input vragen die gewoon niet correct beveiligd zijn. Dat is voor iedereen een probleem en gewoon een nieuwe attack vector voor boevies. Het toelaten van certificaten die gewoon NIET veilig zijn is voor het internet een slechte zaak. Als jij een site beveiligd met een dergelijk certificaat vertrouwd omdat de kans dat het fout is wil vertrouwen, hebben we een ander idee over wat een certificaat doet.

Maar die certificaten zijn op zich wél veilig (in de zin dat ze gevalideerd zijn volgens de normale procedure voor LE certs: HTTP of DNS verificatie). Het enige wat niet goed gedaan is, is de controle of de betreffende domeinen de uitgifte van certificaten door LE toestaan, en zelfs dan alleen indien de uitgifte meer dan 8 uur na de verificatie van de domeinnaam is gebeurd én er meer dan 1 domein in het cert staat.

Voor domeinen waar geen CAA records bestonden die uitgifte door LE verbaden of die CAA records hadden die dat juist toestonden, geldt dus dat er niks aan de hand is. Voor domeinen waar die records er wel waren is dat een ander verhaal; daar zijn certificaten voor uitgegeven die technisch gezien in orde waren (domeinvalidatie is geslaagd) maar die om policy-redenen niet hadden mogen bestaan. Dat is een probleem natuurlijk, en daarom worden er zo veel mogelijk certificaten wél gerevoked. Om te beginnen die 445 (waarvan de betreffende domeinen op dit moment CAA records hebben die uitgifte door LE verbieden) en die 1.7 miljoen die al vervangen zijn.

Maar gezien dat de uitgifte van deze certificaten alleen maar kon nadat er al een andere check, die voor de meeste LE certs de enige is, is 't IMO schadelijker om die certs te revoken dan om ze te laten bestaan gegeven dat:
• De domain validation checks geslaagd zijn
• De betreffende CAA records op dit moment uitgifte niet verbieden
• De certs maximaal 3 maanden geldig zijn

[Reactie gewijzigd door CyBeR op 5 maart 2020 21:53]

Ze weten niet hoeveel van die certificaten wel te vertrouwen zijn. Dan neem je geen risico en trek je ze in. Alleenn zien ze nu dat eem groot deel van de aanvragers niet binnen de gestelde termijn vernieuwing krijgen. Dat zijn dan potentieel een miljoen websites met een verlopen certificaat en ze zijn bang dat dat voor verwarring gaat zorgen bij gebruikers van de website. Eigenlijk zegt lets encrypt eerst dat de beheerders van die certificaten zich aan de eisen moeten houden, maar nu ze dat niet lijken te doen zegt lets encrypt dat de eisen dan maar niet zo belangrijk zijn. Lets encrypt en de eigenaren van de certificaten zijn niet in staat om op korte termijn certificaten te vervangen als de certificaten massaal plotseling niet meer te vertrouwen zijn.

Je kunt ook al die mensen ziek laten worden met de hoop dat ze daardoor extra weerstand opbouwen. En volgens mij is dat inderdaad een betere keus. Maar wat heeft het niet intrekken van certificaten met de gezondheid van internet te maken?

Ik was in de veronderstelling dat al deze 1,7 miljoen certificaten niet meer veilig waren. Als je dan gaat wachten op de expirationdate, dan zijn 1,7 miljoen websites voor maximaal 90 dagen onveilig. Dit terwijl iedereen netjes een groen slotje ziet. ->schijnveiligheid...

De Let's Encrypt topman was bezig met het vergelijk over gezondheid. Ik was slechts doorgegaan op die analogie. Het vergelijk met gezondheid is wat mij betreft niet correct. Extra weerstand opbouwen geldt/werkt niet voor certificaten.

[Reactie gewijzigd door PizZa_CalZone op 5 maart 2020 17:10]

pff, mensen moeten echt beter lezen. De certificaten zijn gewoon veilig! er zijn geen keys uitgelekt. Er zijn alleen, onder hele specifieke omstandigheden, certificaten uitgegeven voor domeinen die LE niet had mogen uitgeven. De certificaten zijn gewoon goed getekend, de keys zijn veilig, en de domeinen zijn gecheckt.

in eerste instantie wilde LE alle certificaten die zijn uitgegeven gedurende de periode dat de bug in de code zat revoken (dus ook alle certificaten die gewoon helemaal goed zijn). Omdat dat erg ingrijpend is, is ervoor gekozen dat niet te doen, aangezien een heel groot gedeelte van de certificaten al vernieuwd is, en de rest binnen 90 (maar meer waarschijnlijk 30 dagen) dagen vernieuwd wordt. De certificaten die niet uitgegeven hadden mogen worden, worden wel geinvalideerd.

Wat mij betreft een prima oplossing. Ik zie niet in hoe deze oplossing niet veilig is, of "slecht" voor Internet.

[Reactie gewijzigd door borft op 6 maart 2020 10:17]

Aan de inhoud van dit nieuwsbericht kan je prima concluderen dat de certificaten onveilig zijn. Als ik me verder had verdiept middels onderzoek/andere nieuwsberichten dan had ik een andere conclusie kunnen trekken. Gezien ik dat reeds gedaan had open ik het bericht met: "Ik was in de veronderstelling".

Omdat de certificaten niet onveilig zijn is er inderdaad geen reden deze allemaal verplicht te vervangen.

Inmiddels is er uitgezocht welke certificaten "echt fout" zijn. Die 445 worden wel ongeldig verklaard. (nu moet iedereen de CRL natuurlijk nog checken...).

Overigens is certificaten intrekken en opnieuw uitgeven voor LE toch eenvoudiger omdat het daar geautomatiseerd is. Dus bestaande scripts een keer extra runnen is nu ook niet echt een issue....

Een geautomatiseerd proces kan best mislopen. Daarom heb je monitoring als achtervang. Op één van mijn servers liep het proces niet goed, dus ik heb onder hoogspanning moeten troubleshooten. Zal je altijd zien. Dit issue was anders over een maand alsnog gekomen, maar dan met bijna een maand de tijd om de monitoring weer groen te krijgen, in plaats van twaalf uur (ik vervang LE certificaten na 61 dagen).

Omdat ik geen CAA record heb vraag ik me af wat de relevantie van de bug voor mijn domein is, dus ik denk dat Lets Encrypt de juiste keuze heeft gemaakt door certificaten voor domeinen zonder CAA record geldig te laten.

‘We hebben een medicijn, iedereen kan het nemen en het is vrij beschikbaar, maar we stoppen niet de hele stad in Quarantaine’ is een betere analogie: iedere certificaat bezitter kan zelf er voor kiezen om een nieuw certificaat aan te vragen.

Het zijn vrijwel niet gevalideerde certificaten (e-mail is genoeg). Het is geen trust relatie die je met letsencrypt opzet, maar voornamelijk een ge-encrypte link met een aan hoge waarschijnlijkheid grenzende gevalideerde tegenpartij. Intrekken maakt meer kapot m.i.

Nou...

naast email heb je ook de loop die gemaakt moet worden hetzij via DNS records of DNS + webserver of .... op het moment van aanvraag.

Dus je moet DNS goed in kunnen stellen en/of je moet een webserver kunnen besturen.

Wat ik bedoel te zeggen is dat het niveau van verificatie vrij laag is. De web-content editor van ABN Amro bank zou een lets encrypt kunnen aanvragen voor abnamro.nl. Is het dan zeker dat het certificaat wat lets encrypt ondertekend gedragen wordt door de bank in kwestie? Nope. Is de beveiliging tussen de client en deze server veilig: jazeker: niemand kan meeluisteren.

idd. abn-amro heeft geen CAA record.
Er is wel een lijst voor CA's waarop staat wie de huidge uitgever van het record is.
Die behoren CA's ook re raadplegen.

Probleem is als iemand ANDERS een abn-amro site kan optuigen inclusief een certificaat,
Dan is het voldoende om het verkeer ernaartoe te leiden (bv. lijn tap, routing"foutje" bij een ISP
of een BGP injectie en al het verkeer dat bedoeld was voor de ABN-AMRO wordt ergens anders afgehandeld alsof het betrouwbaar is.

Was een verkeerd voorbeeld. abnamro.nl heeft wel een CAA record in het DNS. Maar ing.nl en triodos.nl bijvoorbeeld niet (raar).

En voor je 2e paragraaf: correct. Een DNS aanpassing in combinatie met een lets encrypt certificaat en je kunt als klant het verschil niet meer zien.

abn-amro.nl is blijkbaar een typo sqatter.. accoord.

De web-content editor heeft geen rechten om de DNS aan te passen of een bestandje in .well-known/acme-challenge te zetten voor de HTTP(S) verificatie.

wat een onzin, die certificaten zouden juist veiligheid moeten garanderen....dat doen ze niet...dus moeten ze ingetrokken cq vervangen worden!

Het is zeer zorgelijk dat men deze certificaten niet intrekt/vervangt voor geldige versies!

De certificaten zijn gewoon ok. Domeinvalidatie is gewoon gedaan. Er is geen veiligheidsprobleem oid met deze certificaten.

Dus waaruit blijkt volgens jou dat die certificaten gewoon ok zijn?

De regels bepalen onder welke omstandigheden er een veiligheidsprobleem is waarbij een certificaat ingetrokken moet worden. Zoals ik Let's Encrypt begrijp hebben ze eerst geconcludeerd dat de regels niet voor niets zo streng zijn en ze die certificaten dus gingen intrekken. Dat ze vinden dat die regels voor goede redenen zo streng zijn bevestigen ze ook nu nog. Maar nu ze achteraf alsnog maar controles hebben uitgevoerd en omdat veel certificaten niet vervangen dreigde te worden stellen ze opeens dat ze vinden dat die regels niet zouden moeten tellen. Alleen is Let's Encrypt is niet de organisatie die de regels bepaalt waar iedereen vertrouwen in heeft. Die regels worden gezamenlijk besloten en daar beloof je als CA aan te voldoen anders kan je als CA uitgesloten worden als een betrouwbaar om certificaten uit te delen en in te trekken.

Ze zijn ok omdat de enige lek hierbij een domein zou zijn die LE's machtiging om een CA te zijn voor dat domein te hebben ingetrokken. Die betreffende domeinen zijn opgespoord en hun certificaten (ruim 400) zijn wel direct ingetrokken. In de andere gevallen is er geen sprake van onrechtmatige verlenging van het certificaat, alleen de originele check hiervoor was niet goed (checkte maar 1 domein meerdere keren).

De originele check voldeed niet aan de eisen om een certificaat geldig te verstrekken. Dat is niet een kwestie van het voldeed slechts daaraan niet, het voldoet niet aan een cruciale eis. De check achteraf is ook niet volgens afspraak. De enige certificaten die aan de eisen voldoen is die op de juiste manier zijn uitgegeven. Dat is waarom we een CA vertrouwen, juist niet omdat een CA achteraf de eigen fouten probeert goed te praten door met eigen regeltjes te komen.

edit:
Hoezo ongewenst/off-topic? Als je het niet eens bent, geef dan commentaar en ga niet wegmodden.

[Reactie gewijzigd door kodak op 6 maart 2020 09:48]

Het klopt dat de gang van zaken onjuist was maar dat maakt een certificaat nog niet onveilig. Dat heeft immers een technische onderbouwing en niet een beleidsmatige. Een fietsslot is niet opeens onveilig omdat het slot zonder goede check van toestemming van de fietseigenaar om de fiets is gelegd. Als later blijkt dat die toestemming wel aanwezig was dan hoef je toch niet opeens andere fietssloten te gaan gebruiken

[Reactie gewijzigd door Lekkere Kwal op 6 maart 2020 07:51]

De regels zijn er niet alleen omdat het anders onveilig. Ze gaan om vertrouwen op basis afgesproken minimale eisen en dat een CA zich daaraan beloofd te houden. Als een CA maar wat gaat doen wat hun eigen mening is dan is het einde zoek. Dat ze een punt hebben dat het resultaat van intrekken vervelend kan zijn, gebruikers en websites er last van hebben? Dat is de afspraak. Doe je je werk niet goed dan heeft dat opzettelijk vergaande gevolgen. Dat is altijd al zo geweest en lets encrypt heeft nauwelijks iets gedaan om dat risico weg te nemen. Nu blijkt dat lets encrypt de certificaateigenaren niet kan bereiken en een miljoen eigenaren niet goed met incidenten om willen of kunnen gaan omdat het te makkelijk is gemaakt past Lets encrypt de regels zelf maar aan. Maar dat is niet de afspraak. Als ze er problemen mee hebben dan ga je niet even zelf als CA de gezamenlijke afspraken negeren. Dat is namelijk ook het systeem onveilig maken. Een ca moet te vertrouwen zijn en vooraf duidelijk zijn waar de grenzen liggen, niet wispelturig zijn en zelf maar wat doen omdat het ze zelf beter uit komt als ze zelf blunders begaan. Want waar ligt dan de volgende afwijking? Ze hebben het nu al zo opgerekt dat een certificaat 90 dagen onveilig mag zijn omdat ze dat zelf makkelijk vinden.

Je klinkt een beetje als een ambtenaar die iets afkeurt omdat het niet volgens regeltjes X en Y is gegaan.

Een fietsslot dat niet volgens de regels wordt toegepast is technisch niet opeens een onveilig slot, daarvoor moet je kunnen onderbouwen dat bijvoorbeeld de sleutel in andermans handen kon zijn geweest, of dat er onzekerheid is over de sterkte van het materiaal omdat er een deel van de keten niet is gecontroleerd. Maar als die zaken in orde zijn en alleen er een beleidsmatig aspect verkeerd is gegaan (toestemming om het om de fiets te leggen) dan is die overtreding niet opeens een diskwalificatie van de veiligheid van dat specifieke slot (of die groep die zo is geplaatst).

Dat het volgens de regels moet gaan want 'anders wordt het een zooitje' klopt, maar dat is geen argument om iets wat aantoonbaar veilig is te moeten diskwalificeren alleen maar op basis van principe. Dan zorg je voor meer problemen dan het oplost, immers het intrekken van die certificaten gaat er niet voor zorgen dat het in de toekomst beter gaat dan als je ze niet intrekt. Het is puur een extra effect achteraf voor de betrokken partijen, niet voor de beveiliging in de toekomst. Dat zou het wel zijn als je bijvoorbeeld audits zou afdwingen van implementaties zodat dit soort fouten niet alleen door de CA zelf gemaakt en gekeurd kunnen worden. Dan los je een daadwerkelijk risico op, niet door nog eens extra moeilijk te doen voor iets wat al is gebeurd.

Je hoeft me er niet van te overtuigen dat het ook anders kan. Wat ik aangeef is dat het vertrouwen gebaseerd is op de afspraken. Er is verder weinig anders waar iedereen zich in kan vinden als oplossing. Hoe is het eenzijdig afwijken volgens jou dan een oplossing om het vertrouwen te behouden? Want terugvallen op ik doe lekker wat ik zelf wil en anderen moeten daarom maar vertrouwen in me hebben lijkt me niet de oplossing als je als CA een enorme verantwoordelijkheid hebt.

Dat het vertrouwen er een deuk van krijgt is helemaal waar, maar daar ging het niet om weet je nog, jij vroeg

Dus waaruit blijkt volgens jou dat die certificaten gewoon ok zijn?

Niet welke keuze het beste zou zijn voor het imago van LE, of voor andere aspecten in dat opzicht. Simpelweg omdat je een certificaat technisch kan beoordelen op veiligheid, los van het imago van de CA en hun handelswijze.

Dan snap je de bug niet helemaal goed, en de acties die ze nu ondernomen hebben.

Normaal gesproken moeten ze op het moment van uitgifte alle checks doen. Bij 1 vd 2 checks ging het nu fout (een die vrij recent erbij is en vroeger niet bestond). Die check hebben ze nu achteraf nog een keer gedaan (maar nu goed) en daar zijn 445 certificaten uitgekomen die niet door de tweede check heen komen. Die hebben ze nu ingetrokken.

Het enige wat je nu niet weet is of de certificaten die niet ingetrokken worden op het moment van aanvragen een correct CAA record hadden, maar dat ze dat nu wel hebben.

[Reactie gewijzigd door Kees op 5 maart 2020 17:57]

CAA records werden te lang bewaard. Dus als je 29 dagen geleden een aanvraag deed dan en nu weer dan was het CAA record nog geldig voor Boulder (de certificaat uitgeef software).
Als jij 10 dagen geleden naar een andere certificaatboer uitgeweken bent dan controleerde boulder niet de actuele toestand. Nu had die periode niet meer dan 8 uur mogen zijn.

Dat is waar de bug over gaat. CAA check werd mogelijk gedaan met data tot 30 dagen oud. Die inmiddels niet meer klopte.

Nu maar hopen dat let's encrypt met een oplossing komt om certificaten wel snel in te kunnen trekken als dat nodig is. Want blijkbaar zijn let's encrypt en de eigenaren van de certificaten niet in staat om snel certificaten te kunnen vervangen als dat afwijkt van het gewone updaten.

Zij zijn alleen verantwoordelijk voor het intrekken, niet het vervangen. Dat zou betekenen dat als een hacker jouw certificaat steelt en deze ingetrokken wordt, hij gewoon doodleuk weer een nieuwe krijgt.

Ze kunnen als CA doormiddel van OCSP die certificaten gewoon terugtrekken net als een normale CA, zie bijvoorbeeld: https://letsencrypt.org/docs/revoking

Ze voelen zich verantwoordelijk als er te veel certificaten niet tijdig vervangen worden als ze die intrekken. Het is namelijk een groot deel van het excuus om het intrekken toch maar niet te doen.

Ze voelen zich verantwoordelijk als er te veel certificaten niet tijdig vervangen worden als ze die intrekken.

Ja, dat heeft een reden; reputatie. Wanneer er veel mensen issues krijgen omdat certificaten niet op tijd vervangen worden veroorzaakt door een fout aan de kant van LetsEncrypt kan dat voor een behoorlijke deuk in het image zorgen. Het meest veilig is wel intrekken.

Nee er zijn mensen die aangegeven hebben dat ze niet aan paniek voetbal moeten gaan doen maar gerichter intrekken.
Dus een gericht schot met een kogen ipv. met hagel schieten.

Er worden nu 445 certificaten ingetrokken, die aantoonbaar niet aan de voorwaarden kunnen hebben voldaan.

Zie ook:
https://community.letsenc...ficates-on-march-4/114864

[Reactie gewijzigd door tweaknico op 6 maart 2020 11:17]

Als iedereen de Let's Encrypt certificaten automatisch laat vernieuwen zoals in de instructies staan, is er elke dag een check; daarmee kan Let's Encrypt de onveilige certificaten al mee vervangen. 90 dagen is dan wel het maximum, en ik zou verwachten (maar dat is een aanname) dat het merendeel van de certificaten al vervangen is.

Certbot bepaalt eerst lokaal of een cert vernieuwd moet worden en gaat pas dan contact opnemen met de Letsencrypt-servers.

Doet certbot zelf ook geen check met de revokelist?

wellicht, maar revoked = revoked, want die lijst is ook in gebruik door browsers, dus dan zou je alsnog sites p zwart zetten.

Als certbot niet alleen lokaal kijkt naar de validity period maar ook naar de CRL dan vervangt het dus automatisch het certificaat. Dan gaat je site wel op zwart voor heel veel mensen (een kleine minderheid controleert geen CRL) maar lost het zichzelf binnen 12 uur (default) op.

Maar afaik kijkt certbot alleen naar de validity period van het lokale certificaat.

Nee, dat doet de Certbot niet. Maar zou een interessante toevoeging zijn.

Op het Let's Encrypt forum las ik dat hier wel over gedacht wordt maar het nog niet geïmplementeerd is.

Hoevaak er gecheckt word ligt volledig aan de kant die het cert implementeert.
Elke dag kan, maar ook elke maand bv. Ik doe het zelf in een cron job waarvan ik zelf de frequentie bepaal.
Ik zou er niet zonder meer vanuit gaan dat iedereen het elke dag doet.

[Reactie gewijzigd door jozuf op 5 maart 2020 16:50]

Zie FAQ: https://community.letsenc...ficates-on-march-4/114864

Niet intrekken betekent dus ook dat door die bug de certificaten niet geverifieerd kunnen worden en dat je niet zeker kan zijn dat het certificaat de juiste is. Met andere woorden: een vals gevoel van veiligheid. Is dit niet NOG veel gevaarlijker dan geen cert?
Al die webadmins die na het ontvangen van een mail door letsencrypt dat de certificaten vernieuwd moesten worden en het niet hebben gedaan zijn wat mij betreft: https://watbenjedan.nl/
Ik heb in ieder geval certbot aan het werk gezet direct nadat ik dat mailtje ontving.

Dat is dus niet waar, zoals al door meer uitgelegd hierboven. Enkel CAA record is niet goed gechecked (en enkel alleen voor de SANs) . Domeinvalidatie is gewoon gedaan. Geen enkele reden nu om je certificaten te vervangen.

Dus als er op 3 maart een mail wordt gestuurd door letsencrypt dat op 4 maart alle certs worden ingetrokken. Dat er voor die tijd een vernieuwing gedaan moet worden om te voorkomen dat de website(s) zonder cert komen te zitten, dan hoeft die vernieuwinng niet uitgevoerd te worden omdat?
Letterlijke tekst in de email van letsencrypt:

We recently discovered a bug in the Let's Encrypt certificate authority code,
described here:

https://community.letsenc...caa-rechecking-bug/114591

Unfortunately, this means we need to revoke the certificates that were affected
by this bug, which includes one or more of your certificates. To avoid
disruption, you'll need to renew and replace your affected certificate(s) by
Wednesday, March 4, 2020. We sincerely apologize for the issue.

If you're not able to renew your certificate by March 4, the date we are
required to revoke these certificates, visitors to your site will see security
warnings until you do renew the certificate. Your ACME client documentation
should explain how to renew.

Ik bedoelde het ook vanuit het oogpunt van dat het niet veilig zou zijn. Ik heb er ook wat vernieuwd omdat ze anders ingetrokken zouden worden

Het is een beleidsregel die ze nu overtreden, geen inherent veiligheidsissue (behalve die specifieke 445, maar die trekken ze dan ook in)

Beetje zoals dat recent Sectigo certificaten vervangen moesten worden, omdat er ‘privacy-gevoelige’ gegevens in zouden staan (ging om het State veld voor EV’s ofzo, echt te onbenullig voor woorden).
https://www.sslcertificat...tie/Vervanging_Sectigo_EV

Dat was niet een echt veiligheidsrisico, maar niet volgens de regels, dus: vernieuwen.

[Reactie gewijzigd door Keypunchie op 5 maart 2020 18:53]

Is er een overzicht welke sites dit zijn?

Dat is niet erg boeiend, het is niet de 'schuld' van die websites. Ik kreeg ook een mail dat mijn certificaten voor *.tweakers.net gerenewed moesten worden, dat is gelukkig 1 jenkins job starten en klaar.

Vind ik best boeiend, want er kunnen sites van mij tussen zitten. Maar goed, misschien voor alle zekerheid een -renew uitvoeren.

Als je er tussen zat kreeg je er een mail van. Als je tenminste netjes je mail invult

Sites niet, wel welke serials (op één certificaat kunnen honderden sites staan). Tevens staat er een tool online om te kijken of jouw site getroffen is: https://checkhost.unboundtest.com/

Dit (en meer) staat ook in het eerdere bericht (dat ook gelinkt staat in het nieuwsbericht): nieuws: Let's Encrypt trekt drie miljoen certificaten in vanwege bug

Ik ben er eigenlijk wel een beetje begrip voor want het intrekken van certificaten is duur en lastig voor heel internet. Als je een certificaat intrekt (in plaats van het te laten verlopen) dan komt het op een zwarte lijst te staan. Iedere computer op internet moet voor iedere verbinding die hele lijst controleren. De hele procedure is helaas een beetje ouderwets en traag. Daarom staat die controle in de meeste browsers helaas uit. Dat is fijn voor de snelheid maar niet zo best voor de veiligheid, want als je niet controleert kunnen ingetrokken certificaten gewoon gebruikt blijven worden.

Als we anderhalf miljoen certificaten aan die lijst zouden toevoegen zou dat voor een hoop extra vertraging zorgen. Vandaar dat je altijd goed moet nadenken of het echt nodig is om een certificaat in te trekken. Dat ze niet in een keer anderhalf miljoen certificaten aan die lijst toevoegen terwijl dat waarschijnlijk niet nodig is vind ik dus wel verdedigbaar.

Maar als ik het goed heb zijn die +-1.5 miljoen wel degelijk ingetrokken.

Overigens heb ik de indruk (maar ik weet van dit stukje heel weinig van af), dat met OCSP het niet zo'n issue is. Je hoeft dan niet een hele lijst binnen te halen, maar je doet een request naar een server, die een lekkere dikke database heeft en je gewoon "ok/niet ok" terug geeft.

Voor een beetje database moet 1.5 miljoen text records (je vraagt serienummers op) geen probleem zijn.

[Reactie gewijzigd door Keypunchie op 5 maart 2020 17:24]

Klopt. OCSP is al een stuk beter dan CRL.
Helaas ondersteunt lang niet alles OCSP, Chrome kan het bijvoorbeeld niet.

Maar naar ik begrepen heb doet Chrome alleen maar revocation check voor Extended Validation sites.
En die levert Let's Encrypt om te beginnen toch niet?

[edit]
Overigens heb ik het idee dat we het om te beginnen met elkaar eens zijn dat kort geldige certificaten een betere bescherming zijn dan wat voor revocation mechanisme dan ook.

[edit2]
Ik zou vooral beargumenteren dat Let's Encrypt beter wel alles revoked. Nu al heeft de helft van de beheerders hun certificaat vervangen (is ook vrij makkelijk), en de andere helft doet het snel genoeg nadat intrekken gevolgen heeft. (en 1.5m vs. 3m maakt voor de revocation-lists ook niet echt uit)

Alternatief zouden ze nog iets meer tijd kunnen gunnen voor vervanging, een week ofzo.

[Reactie gewijzigd door Keypunchie op 5 maart 2020 17:45]

Ja, korter is beter, ook omdat het revocation minder duur maakt.

AFAIK doet Chrome geen OCSP maar heeft het een ingebouwde lijst van geblokkeerde certificaten. Ik neem aan/hoop dat Google die regelmatig bijwerkt maar ik heb geen idee volgens welk mechanisme.

In een ander topic heb ik het over DANE, een systeem dat fingerprints van certificaten in DNS publiceert zodat je geen CA meer nodig hebt. Een bijkomend voordeel van DANE is dat je certificaten ongeldig kan maken door het DANE record uit je DSN te halen. Zo kun je heel snel schakelen.

Wat ik in de reactie van Let's encrypt lees is: wij mogen alleen een CA zijn onder zeer strenge regels en die regels zijn voor hele goede redenen zo streng. Maar omdat wij zien dat veel gebruikers straks geconfronteerd gaan worden met ongeldige certificaten omdat die niet op tijd zijn vernieuwd hebben we besloten dat onze mening maar voldoende moet zijn. Om daarmee indirect te stellen dat ze de regels maar even niet voor hun Let's encrypt moeten gelden.

Heb voor de zekerheid net maar even mijn certificaten vernieuwd met:

certbot renew --force-renew

[Reactie gewijzigd door MaartenBW op 5 maart 2020 17:00]

Je had het kunnen checken via:
$ curl -XPOST -d 'fqdn=letsencrypt.org' https://checkhost.unboundtest.com/checkhost

Vervang letsencrypt.org met jou domein.
Stond op de letsencrypt site

The certificate currently available on tweakers.net is OK. It is not one of the certificates affected by the Let's Encrypt CAA rechecking problem. Its serial number is 0375bdc8f2e30d6e840a0c1e3e55b6c953b1
The certificate currently available on tweakers.nl is OK. It is not one of the certificates affected by the Let's Encrypt CAA rechecking problem. Its serial number is 0375bdc8f2e30d6e840a0c1e3e55b6c953b1

"Daarvan blijven uiteindelijk 445 certificaten over, die donderdag door de organisatie worden ingetrokken."

zouden worden ingetrokken, neem ik aan.

Nee, dit aantal wordt alsnog ingetrokken.

The following certificates have been, or will be, revoked prior to the compliance deadline at 2020-03-05 03:00 UTC (9pm U.S. ET tonight):

1,706,505 certificates that we are confident were replaced during the incident period

445 certificates that we treated as highest priority for revocation because, at the time we found the bug, they had CAA records that forbid issuance by Let’s Encrypt.

Dat is interessant, want ondanks dat de eigenaar heeft aangegeven dat er voor het domein in kwestie geen certificaat mocht worden uitgegeven door Let's Encrypt, zijn de certificaten dus wel aangevraagd (en door de bug ook daadwerkelijk uitgegeven). Blijkbaar heeft daar dus iemand zijn zaakjes niet goed op orde.

Het kan best zo zijn dat er een certificaat is aangevraagd voor een domein om 'm in ieder geval direct up and running te hebben, en dat vervolgens is overgestapt op een andere cert-aanbieder (en dat in CAA is dichtgezet). Dan was op het moment van aanvragen alles in orde en het CAA-record niet aanwezig of zodanig dat Let's Encrypt het cert uit mocht geven, maar is dat nu niet meer zo. Geen heel onwaarschijnlijk scenario gezien het gemak van LE.

Ik denk eerder dat ze overgestapt zijn naar LE en daarvoor een andere CA hadden. Maar omdat het record niet werd gechecked bij meerdere domeinen (alleen het eerste domein werd gechecked) viel dat gewoon niet op, en het werkte gewoon dus er was ook geen reden om de CAA records aan te passen.

We weten niet meer wat er ten tijde van het aanvragen in het CAA-record stond, we kunnen alleen zien wat er NU staat. Er zijn best veel hosters die bij het aanmaken van een nieuwe klant / website daar automatisch een LE cerificaat op zetten.

Als die klant vervolgens een CAA-record aanmaakt en er een ander certificaat op zet, dan heb je dus N dagen (n<90) waarop er volgens LE een niet-verlopen certificaat voor dat domein is, maar die site dat certificaat niet meer gebruikt (en mogelijk zelfs de private key niet meer heeft)

Ik ben ergens wel benieuwd naar hoeveel van die 445 sites dat certificaat daadwerkelijk gebruiken Alleen niet benieuwd genoeg om het uit te zoeken

Dat laatste inderdaad

Je uitleg klinkt plausibel, het is een scenario waar ik niet over had nagedacht omdat ik erg tevreden ben over Let's Encrypt dus er geen moment over heb nagedacht dat je binnen de looptijd van je certificaat zou willen overstappen van CA.

Het staat slecht beschreven in dit artikel, maar de bron maakt het duidelijk:

445 certificates that we treated as highest priority for revocation because, at the time we found the bug, they had CAA records that forbid issuance by Let’s Encrypt.

Die 445 certificaten hebben geen geldig CAA record, dus die beschouwen ze als niet geldig. Daarom zullen ze ze wel verwijderen.

Van het andere deel zal het gros waarschijnlijk geen probleem hebben, en verwachten ze meer problemen door ze wel te verwijderen.

Een CAA record zit op de zone van je domein om bepaalde CA's te whitelisten. Als domeineigenaar geef je daarmee dus aan welke CA's een domein mogen uitgeven voor je domein. Áls een domein een CAA record heeft, en letsencrypt.org wordt daar niet in genoemd als toegestane issuer, dan mag LE dus geen certificaat uitgeven voor dat domein. Maar omdat de CAA verificatie niet goed werkte werd dat toch gedaan.

[Reactie gewijzigd door .oisyn op 5 maart 2020 17:12]

Hmm.. dat snap ik. Wat ik niet snap is waarom browsers daarop (blijkbaar) niet controleren. Doen ze dat wel, dan maakt het weinig uit als een verkeerde CA certificaten uitgegeven heeft. Die worden dan toch niet geaccepteerd. Lijkt me een veel betere methode dan te vertrouwen op de CA's om geen certificaten uit te geven waartoe ze niet gerechtigd zijn.

Browsers controleren alleen maar de geldigheid (datums en naam), en tegenwoordig de OCSP status (het protocol waarmee een certificaat ingetrokken kan worden)

Als een browser ook een CAA record moet checken, dan wordt het lastiger om te wisselen van certificaat leverancier.
Stel je hebt een certificaat wat een jaar geldig is van CA1 en je wilt overschakelen naar CA2. Dan moet je:
- je CAA record aanpassen zodat beide CA1 en CA2 toegestaan zijn
- wachten totdat je DNS TTL verlopen is
- certificaat aanvragen bij CA2
- certificaat installeren
- CAA record aanpassen zodat alleen CA2 toegestaan is

Gelukkig dus dat alleen de CA's een CAA record controleren, en niet de browsers.

Nee, die 445 worden wel degelijk ingetrokken, "because, at the time we found the bug, they had CAA records that forbid issuance by Let’s Encrypt".

Wat betreft gebruiksvriendelijkheid begrijpelijk maar vanuit pure security een dubieus besluit, zeker omdat het bij certificaat uitgifte en gebruik in grote mate om vertrouwen gaat (daarom accepteren de meeste mensen ook geen certificaten uitgegeven door de slager op de hoek). Het gaat om een zeer groot aantal certificaten; ruim drie miljoen, 2,6 procent van het totale aantal actieve certificaten.

Het gaat om het volgende issue:

On 2020-02-29 UTC, Let’s Encrypt found a bug in our CAA code. Our CA software, Boulder, checks for CAA records at the same time it validates a subscriber’s control of a domain name. Most subscribers issue a certificate immediately after domain control validation, but we consider a validation good for 30 days. That means in some cases we need to check CAA records a second time, just before issuance. Specifically, we have to check CAA within 8 hours prior to issuance (per BRs §3.2.2.8), so any domain name that was validated more than 8 hours ago requires rechecking.

The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.

Ik zie een mooie link naar dit artikel van vandaag: nieuws: SIDN: afhankelijkheid van klein aantal partijen voor tls-certificaten...

[Reactie gewijzigd door Bor op 5 maart 2020 16:50]