Storing door verlopen Let's Encrypt-certificaat treft miljoenen gebruikers

Het verlopen van het verouderde digitale root-beveiligingscertificaat DST Root CA X3 van Let's Encrypt zorgde voor storingen en foutmeldingen voor enkele miljoenen gebruikers. Een onbekend aantal diensten, websites en apps werd niet op tijd van een nieuw certificaat voorzien.

Veel techbedrijven hadden op 30 september last van storingen omdat Let's Encrypt's IdentTrust DST Root CA X3-certificaat verlopen was. Na het vooraf aangekondigde verlopen van het certificaat waren uiteenlopende services, browsers, games, websites en apps naar schatting tijdelijk voor miljoenen gebruikers niet toegankelijk of functioneerden niet meer goed of veilig. In het ergste geval konden apparaten zelfs geen verbinding met het internet meer maken.

De precieze omvang van het incident is niet bekend. Vooral oudere apparaten als de PlayStation 4 en Android 7.1.1-smartphones zouden door connectieproblemen getroffen zijn, zeker wanneer het bijbehorende besturingssysteem of de firmware al een tijdje niet geüpdatet was. Beveiligingsexpert Scott Helme waarschuwde een week geleden al voor de problemen. Hij zegt tegen ZDnet dat hij op vrijdag inderdaad verschillende diensten met storingen zag. Een precieze omvang noemt hij niet. Onder andere Shopify en Heroku beschrijven op hun statuspagina's dat ze recent aan het certificaat gerelateerde storingen hebben opgelost. Helme noemt ook Bluecoat, Cisco Umbrella, Catchpoint, Guardian Firewall, Monday.com, PFsense, Google Cloud Monitoring, Azure Application Gateway, OVH, Auth0, Shopify, Xero, QuickBooks, Fortinet, Heroku, Rocket League, InstaPage en Ledger.

Honderden miljoenen websites wereldwijd gebruiken door Let's Encrypt uitgegeven certificaten voor een beveiligde https-verbinding. Doorgaans bereiden bedrijven zich ruimschoots voor het verlopen van essentiële digitale certificaten voor op een dergelijk moment. Omdat er in een korte tijd intermediate- en root-certificaten verliepen, zijn veel servers, browsers en besturingssystemen niet op tijd geüpdatet, zo legt Let's Encrypt-topman Josh Aas tegenover TechRadar uit.

De non-profitorganisatie Let's Encrypt is 's werelds grootste certificaatautoriteit en schreef in de afgelopen jaren ruim 2 miljard digitale certificaten uit. Het DST Root CA X3-certificaat werd in samenwerking met IdentTrust uitgeschreven en zorgt voor een versleutelde connectie. Ondertussen moeten alle voorheen op DST Root CA X3 rustende services overgestapt zijn op IdenTrust Commercial Root CA 1 om zonder problemen te blijven functioneren.

Reacties (110)

Doorgaans bereiden bedrijven zich ruimschoots voor het verlopen van essentiële digitale certificaten voor op een dergelijk moment.

Haha… de schrijver heeft blijkbaar nog niet veel IT bedrijven van binnen gezien. Het verlopen van certificaten is 1 van de meest voorkomende redenen voor uitvallen van diensten/services. Monitoring is vaak niet tot slecht op orde. Vervolgens moet er in alle paniek een nieuw certificaat aangevraagd worden of een brakke work around bedacht worden.
De keren dat ik dit al bij vele bedrijven heb zien gebeuren zijn niet meer op mijn handen en voeten te tellen…

Haha… de schrijver heeft blijkbaar nog niet veel IT bedrijven van binnen gezien. Het verlopen van certificaten is 1 van de meest voorkomende redenen voor uitvallen van diensten/services. Monitoring is vaak niet tot slecht op orde. Vervolgens moet er in alle paniek een nieuw certificaat aangevraagd worden of een brakke work around bedacht worden.
De keren dat ik dit al bij vele bedrijven heb zien gebeuren zijn niet meer op mijn handen en voeten te tellen…

Ik beaam ook dat dit een van de meest voorkomende "kleine" problemen is dat ik veel bij onze partners zien. Binnen mijn eigen organisatie valt het enorm mee sinds wij het intensief monitoren. Dan nog gaat het wel eens mis, maar goed.

tips:
- monitoring: monitor alles en geef je zelf minstens 2 weken om een cert te vervangen
- standarisatie: zet je certificaten (waar mogelijk) op een voorspelbare locatie zodat je eenvoudig allemaal kan controleren
- network: monitor niet alleen files maar (juist) ook via netwerkverbindingen, configuratie is minstens zo belangrijk als de verloopdatum van het certificaat (bv of je SSL3 of TLS1.3 gebruikt)
- staggering: geef nodes van HA-systemen allemaal hun eigen certificaat met eigen verloopdatum, zodat niet je hele cluster tegelijk omvalt omdat 1 certificaat verloopot
- universeel: zet certificaten breed in. vraag je niet af of een cert wel nodig is, doe het als het kan. Liever wat te veel dan eentje te weinig.

[Reactie gewijzigd door CAPSLOCK2000 op 2 oktober 2021 11:32]

Je vergeet nog een belangrijke:

* Automation - Zorg ervoor dat vervanging van certs automatisch kan (Let'sEncrypt is hier heel goed in!)

"Let'sEncrypt is hier heel goed in!"

Tot het mis gaat bij LE

Niks mis gegaan bij LE toch?

Tnx, je hebt helemaal gelijk, zelfs binnen de IT lijkt nog niet iedereen door te hebben dat het vakgebied vaak 'automatisering' wordt genoemd en dat dit dus zo ongeveer standaar zou moeten zijn voor alles wat je doet. Maar je hebt gelijk, misschien is het wel de belangrijker dan de rest van die punten.

2 weken is wel het absolute minimum, inderdaad. 4 weken of meer is te adviseren. Dit vooral bij certificaten waarvan de jijzelf of de klant niet de eigenaar van de domeinnaam zijn, of zelf het DNS beheer niet uitvoeren. Dan moet je namelijk over zoveel schakels heen, dat je met 2 weken al gauw te kort komt.

En dan nog maar niet te spreken over PKIo certificaten...

2 weken is wel het absolute minimum, inderdaad. 4 weken of meer is te adviseren. Dit vooral bij certificaten waarvan de jijzelf of de klant niet de eigenaar van de domeinnaam zijn, of zelf het DNS beheer niet uitvoeren. Dan moet je namelijk over zoveel schakels heen, dat je met 2 weken al gauw te kort komt.

En dan nog maar niet te spreken over PKIo certificaten...

Yup, mijn tips zijn maar algemeen en voor interpretatie vatbaar. Als je het echt goed doet zorg je dat alles automatisch gaat en dat je nog steeds die twee weken speling hebt als het niet goed gaat.
Maar het is maar moeilijk om echt een "juiste" termijn vast te stellen. Als je een organisatie hebt waarin er één iemand verantwoordelijk is voor certificaten en die persoon zes weken op vakantie kan gaan (of ziek zijn) dan zul je zoveel extra speling moeten hebben. Een week of acht dus. Als je dan LetsEncrypt certificaten gebruikt die drie maanden geldig zijn en na twee maanden vervangen worden heb je een probleem want je "veiligheidsperiode" is net zo lang als de "gebruiksperiode" en je alarm staat altijd op rood en is daarmee nutteloos geworden.

De beste aanpak is natuurlijk zorgen dat je niet afhankelijk bent van één Single Point of Failure, of dat nu een persoon, systeem, certificaat of monitor is, en zorgen dat je het proces sneller maakt door automatisering, training of voorbereiding want er zullen altijd onverwachte gebeurtenissen blijven waardoor snel fouten herstellen belangrijk blijft, maar in praktijk is dat natuurlijk makkelijker gezegd dan gedaan.

Ik ben wel fan van DANE/TLSA omdat je daar geen CA voor nodig hebt. Je gebruikt een self-signed certificaat en je publiceert in DNS welk certificaat de gebruikers kunnen verwachten. DNS beheren is makkelijk zelf te doen, makkelijk redundant op te zetten, makkelijk te verdelen over meerdere hosters/aanbieders/leranciers en eenvoudig delegeerbaar (iedere afdeling/partner/leverancier/... kan z'n eigen stukje in eigen beheer krijgen). En het is nog snel ook, zelfs in vergelijking met LetsEncrypt. Je kan veranderingen in één seconde doorvoeren (wel even nadenken over cache-tijden, maar dat is niet moeilijk).
Je beheerders moeten dan wel op een of andere manier toegang hebben tot je DNS-infrastructuur maar dat is op zich een opgelost probleem, dat doen wel tientallen jaren, al het benodigde gereedschap is er.

Extra voordeel van DANE/TLSA is dat we onze TLS verbindingen niet meer hoeven te beginnen met een onversleutelde handshake. De client heeft al in DNS gezien dat TLS beschikbaar is en welk certificaat wordt gebruikt.

Tja, maar voor veep bedrijven is dit soort zaken niet hun dagelijkse business, zelfs niet IT bedrijven. Dus het is makkelijk praten als dit wel iets is waar je dagelijks mee van doen hebt.

Niemand werkt dagelijks aan (het verlengen van) certificaten en daarin schuilt meteen het probleem. Er zijn maar weinig IT-ers voor wie dit echt routine is en kleine en middelgrote bedrijven hebben meestal niet zo iemand in huis. Het feit dat certificaten in het verleden ook lang geldig waren, tot 3 jaar zelfs, heeft daar ook niet aan bijgedragen.
Certificaatbeheer is bij veel bedrijven dus slecht ingeregeld. Met de korte levensduur van Let's Encrypt certificaten is automatisering en monitoring onontbeerlijk en zal de situatie hopelijk verbeteren.

De tips zoals @CAPSLOCK2000 ze geeft kan ik zeker achter staan.

[Reactie gewijzigd door rbr320 op 2 oktober 2021 12:46]

Volgens mij is dit niet heel anders dan wat je met een goede contractmanagement tool ook kan doen, contracten hebben vaak ook een einddatum waarbij je ruimschoots vooraf een seintje krijgt dat die er aan komt. Volgens mij moet je gewoon je beheer op orde maken.

Natuurlijk heb je gelijk, het is heel erg vergelijkbaar met contractbeheer en iets dat een organisatie gewoon op orde zou moeten hebben. Contractbeheer is vaak belegd bij een afdeling inkoop of iets dergelijks waar mensen zitten die daar verstand van hebben en ook dan gaat het nog wel eens mis weet ik uit ervaring. Certificaten worden meestal beheer per project en dus de facto door de beheerders of ontwikkelaars op dat project, die er niet altijd even nauwkeurig mee om gaan. Als er goede monitoring en automatisering is ingericht zoals @CAPSLOCK2000 in zijn post adviseert gaat het meestal goed, maar dat is lang niet overal het geval.

"Contractbeheer is vaak belegd bij een afdeling inkoop of iets dergelijks waar mensen zitten die daar verstand van hebben"
Jaja, horen te hebben. Financiën zijn iets om op te besparen, dus betalen doe je zo laat mogelijk. Ondanks dat we vaak 3 maanden van te voren bij hen aan de bel trokken voor nieuwe license keys en het onderhandeltraject weken duurde, begon men er 2 weken van te voren aan, zodat we keer op keer temporary keys moesten aanvragen totdat er eindelijk betaald was.

Beetje makkelijk misschien, maar wie wordt er uit bed gebeld/op het matje geroepen als het stuk gaat? Iemand van IT of iemand van Financiën? Als je de situatie niet kan veranderen dan kun je ook niet verantwoordelijk gehouden worden. Als de taak van IT is om geld/licenties te vragen bij een andere afdeling dan moet je dat doen en daarop worden afgerekend. Het tijdig sturen van herinneringsmails kan je als IT-afdeling wel verzorgen en automatiseren.

Mensen zijn heel makkelijk met de tijd, het geld en de prioriteiten van anderen. Al is het maar omdat ze zelf een ander beroep hebben en dus gewoon niet echt snappen wat er achter zit. Zeker als ze een afweging moeten maken tussen "zelf last hebben" of "iemand anders heeft last", want ze weten hoe groot hun eigen last is maar de last voor de ander overzien ze niet, die lijkt dus altijd kleiner.

Dat werkt overigens twee kanten op. De afdeling IT snapt waarschijnlijk de overwegingen en uitdagingen van Financiën niet echt. Misschien maken ze zo echt wel de goede keuze en is de ellende van tijdige keys het financieel waard, voor hun afdeling. Maar het gaat je nooit lukken om een eerlijke vergelijking te maken tussen "gedoe voor IT" en "gedoe voor Financiën". Iedere afdeling vind zichzelf het belangrijkste en wil het liefst helemaal geen gedoe.

De logische conclusie is dat je de verantwoordelijkheid neerleggen waar de pijn gevoeld wordt en, omgekeerd, dat de pijn gevoeld wordt door diegene die overwogen beslissing kan nemen om het te veranderen, of niet. Misschien is het wel beter om eens per jaar een storing te hebben dan om veel geld te investeren in een onbelangrijke applicatie. Misschien is het wel beter om wekelijks uit bed gehaald te worden dan om een extra beheerder aan te stellen.

Als je zorgt dat de pijn op de juist plek terecht komt dan regelt het zichzelf. Misschien niet zoals je het zou willen maar het is in ieder geval niet meer jouw probleem.

Ik weet dat dit makkelijker gezegd dan gedaan is, zeker als je daarvoor bestaande afspraken moet veranderen. Neem het dus mee op het moment dat er iets nieuws wordt georganiseerd.

Als je zorgt dat de pijn op de juist plek terecht komt

Da's niet zo makkelijk. Wie wordt er na middernacht gebeld? Ik als standby. Probeer het dan maar eens door te schuiven tot de volgende ochtend, als Inkoop binnen is en de koffie op heeft en in de tussentijd een hele applicatie of service stil te laten liggen.

Da's niet zo makkelijk. Wie wordt er na middernacht gebeld? Ik als standby.

Precies, daar gaat het fout. Als jij gebeld wordt dan moet jij de middelen hebben om dit te voorkomen.
Heb jij er persoonlijk last van dat die applicatie niet werkt? Vast niet, waarschijnlijk zijn het de mensen bij Inkoop die er last van hebben. Dus ofwel krijgt Inkoop de verantwoordelijkheid om tijdig de certificaten te (laten) vervangen én zij worden gebeld als het fout gaat. Of jij krijgt die verantwoordelijkheid maar dan moet je die verantwoordelijkheid ook kunnen uitvoeren.

Het klinkt misschien een beetje flauw, dat "heb jij er last van?" en dat moet je zeker ook niet zo brengen . Ik bedoel niet dat je het werk over de schutting moet gooien of je aan je verantwoordelijkheid te onttrekken. Maar je moet de middelen hebben om je werk te doen. Storingen voorkomen hoort daar bij.

Ik den dat juist LE hier super is in het heel makkelijk maken en aansporen van automatiseren. Bij mijn vorige werkgever hadden we ook heel wat klanten die hun eigen certificaten aanleverden en dat was altijd een gezeik, dus die hebben we allemaal aangeraden om ons gewoon automatisch hun gratis LE-certificaat te laten vernieuwen. Er zijn een aantal diensten waar dat niet zomaar kan, zo zijn er mailclients die dan iedere maand gaan zeuren dat er weer een ander certificaat is omdat die niet per domein maar per server geregeld worden, maar voor een gewone website zou dit gewoon goed moeten gaan.

Klopt, heb er toen ik nog op de servicedesk werkte diverse keren mee te maken gehad tijdens standbydienst. Eén situatie die me nog altijd bijstaat is een situatie van een jaar of wat geleden met een klant die uit meerdere organisaties bestaat. In de zomer verliep het wildcardcertificaat van één van hun domeinen in het weekend waardoor ze onder meer niet meer op de loginpagina konden komen. Op zondag om 2:45 had ik ze aan de lijn om te testen of het allemaal werkte en konden ze overal weer bij, engineer heeft het certificaat op dat tijdstip maar met z'n eigen creditcard betaald om het gefixt te krijgen. Nog geen half jaar later verliep het wildcardcertificaat van één van hun andere domeinen waardoor de andere helft van hun medewerkers niets meer kon, toevallig toen ik en dezelfde engineer als de eerste keer standby hadden...

Na die tweede keer ben ik maar met de manager (servicedesk en beheer viel onder dezelfde manager) gaan zitten en heb voorgesteld om die controle naar ons te halen. Niet dat het daar hoorde, maar op hoger niveau gebeurde het kennelijk niet en wij hadden er het meeste last van omdat iedereen dan begon te bellen. Sinds dat moment hebben we het gelukkig niet meer meegemaakt, enkel een paar keer kleinschaliger omdat een certificaat niet overal vervangen bleek te zijn, dat was dan gelukkig wel snel gefixt.

Inmiddels zit ik al even in een niet-technische functie, maar die controle doe ik nog altijd.

is ook een conclusie die de schrijver niet neer kan zetten zonder, zich te identificeren als iemand met tig jaren ervaring in dat soort bedrijven. meer een beetje Telegraaf conclusie die de schrijver maakt.
Is sowieso een probleem de laatste tijd op tweakers, telegraaf titels, telegraaf conclusies.
Je zou bijna denken dat ze onderdeel zijn van een grote media groep.

Grootste probleem waar ik geregeld tegen aan loopt zijn DNS issues, van de week ook weer met slack..

https://imgur.com/WmRbmf5

Beste deskundigen,

Hier een soort van digibeet met een webshop en een probleem sinds begin oktober en deze storing is opgetreden met Let's Encrypt. Ik heb Shopify al gevraagd om hulp en alle suggesties die zij gaven uitgevoerd. Toch is het nog niet verholpen en ik wacht nog opm hun verdere reactie. Ondertussen ben ik oer toeval hier beland. Ik denk dat ik een nieuw certificaat moet installeren. Ik zag wel op een website staan de stappen hoe ik dat moet doen maar vind dat nog wel een dingetje zeg maar omdat ik er helemaal niet in thuis ben. Wat zou jullie advies zijn? En moet ik dan door een expert laten doen of kan ik dat zelf?

Helaas bleek certbot het bij ons niet automatisch te verhelpen. Door de prefered chain mee te geven was het uiteindelijk goed gezet.

certbot renew --force-renewal --preferred-chain "ISRG Root X1"

[Reactie gewijzigd door xFeverr op 1 oktober 2021 21:31]

Bij ons ook. Een update van win acme verhelp het probleem wel.

Helaas een update ook niet. Zijn uiteindelijk heel snel omgeschakeld naar een vergelijkbare dienst van cpanel, want we liepen omdat dit bleef hangen op de oude tegen rate limit van letsencrypt aan...

Ik zag het al aankomen een week terug: dit word een drama. Op de site van Let’s Encrypt staat de procedure totaal niet goed uitgelegd.

Bij de uitleg over de nieuwe cert chain stond bijvoorbeeld niet over hoe je kon switchen naar die chain, bizar. Wel werd er gehint dat alles automatisch zou gaan en dat het alleen op hele oude apparaten (Android 4.4) voor issues zou zorgen.

Echt bizar hoe slecht ze zit hebben aangepakt. Waarom in vredesnaam niet al vorig jaar, of in elk geval een half jaar terug de nieuwe chain als default zetten en al je gebruikers informeren?

Als mijn cert binnen een week verloopt krijg ik een mail. Maar als de hele chain niet meer geldig is hoor je niks. Echt heel raar.

Op de site van Let’s Encrypt staat de procedure totaal niet goed uitgelegd.

Onzin. Alles staat piekfijn beschreven; zolang je geen OpenSSL <1.1.0 gebruikt, gaat alles vanzelf.

Echt bizar hoe slecht ze zit hebben aangepakt.

Wederom onzin. Als je om je heen kijkt, kun je zien dat het fouten zijn in de implementaties van clients, of laksheid van vendors die hun cert stores niet willen updaten.
Niet de verantwoordelijkheid van LE, maar van de systeemintegrators.

Certify The Web deed dat ook niet automatisch. Handmatig op het renewal knopje klikken, verhielp het probleem.

Uitstekend programma verder. Heeft me verlost van al m'n SSL-gerelateerde kopzorgen.

Op mijn Plesk hosting blijkbaar geen probleem...

Er zijn vandaag ook flink wat klachten te lezen op het Plex forum over de app op Samsung en LG smart tv's die helemaal niet werkt of waarbij bepaalde bestanden niet werken en een 'unexpected playback error' geven
Dit probleem wordt verholpen door de instellingen 'allow unsafe connections' en 'prefer unsafe connections' op always te zetten
Aangezien een de error dus alleen bij een 'safe connection' plaatsvindt, heeft het hoogstwaarschijnlijk met encryptie te maken
En aangezien Let's Encrypt de certificaten voor Plex verzorgt lijken de verlopen certificaten ook hierbij de boosdoener

Ook OpenVPN, in ieder geval wanneer dit gebruikt wordt op een Synology NAS, had hier last van
Door de VPN Server applicatie te updaten en de nieuwe configuratie, met dus het nieuwe certificaat, te exporteren en te gebruiken in OpenVPN app/GUI wordt dit probleem opgelost

[Reactie gewijzigd door Stijnvi op 2 oktober 2021 01:05]

Dit probleem wordt verholpen door de instellingen 'allow unsafe connections' en 'prefer unsafe connections' op always te zetten

Dat is dus precies wat je niet moet doen. Daarmee zet je de TLS-verificatie uit en sloop je in feite dus de beveiliging. Dan kun je bijna net zo goed helemaal geen TLS meer gebruiken.

Ja, het is daardoor inderdaad niet veilig
Maar anders kan je gewoon niet bij een deel van je materiaal van Plex op dit moment
Dus het is even een tijdelijke oplossing om alsnog Plex te kunnen gebruiken

https://github.com/dehydrated-io/dehydrated - Handig tooltje om via CLI snel SSL certificaten aan te vragen en automatisch te vernieuwen

Wat ik oprecht niet begrijp is hoe zoveel grote bedrijven een datum die al jaren bekend was compleet missen. Is dat laksheid of misplaatste zuinigheid?

Probleem is tweeledig. Er is destijds gekozen voor een cross-sign met de X1 en de X3 root zodat oude meuk zonder X1 in de CA root store bleef werken.
Probleem is dat oude clients zoals certify en wacs vervolgens de oude intermediate certificaten deployen, waardoor de browser uitkomt op het verlopen root certificaat.
Probleem 2 is dat OpenSSL 1.0 alsnog triggert op de 2e chain ongeacht wat je serveert. Een heleboel commerciele software draait nog met OpenSSL 1.0 ipv 1.1, wat dus voor problemen zorgt aan de client kant. Onder meer dure commerciële firewalls met SSL inspectie gingen hier compleet op kapot.

Ik heb donderdag stuk of 8 servers bij een klant moeten voorzien van nieuwe certify of wacs, maar ook pfsense maakte er een zooi van, ik moest gewoon alle certificaten weggooien incl CAs en daarna opnieuw aanvragen, anders bleef pfsense de foute chain samenstellen. Leuk als je VPN server met letsencrypt draait...

En niet alleen oude OpenSSL. Ook de huidige LibreSSL (inmiddels patch beschikbaar [1]) snapte de "domain cert > intermediate cert dat ook geldig root cert is > expired root cert" constructie niet. Dat viel als systeembeheerder niet echt te voorzien, waardoor het halve internet even stuk ging

[1] https://marc.info/?l=open...nce&m=163303141426965&w=2

Wacht, in OpenSSL was dit dus opgelost, maar LibreSSL, dat een fork was met het doel een slankere implementatie te bouwen die veel beter te onderhouden was, heeft dit niet op tijd ingezien? Dan vraag ik me ineens af: welke meerwaarde heeft LibreSSL eigenlijk nog?

Ja, want als LibreSSL één probleem niet oplost dat in OpenSSL zat is het natuurlijk compleet waardeloos. Het was immers de belofte dat het alle bugs die in OpenSSL zat zou oplossen, en wel onmiddellijk. /s

Ook LibreSSL is gewoon software, heeft gewoon fouten, is niet perfect. Het is in het leven geroepen omdat OpenSSL het in korte tijd erg bont maakte met beschamende bugs die aan het licht kwamen door brakke, onvoorspelbare code waarin nog veel meer bugs van dien aard konden schuilen. Dit klinkt meer als een ordinair probleem in de logica, een uitzondering waar de implementatie de verkeerde keus maakt om alle certificaten te controleren op geldigheid in plaats van alleen de relevante (iets waarbij je de standaard erbij moet pakken om te zien wat correct is). Zulke dingen zal LibreSSL niet altijd beter doen dan OpenSSL; dat wil niet gelijk zeggen dat het dus geen meerwaarde heeft.

Wie LibreSSL niet leuk vindt kan ook nog kiezen voor Amazon's s2n herimplementatie of Google's fork Tink (voorheen BoringSSL). Dat ook die mensen meerwaarde zien in eigen code in plaats van OpenSSL blijven gebruiken zegt ook wel iets.

Dit!

Wij hebben de monitoring op certificaten best op orde maar zijn toch ook getroffen: iOS devices hadden geen zin meer in onze exchange servers terwijl andere OSen nergens last van hadden.

Ik zag het woensdag om 21:21 al in Zabbix vanwege website monitoring. Ineens 20 websites rood. Blijkbaar zijn er 2 (intermediate en root) certificaten die zijn verlopen kort na elkaar.

Fortigate heeft zn firewalls een dag later nog steeds niet op orde .

Duurt aardig lang inderdaad...
Het advies was ook vrij bijzonder: schakel de SSL inspectie maar even helemaal uit...

Gister was er wel een nieuwe cert update beschikbaar op de fortinet. Maar dit heeft niet geholpen helaas

Grappig, bij ons waren het de Android devices die met onze Xamarin app de mist in gingen. iOS leek geen probleem te hebben.

Nog niet te spreken over thinclients met oudere firmware...

1.1? is 3.0 al niet de laatste stable?

3.0 is net uit en niet backwards comatible. Gaat nog 5 jaar duren voor dat breed ondersteund wordt.

Ik heb hier ook pfsense draaien inc. acme en de afgelopen maanden melde pfsense midels alerts dat het intermediate cert ging verlopen. Ik heb dit intermediate cert zelf vervangen en bij de afgelopen verversingsronde ging alles zoals gewoonlijk.

Als het verlopen van een intermediate cert zoveel impact kan hebben ga je daar toch niet op wachten, afwachten of het goed gaat en vervolgens gaan klagen ...

Bij Certbot wordt die intermediate gewoon automatisch vervangen, bij de acme client niet. Als je daar niet op bedacht bent let je daar niet op.

Bij ons waren het vooral de firewalls die er over struikelden, waardoor sites zoals 365 zelfs niet meer normaal te gebruiken waren. Voor dat je dan in de gaten hebt dat het met iets op het oog ongerelateerds te maken heeft ben je een paar uur verder.

Je zag dat veel partijen met spoed een ca-certificates update uitgerold hebben om het verlopen root certificate uit de store te halen. Bijvoorbeeld bij Amazon Linux kwam de update pas 's avonds om 8.25PM UTC. Daarmee was het probleem ook opgelost.

Het vervelende was vooral die OpenSSL optie, want in de meeste gevallen werd er gewoon netjes een valide chain geserveerd, maar ging de client onderuit omdat hij alsnog tegen het oude root certificate ging valideren.

Opensense idem ditto. Ik moest de CA verwijderen en de certs opnieuw laten genereren. Acme client refreshed kennelijk niet automatisch de Intermediate Certs. Toch is het mijn eigen schuld ik had hier eerder aandacht aan moeten besteden maar was het gewoonweg vergeten.

Op mijn werk monitor ik de certificaten en die had ik gelukkig al een paar weken geleden vervangen.

Voor je dit de problemen noemt verwacht ik toch ook wel onderbouwing van de bedoeling om oude software en hardware te gebruiken waar je kennelijk niet op kan vertrouwen door bestaand gebrek aan ontwikkeling en onderhoud.
Dat lets encrypt mogelijkheid tot gebruik van oude oplossingen geeft wil nog niet zeggen dat je als bedrijven er goed aan doet dat gebruik voort te zetten. Het probleem lijkt dus meer dat bedrijven en consumenten software en hardware blijven gebruiken die nier betrouwbaar genoeg blijken.

Ah dank voor je uitleg. We gebruiken de laatste versie van Certify, maar pas bij het verwijderen van alle certificaten ging het pas goed bij vernieuwing.
Gelukkig had Certify afgelopen zondag al een e-mail gestuurd. Onder het motto: niet dat er problemen verwacht worden, maar toch dat je het weet. Ik was dus gewaarschuwd.
Wel bijzonder vond ik dat het oude certificaat alleen op mobieltje problemen gaf en de websites op Edge/Chrome het gewoon bleven doen. Daardoor vraag ik me wel af hoe goed deze browsers de chain van certificaten controleren.

Ene grote bedrijf is het andere niet. Denk vaak een kwestie van hun eigen systemen niet goed kennen.

Welke van die argumenten zijn redelijk als het de bedoeling is dat die certificaten moeten zorgen dat je zaken kan doen?

Ja makkelijk praten. Wij hebben Letse crypt met iis en de officiele boodschap was altijd, niets veranderd, je hoeft niks te doen.

Toch ging het stuk omdat de cliënt out of date was. En de patch voor win acme kwam pas een week geleden uit.

Sinds wanneer is het makkelijk praten dat je als bedrijf eigen verantwoordelijkheid blijft hebben als je gebruik gaat maken van een gratis dienst? Wel het voordeel van de kosten en een mooi verhaal willen maar niet willen rekening houden met de mogelijke nadelen klinkt eerder te makkelijk. Als die certificaten zo belangrijk voor je bedrijf zijn dan zorg je er toch voor dat je vooraf duidelijke afspraken maakt en dat als die afspraken er niet zijn je op tijd terug kan vallen op iets wat je wel kan accepteren? Of helemaal geen diensten af neemt als je te weinig zekerheid hebt?

zit wat in. uiteindelijk is letsencrypt gratis. dus tja... waarom zou letsencrypt zich verantwoordelijk voelen? ze verdienen er geen cent aan. laat iedereen het maar lekker zelf uitzoeken. ik snap die houding dan wel.

Ging ik ook net zeggen. Eigenlijk was het Let's Encrypt root certificaat (dat ge cross-signed was met de DST Root certificaat van IdenTrust) al eens expired. IdenTrust en Let's Encrypt hadden dan overeengekomen om een nieuw certificaat te cross-signen (dit was het R3 certificaat). Hiervan was geweten dat het maar tot eind september geldig ging zijn. Dan moeten server admins dit toch al lang genoteerd hebben.

Let's Encrypt had afgelopen 2 jaar extra moeite gedaan om ervoor te zorgen dat het ISRG root certificaat door alle clients vertrouwd wordt. Zelfs Apple vertrouwt Let's Encrypt nu rechtstreeks. Het enige waar nog problemen zijn is bij android. Want bij android wordt de certificate store namelijk geïmplementeerd door Google.

Google releast nieuwe versies van android, hierin zit de nieuwe certificate store. Smartphone fabrikanten forken deze en modden deze dan (vb. Samsung: One UI 2). Deze versie wordt dan getest op de apparaten (bijvoorbeeld de S8). Als Samsung dan beslist dat deze nieuwe android versie niet kan draaien, zullen deze gebruikers nooit de nieuwe android krijgen. Dit is iets waar ondertussen al 3 jaar hevig over gedebatteerd wordt.

Het ISRG root certificaat wordt pas vertrouwd door Android 7.1. En dus iedereen met android versie 7.0 of lager zal dus problemen ondervinden. Maar even serieus, wie gebruikt nu nog een android versie ouder dan 7.1? Hmmmm 🤔

Bij ons werd alles vernieuwd met de R3 ipv X1. Alles geforceerd refreshen was de oplossing.
Onbegrijpelijk hoe dat X1 niet al maanden de preferred optie was.

R3 is gewoon de intermediate, X1 is de root. R3 als root bestaat niet.

Er waren volgens mij wel meer problemen dan alleen een verlopen certificaatje, want ondanks dat de mijne uiteindelijk signed zijn door X1 kregen sommige mensen een OCSP stapling error op sommige sites. Ik heb letterlijk niks veranderd op de server en toch doen die sites het nu weer.

Let's Encrypt gebruikt ook nog een R3 als intermediate.
Die is geldig tot 2025. Weet je zeker dat je een verlopen cert kreeg?

Onbegrijpelijk hoe dat X1 niet al maanden de preferred optie was.

Dit was al sinds 11 januari 2021 het geval en had al veel eerder het geval moeten zijn maar Let's Encrypt vond de beschikbaarheid van hun nieuwe root certificaat op vooral oude Android toestellen niet hoog genoeg.

Bron: https://scotthelme.co.uk/lets-encrypt-old-root-expiration/

De reden hiervoor was omdat ze nog niet wisten hoe ze met android 7.0 of ouder gingen omgaan. Deze arme stakkers zitten nog steeds met een certificate store (van VOOR oktober 2016) waar de ISRG Root CA X1 nog niet in zit, en dus fouten zouden krijgen op 1/6 van alle websites...

Vreemd, zou verwachten dat zoiets wel goed gaat als de certbot elke maand ofzo renewed, wat juist bij letsencrypt geautomatiseerd is en best practice is?

[Reactie gewijzigd door - peter - op 1 oktober 2021 21:36]

Ik heb hier last van gehad met DNS-over-TLS in Android 11. Ik heb het opgelost door gewoon de verlopen intermediate weg te gooien, ondanks dat de auto renew gewoon werkt. Dat is met de officiële client. Ik denk dat er toch iets meer speelde.

Dat is natuurlijk persoonlijke infra, voor belangrijke (zakelijke) dingen verwacht ik dat men hun zaken beter op orde heeft en hier drie maanden geleden al naar heeft gekeken.

Hoi, hoe heb je dat gedaan? Ik heb er zelf last van met homeassistant en duckdns

Heel erg lelijk

De goede oplossing is waarschijnlijk degene die bovenaan de comments gegeven is door @xFeverr:
certbot renew --force-renewal --preferred-chain "ISRG Root X1"

Mijn "oplossing" is om naar /etc/letsencrypt/live/<domeinnaam>/ te gaan en fullchain.pem en chain.pem aan te passen. Het onderste certificaat in de chain gaf bij mij het probleem, dus die heb ik weggehaald en nginx herladen. Misschien gaat dit bij de volgende renew kapot (als fullchain vervangen wordt...) maar voor nu werkt het...

Edit: zojuist zelf het force-renewal-commando gedraaid, de oude chain is inderdaad helemaal vervangen nu en het probleem is écht opgelost.

[Reactie gewijzigd door GertMenkel op 1 oktober 2021 22:38]

Nou, in mijn geval werkt het nog niet. Zojuist reinstall om nieuwe pem keys te krijgen.

Duckdns addon van HA gebruikt, welke niet certbot maar dehydrated gebruikt. Ik zoek idd een meer robuuste workaround

Ik weet niet op welke apparaten je problemen hebt, maar misschien moet het gezegd worden dat als je apparaten een ouder OS draaien (Android 7, bijvoorbeeld), het ook niet gaat werken. Daarop moet je de Let's Encrypt certificaatautoriteit inladen in je certificaatopslag, indien je apparaat daarvoor de mogelijkheid geeft.

Op Android moet je voor systeemfunctionaliteit (dus alle apps die niet expliciet je gebruikerscertificaten vertrouwen vanaf Android 7) ook nog eens het cerificaat naar de systeemcertificaatopslag laden, iets waar je keihard root-toegang voor nodig hebt. Het kan gelukkig wel met een Magisk-module maar dat kan voor veel oude telefoons nog wel eens heel problematisch zijn.

Ik heb een s10, dus modern android (gebruik de private dns functie als dns adblocker).

Heb wel geprobeerd certificaten in te laden in m'n store, maar weet niet hoe dit werkt in android/samsung. Misschien ook ff reboot doen..

Nope, ik heb allerlei ca certs geprobeerd. Welke zou ik moeten hebben?

[Reactie gewijzigd door sjongenelen op 2 oktober 2021 13:09]

Het kan ook aan de andere kant liggen. Certificaten die gesigned zijn met het nieuwe letsencrypt root certificate worden als geldig gezien als de client gebruik maakt van de OpenSSL library versie 1.1.0 (of nieuwer).
Bij ons draaide er nog een applicatie die geschreven was in NodeJS 6 (wat gebruik maakt van OpenSSL 1.0.2), en plots kon die niet meer verbinden met een API

Bij ons draaide een webserver die zelf 1 request naar buiten moest maken voor de login. Draaide op een oude nodejs, die alleen het oude cert kende (en niet die van het os gebruikt blijkbaar), waardoor de call niet kon worden gevalideerd.

Hadden we niet aan zien komen want verder staat het achter reverse proxy met nieuwe certificaten, en het OS was up to date. Certbot komt daar dus niet in de buurt in dit geval.

Kan dit ook de oorzaak zijn dat de openVPN naar mijn NAS (Synology) plotseling niet meer werkt?

Kan dit ook de oorzaak zijn dat de openVPN naar mijn NAS (Synology) plotseling niet meer werkt?

Heb je hem geupdate?
En de client ook?
Op mijn Syno werkt het nog.

Dat kan kloppen als je hem pas recent hebt ingesteld
Synology zag dit aankomen en had dus al een update voor de VPN Server met nieuwe certificaten
Dus als je de VPN ingesteld hebt na die update werkt het gewoon nog
Maar die update is nog niet zo heel lang beschikbaar, en alles van voor die update werkt dus niet meer en moet opnieuw geconfigureerd worden

Thanks voor je reactie. Heb het package op mijn local NAS geüpdatet, maar twijfel nu of ik hem op mijn remote NAS heb gedaan.

Gekke is dat mijn Android telefoons ook niet meer kunnen connecten.

Klopt, als je die voor de update hebt ingesteld gebruiken die ook nog het oude certificaat
Dus ook daar moet je die nieuwe configuratie importeren
Dan werkt het weer

Klopt, als je die voor de update hebt ingesteld gebruiken die ook nog het oude certificaat
Dus ook daar moet je die nieuwe configuratie importeren
Dan werkt het weer

Nee hoor.
Hij draait hier al 1,5 jaar, zonder problemen.

Wat te doen vanmiddag

Thanks

Zie de post van @Stijnvi hierboven

Ik had hier al over gepost, maar ja, dat is de oorzaak
Het is op te lossen door in Package Center, VPN Server te updaten, vervolgens de OpenVPN configuratie weer te exporteren, die aan te passen met je eigen IP, zoals bij de oude config, en vervolgens die weer te importeren in je OpenVPN client

Ook cPanel had het verkloot door een fout in de chain door verouderde root/intermediate. Dat was gelukkig op te lossen zonder alles te re-signen, maar wel heel erg slordig van zo’n toko met hun verantwoordelijkheden. Soms vraag je je af of ze t express doen om cPanel CA (Comodo) te pushen, hehe. Afijn.

Hier lukte het resignen niet(rate limit en bleven de oude terug krijgen) , dus zijn we idd heel snel overgeschakeld naar cPanel CA...

Over een week maar eens kijken of we weer terug kunnen.

Was ook false positive, re-signen was helemaal niet nodig. Enkel commando “ /scripts/autorepair update_lets_encrypt_cabundles” en je certificaten werden weer herkend.

De (SSL) verbinding van mijn usenet provider stopte er mee. Tijdelijke oplossing was om SSL uit te schakelen.
Het is inderdaad bedroevend, dat dit soort dingen gebeuren bij bedrijven van deze importantie Ik maak het op mijn werk ook mee, je legt hele businesses plat. Ik kan het inderdaad niet anders dan als laksheid zien.

Het is juist het "probleem" dat Let's Encrypt vaak automatisch wordt vernieuwd en men (ook grote bedrijven) hier dus niet meer naar omkijkt.
Al geeft Let's Encrypt nu wel de nieuwe root certificates mee, dan is het daarnaast ook nog aan de client om dat nieuwe root-certificate te ondersteunen (clients als Windows, Linux, android, browser, OpenSSL, etc.). Dus het zou ook een probleem van je usenet-applicatie kunnen zijn die al jaren niet meer is bijgewerkt, of niet van nieuwe OpenSSL is voorzien of iets in die richting. (of je moet zelf een update installeren die het fixt )

[Reactie gewijzigd door Olifant1990 op 1 oktober 2021 21:58]