DigiCert trekt meer dan 80.000 certificaten in na DNS-validatiefout

Certificaatuitgever DigiCert moet meer dan 80.000 certificaten intrekken vanwege een fout in de manier waarop domeinnamen worden gevalideerd. Het bedrijf zegt dat het daarom verplicht is binnen een dag een aantal certificaten in te trekken.

DigiCert zegt dat het een flink aantal certificaten van gebruikers noodgedwongen intrekt. Het bedrijf noemt geen cijfers, maar zegt dat het om 0,84 procent van alle domeincertificaten gaat die het heeft uitgegeven. Volgens een BugZilla-rapportage gaat het om 83.267 certificaten, verdeeld over 6807 klanten. Het gaat om certificaten die tussen augustus 2019 en juni 2024 zijn uitgegeven. Het grootste deel van de certificaten is inmiddels ingetrokken.

De reden voor het intrekken is de manier waarop DigiCert aan Domain Control Verification doet. Dat doet DigiCert om te controleren of een domeinnaam bij een klant hoort. Dat gebeurt met een DNS-look-up van een Cname-record. DigiCert voegt een willekeurige random value toe aan zo'n Cname-record.

Om te voorkomen dat een random value precies dezelfde waarde kan krijgen als de domeinnaam, zegt standaardisatie-uitgever Certification Authority Browser Forum dat certificaatuitgevers een underscore aan de random value moeten toevoegen. DigiCert zegt nu dat het heeft ontdekt dat in sommige Cname-records geen underscore werd toegevoegd. Het bedrijf zegt dat de kans minimaal is dat er daardoor een botsing tussen waardes en domeinnamen ontstond, maar 'volgens de strenge CABF-regels moeten certificaten met een probleem in de domeinvalidatie binnen 24 uur worden ingetrokken, zonder uitzondering'. Het bedrijf zegt dan ook niet of het concrete problemen heeft opgemerkt, maar dat het om een standaardmaatregel gaat.

Klanten moeten zelf via hun DigiCert-account een nieuw certificaat aanvragen. Dat kan ook via tools als de Trust Lifecycle Manager. DigiCert zegt dat het het probleem op het spoor kwam nadat een gebruiker vragen stelde over het proces. Het bedrijf begon daarna een eigen onderzoek.

Reacties (66)

[laurxp]

Het bedrijf zegt dat de kans minimaal is dat er daardoor een botsing tussen waardes en domeinnamen ontstond

Dit is trouwens niet waar. Er zijn weldegelijk serieuze veiligheidsrisico's!

Het probleem is dat er partijen zijn die de gebruiker een subdomein laten kiezen. Zo was (is?) er bijvoorbeeld DynDNS, waar je een zelfgekozen "gekkehenkie.dyndns.com" naar jouw eigen dynamische thuis-IP laat verwijzen. Er is geen enkele regel die dit verbied, en op papier is ook niks mis met een dienst die iets vergelijkbaars implementeert met CNAME records. En ja, er zijn dus daadwerkelijk providers die dit aanbieden.

Het probleem is dat dit door de bug van DigiCert ineens een serieus veiligheidsrisico is. Om aan te tonen dat jij de eigenaar bent van "mijndns.com" vraagt DigiCert je om een CNAME record aan te maken van "fesfawdx3eq2d.mijndns.com" dat wijst naar "dcv.digicert.com". Iedere gebruiker zou dit triviaal kunnen doen, en daarmee een aanval kunnen uitvoeren op "mijndns.com" en zelfs "*.mijndns.com"!

De reden dat de underscore cruciaal is, is dat een underscore geen geldig karakter is in een domeinnaam - maar wél gebruikt kan worden in een CNAME record. "_fesfawdx3eq2d.dyndns.com" is nóóit een geldige domeinnaam, dus geen enkele dienst zal de registratie daarvan toestaan. Hierdoor is de underscore-variant veilig te gebruiken voor de domein-validatie van DigiCert.

[Reactie gewijzigd door laurxp op 1 augustus 2024 12:05]

[MDKlapwijk]

Het is wel degelijk een correcte domeinnaam, ICS BIND e.d. vinden het helemaal prima:

klapwijk@kc-sys-01:~$ dig _x9e9im80f5tyf1k75f70qlbzw4t75cc.provider.tld

; <<>> DiG 9.16.42-Debian <<>> _x9e9im80f5tyf1k75f70qlbzw4t75cc.provider.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22798
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_x9e9im80f5tyf1k75f70qlbzw4t75cc.provider.tld. IN A

;; ANSWER SECTION:
_x9e9im80f5tyf1k75f70qlbzw4t75cc.provider.tld. 180 IN CNAME dcv.digicert.com.
dcv.digicert.com. 1800 IN CNAME dcv.dcvcheck.com.

;; AUTHORITY SECTION:
dcvcheck.com. 180 IN SOA ns10.digicertdns.com. dns.digicertdns.com. 2009010127 43200 3600 1209600 180

;; Query time: 36 msec
;; SERVER: 192.168.0.254#53(192.168.0.254)
;; WHEN: Thu Aug 01 17:21:06 CEST 2024
;; MSG SIZE rcvd: 189

het zijn de browsers/clients die het niet accepteren:

klapwijk@kc-sys-01:~$ curl -v https://_x9e9im80f5tyf1k75f70qlbzw4t75cc.provider.tld
* Could not resolve host: _x9e9im80f5tyf1k75f70qlbzw4t75cc.provider.tld
* Closing connection 0
curl: (6) Could not resolve host: _x9e9im80f5tyf1k75f70qlbzw4t75cc.provider.tld

De could not resolve werd veroorzaakt doordat "dcv.dcvcheck.com" geen A-record heeft. Als ik "digicert.com" voor de cname gebruikt krijgt curl netjes een 301 etc.:

klapwijk@kc-sys-01:~$ curl -v http://_test.provider.tld
* Trying 45.60.131.229:80...
* Connected to _test.provider.tld (45.60.131.229) port 80 (#0)
> GET / HTTP/1.1
> Host: _test.provider.tld
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Location: https://_test.provider.tld/
< Content-Length: 0
< Connection: close
<
* Closing connection 0

[Reactie gewijzigd door MDKlapwijk op 1 augustus 2024 17:45]

[Argantonis]

Een domeinnaam mocht echter best een underscore bevatten. Een HOSTname daarentegen niet.

Pas vrij recent dat ‘t niet meer toegestaan is:

https://stackoverflow.com...e-in-it/54670381#54670381

[Reactie gewijzigd door Argantonis op 2 augustus 2024 10:47]

[Drumar]

Nee, het is sinds kort wat explicieter niet meer toegestaan in _certificaten_. RFC1034 is ouder en hanteert de regels van ARPANET. Dat is echt veel ouder. Domein namen mogen geen underscores bevatten, wat op zich wel apart is. Geen idee waarom die buiten de expressie zijn gehouden

[MDKlapwijk]

Uitstel is vanwege een "restraining order": https://www.courtlistener...hnologies-llc-v-digicert/

En het waarom dat het een serieus issue zou kunnen zijn, is bijv. in de volgende situatie:
- provider/hoster geeft subdomeinen via cname gebaseerd op usernaam uit: usernaam.provider.tld.
- gebruiker vraagt wildcard certificaat aan bij digicert, krijgt de <random> cname zonder '_'.
- gebruiker meldt zich aan bij provider.tld onder de usernaam <random>
- digicert valideert een wc voor het rootdomein van de provider.tld.
- all hell brakes loose...

note: dit alles valt/hangt samen met CA/BROWSER FORUM - Ballot SC12: https://cabforum.org/2018...-underscores-in-dnsnames/

[FrostyPeet]

Blijf dit certificaat systeem vreemd vinden. Je wil single point of failures voorkomen in de IT als zichzelf respecterend bedrijf.

Een CA hangt in de lucht een ankerpunt, probeert daarna alle browser- en os-makers te overtuigen dat ze betrouwbaar zijn. Verkoopt dan bewijs van betrouwbaarheid aan klanten. Gaat er iets fout, valt de boel in elkaar als een kaartenhuis en moeten er bewijsjes worden ingetrokken of worden vervallen. Wat dan ook weer geregistreerd moet worden. Ik begrijp nu wel waarom een setje certificaten voor domein en e-mail adressen zo duur is. Dan mag je het ook nog elke paar jaar opnieuw kopen.

[Blokker_1999]

Basis certificaten kan je tegenwoordig gratis krijgen, net omdat alles volledig geautomatiseerd kan verlopen. En tot de dag dat men iets beter weet te vinden, zal dit systeem noodzakelijk blijven.

[GertMenkel]

Nou ja, de boel stort niet per se in elkaar. Het systeem is tegenwoordig zo ontworpen dat intrekken en opnieuw uitgeven zonder problemen moet kunnen. Via ACME en diverse andere protocollen heb je met een uur duizenden servers van nieuwe certificaten voorzien.

Als je nog de "ouderwetse" manier van certificaatmanagement gebruikt, waar iemand allemaal bestandjes moet downloaden en uploaden, dan ben je hier wel even mee bezig, maar dat zou niet moeten hoeven als je je systeem goed inricht.

Iedere vertrouwensketen moet marge hebben voor fouten, menselijk of automatisch. Dit intreksysteem is bewijs dat het vertrouwensstelsel werkt zoals het hoort: er is een probleem vastgesteld, het vertrouwen van bepaalde certificaten is niet meer gegarandeerd, en het vertrouwen wordt hierop direct ingetrokken.

De prijs van die certificaten heeft met twee dingen te maken: de kosten om menselijk te valideren (een mens het bedrijf laten opbellen en dergelijke) en de winstmarge van deze bedrijven. Ik betwijfel dat dat eerste significant is voor het bepalen van de prijs van die dingen, hier wordt goed geld op verdiend.

Om die reden zijn tegenwoordig de meeste websites ook beschermd met gratis certificaten. De hele spullenboel gaat allemaal geautomatiseerd, daar komt geen mens voor aan te pas. Voor e-mailcertificaten (S/MIME) en code-ondertekeningscertificaten is geen gratis variant, daar moet op dit moment altijd menselijk werk aan te pas komen.

Er zijn alternatieven voorgesteld (DANE bijvoorbeeld) waar via DNS een vertrouwensketen wordt opgebouwd, maar daar is je vertrouwensketen afhankelijk van de DNS-root, wat ook gewoon bedrijven en organisaties zijn. Dat, gecombineerd met de protocoleigenaardigheden van veilige DNS (DNSSEC is niet in te stellen bij veel Amerikaanse partijen) heeft ervoor gezorgd dat DANE effectief dood is. We zullen eerst DNS goed moeten kunnen beveiligen eer we dat soort systemen kunnen automatiseren.

De overheid heeft met de tweede iteratie op eIDAS naar ontwerp van de certificaatbedrijvenlobby nog weer een ander certificaatsysteem opgezet (QWAC's) om te zorgen dat dit soort dingen geen overheidsdiensten kunnen verstoren. Goed voor de uptime van de overheid, niet zo goed vanwege het feit dat dingen die niet te vertrouwen zijn alsnog als vertrouwd zouden moeten worden gemarkeerd (en dat softwaremakers niet kunnen kiezen wie ze zouden moeten vertrouwen volgens de originele specificatie).

[netmeester]

Als Apple zich netjes aan alle regels zou houden, zou je helemaal gelijk hebben. Maar Apple heeft een probleem met ACME-certificaten (iig LetsEncrypt) in combinatie met Apple Pay - je zult dan 4x per jaar handmatig een actie moeten doen terwijl je certificaat wel gewoon automatisch vernieuwd wordt. Met een betaald certificaat heb je dit gezeik met Apple niet...

Dus helaas, het is niet zo zwart-wit als "moderne" en "ouderwetsche" manier zolang je Apple moet ondersteunen.
https://developer.apple.com/forums/thread/663425

[GertMenkel]

Let's Encrypt doet domeinvalidatie met een korte geldigheidsduur (van max 90 dagen) om de impact van gelekte certificaten te minimaliseren. Natuurlijk geeft Apple geen uitleg over hun bug, maar als ze inderdaad vlak voor het verlopen van het certificaat moeilijk gaan doen, zul je certificaten van een langere termijn moeten gebruiken, of eerder een vernieuwing afdwingen.

ACME is slechts een protocol voor het geautomatiseerd aanvragen en vernieuwen van certificaten. Dat kan gratis zijn, maar kan ook achter een betaald account zitten. ACME kan ook gewoon certificaten uitgeven die twee jaar geldig zijn (al is dat niet echt de bedoeling van het systeem).

Het betaalde Digicert, waar dit nieuwsbericht over gaat, ondersteunt bijvoorbeeld ook ACME. Standaard vernieuwen ze 32 dagen voor verlopen of 90 dagen voor verlopen, afhankelijk van hoe lang je vooruit betaalt voor je certificaat en hoe lang je certificaat geldig moet zijn.

Apple's probleem lijkt te zijn dat ze twee maanden of langer voor het vernieuwen van het certificaat een check doen. Heeft niks met certificaatlogica te maken natuurlijk, dat is hun eigen stomme systeem dat rare logica gebruikt. Let's Encrypt vernieuwt standaard automatisch elke twee maanden (om je een maand te geven om automatiseringsproblemen op te lossen zodra ze optreden), maar als je je server instelt om dat elke maand te doen, zou je geen probleem met Apple moeten hebben. Dat probleem zul je ook bij Digicert of wat voor certificaatboer dan ook hebben als ze standaard minder dan 60 dagen voor verlopen geautomatiseerd het certificaat vervangen.

[Reactie gewijzigd door GertMenkel op 1 augustus 2024 15:31]

[netmeester]

Volgens Apple: "Apple servers check if SSL certificates have been renewed at 30, 15, and 7 days before expiration." Bij Xolphin gaat het WEL goed als ik vóór die laatste check de nieuwe certificaten heb geplaatst, bij Let's Encrypt niet.

Dat gezegd hebbende: je voorstel om elke maand te verlengen zal ik zeker eens testen, je weet nooit.

[Reactie gewijzigd door netmeester op 8 augustus 2024 10:52]

[musiman]

Een klein dingetje eigenlijk, een underscore vergeten. Maar wel één met gevolgen voor veel klanten. De titel van dit artikel doet vermoeden dat er iets ernstigs aan de hand is qua security; wellicht de titel iets aanpassen naar iets minder dramatisch?

[Kees]

Het is juist erger dan de titel doet vermoeden. Dit zijn 80k certificaten die in eerste instantie binnen 24 uur vervangen moesten worden. Dat betekend dat in het ergste geval 80.000 6807 unieke klanten allemaal een nieuw certificaat moeten aanvragen en dus 80.000 6807 mensen ongeplanned aan het werk moeten, of dat nu uitkomt of niet. Overigens zouden ze al ingetrokken moeten zijn, want die 24h limiet ging 2 dagen geleden in.

Gelukkig hebben ze toestemming gekregen om die termijn een klein beetje te verlengen (voor specifieke klanten?), maar vanaf komende zaterdag zijn al die 80k certificaten ineens ongeledig.

Je zal maar een weekje op vakantie zijn en je mail niet lezen in de veronderstelling dat je certificaat nog maanden geldig is.

Overigens is dit niet de enige manier waarop ze domain control verification doen waardoor de impact een stuk minder groot is en niet alle certificaten vervangen hoeven worden.

[Reactie gewijzigd door Kees op 1 augustus 2024 08:57]

[laurxp]

Je zal maar een weekje op vakantie zijn en je mail niet lezen in de veronderstelling dat je certificaat nog maanden geldig is.

Deze vervangingstermijn staat gewoon in je contract met DigiCert: letterlijk iedere certificate provider heeft dat, want het is een voorwaarde om überhaupt in de Certificate Store van browsers te komen. Je zal er dus altijd rekening mee moeten houden dat dit zonder waarschuwing kan gebeuren.

Als serverbeheerder heb je drie opties:

• Zorg er voor dat er meer dan één beheerder is. Voor alles dat niet hobbymatig is, is dit een no-brainer.
• Automatiseer de vervanging van certificaten. Dit kan gratis en voor niets met bijvoorbeeld LetsEncrypt.
• Accepteer dat je dienst onverwacht offline kan gaan. Blijkbaar is je dienst niet belangrijk genoeg om er ook maar enige tijd of geld in te steken.

[Reactie gewijzigd door laurxp op 1 augustus 2024 11:58]

[Kees]

Alleen het eerste punt helpt in dit geval.

De gemiddelde Lets Encrypt renewal bot kijkt gewoon naar hoe lang je certificaat nog geldig is en renewed hem dan wel of niet. Die doen geen check op 'wellicht word die certificaat binnenkort ingetrokken', daar is ook geen lijst voor.

[laurxp]

Certbot kijkt al enkele jaren of het huidige certificaat gerevoked is, in ieder geval. Dit beperkt de downtime ná revocation tot gemiddeld 6 uur, aangezien certbot normaal gesproken ieder 12 uur draait.

Voor aankomende revocations is er ACME Renewal Information. Dit is een goedkope API-call die aangeeft wanneer het certificaat vervangen moet worden. Bij een incident zal dit teruggeven dat je certicaat nu vervangen moet worden, en omdat je de bot iedere 12 uur draait heb je dus binnen de 24-uursperiode een nieuw certificaat. Nul downtime, dus.

[Mattashii]

[...] en omdat je de bot iedere 12 uur draait heb je dus binnen de 24-uursperiode een nieuw certificaat. Nul downtime, dus.

Dat is enkel als de CA (ruim) op tijd registreerd dat het certificaat vervangen moet worden. De klok van het intrekken van een certificaat begint namelijk te tikken op het moment dat de CA is ingelicht over een fout in het certificaat (via een ingediend Certificate Problem Report - het moment van indienen geld hier als start, niet het eerste keer lezen-), ofwel vanaf het moment dat het bij de CA duidelijk is dat er een proleem is met een certificaat/groep van certificaten.

Let wel: Het uitvogelen welke certificaten ingetrokken/vervangen moeten worden is hier dus niet relevant voor de klok. Als de CA ontdekt dat de manier waarop domeinen gevalideerd worden niet correct is in sommige gevallen, dan moeten al die certificaten die volgens die manier gevalideerd zijn ingetrokken worden binnen 24 uur vanaf die realisatie, niet pas vanaf het moment dat ieder certificaat gevonden was via een database-query. Dat zou de CA namelijk in staat stellen om in zijn geheel geen onderzoek te doen naar welke certificaten een foutieve verificatie hebben, en dus de certificaten nooit hoeven in te trekken.

Om dus een ACME-RI integratie die elke 12 uur draait te ondersteunen zonder downtime, moet een CA dus in de eerste 12 uur van het probleem de status van deze certificaten updaten (of 108 uur, in gevallen waar de validatie en directe veiligheid van het certificaat minder relevant is, maar zie de BR voor de preciezere regels). Als dit bijvoorbeeld pas na 18 uur gebeurd, heb je dus een flinke mogelijkheid dat je ACME-RI runner in het 18e uur draaide, en je dus tot 6 uur downtime hebt vanwege een ingetrokken certificaat.

[laurxp]

Klopt, maar dat probleem zal je altijd houden. Voor hetzelfde geld heb je een incompetente CA die zijn klanten pas informeert nadat de 24 uur zijn verstreken en alle certificaten ingetrokken zijn, daar kan je als beheerder vrij weinig aan doen. Zelfs met een systeembeheerder die 24/7 naar d'r email zit te staren heb je dan downtime.

12 uur is in de meeste gevallen méér dan genoeg tijd om er achter te komen welke certificaten ongeldig zijn. Vaak is het gewoon een kwestie van een regex testen op de certificaten-database. Als een CA dit niet voor elkaar krijgt, hebben ze wel grotere problemen dan een enkele revocation.

[Gazuhl]

Ehh voor aankomende revocations? Nog nooit gehoord dat er een pre-revocation lijst gepubliceerd wordt. ARI heeft niks te maken met certificaten die teruggetrokken worden. Alleen met die certificaten die het einde van hun leeftijd naderen.

In dit geval had het ook niets uitgemaakt. Het probleem was niet met de certificaten zelf. Daar was in principe niets mis mee. Het probleem zat em in het feit dat domain validation niet goed afgehandeld is en deze certificaten dus nooit uitgegeven hadden mogen worden. Daar kan geen automated renewal tegenop, je moet eerst het domain validation proces correct doorlopen voor er een nieuw certificaat kan worden uitgegeven. Dus ook lets encrypt had hier de nist in kunnen gaan en exact dezelfde problemen kunnen veroorzaken voor afnemers.

[laurxp]

ARI heeft niks te maken met certificaten die teruggetrokken worden

Juist wel. Zie bijvoorbeeld deze blogpost, die expliciet zegt "ARI makes it possible for our subscribers to handle certificate revocation and renewal as easily and automatically as the process of getting a certificate in the first place."

Het probleem was niet met de certificaten zelf.

Onjuist. De certificaten waren niet goed gevalideerd en zijn dus per definitie ongeldig omdat niet kan worden uitgesloten dat de validatie een false positive was.

je moet eerst het domain validation proces correct doorlopen voor er een nieuw certificaat kan worden uitgegeven

Met ACME kan dat dus volledig automatisch - zoals de meeste gebruikers van Let's Encrypt doen. Je hebt alleen maar een DNS-provider nodig die een API bied om je certificaat-bot een validatie-entry te laten maken. De grote partijen ondersteunen dat al jaren.

[nzall]

In het artikel staat dat het gaat over 6807 unieke klanten, dus het zijn geen 80,000 klanten die ineens "ongepland aan het werk moeten".

[Kees]

Ah even gemist; aangepast. Het blijven 6807 mensen die in een vakantieperiode onverwacht aan het werk moeten, dus dat zal niet iedereen lukken.

[Reactie gewijzigd door Kees op 1 augustus 2024 08:58]

[x86dev]

Normaal draag je ook werkzaamheden over voor een vakantie. Mocht je tegelijk vakantie hebben dan zou ik de interne communicatie met je co-beheerders verbeteren en mocht je als enige beheerder zijn bij het bedrijf, risico van het vak.

[Kees]

Uiteraard. Maar dit nieuws kam zondagavond naar buiten, dus maandagavond zouden ze al ingetrokken moeten zijn volgens de regels.

Nu zou het maar net zo zijn dat je twee beheerders hebt waarvan er een net twee weken op vakantie is geweest en dat maandag zijn eerste werkdag is en de ander is vanaf maandag vrij. Dan moet je maar hopen dat die ene die net terug komt op tijd die mail ziet tussen de duizenden andere mails dat hij nu het certificaat moet vervangen. (en dat is geen fictief scenario, gelukkig vielen onze digicert certificaten hier niet onder).

[x86dev]

Monitoring is key.

[Kees]

Je certificaat zal nog gewoon laten zien dat hij over xxx dagen verloopt, dus monitoring daarop zal niet helpen. Het probleem is dat je certificaat op een revoke-list komt, en als hij daar op staat is je monitoring al te laat.

Er is geen 'dit-gaan-we-binnenkort-revoken-lijst' voor zover ik weet. Dus nee, monitoring is niet key in dit geval.

[x86dev]

1e stuk klopt wel ja. Kunnen eindeloos doorgaan maar als je het niet eens bent met hun handelen kan je het beste hun berichten of een andere leverancier zoeken toch?

[Kees]

Ik zeg nergens dat ik het niet eens ben met het handelen van DigiCert. Die volgen gewoon de richtlijnen die ze moeten volgen.

Waar ik het niet mee eens was, en waar ik op reageerde was dat dit niet zo 'dramatisch' was. Mijn reactie daarop is dat dit in heel veel gevallen mis kan gaan en dat de we impact nog niet goed kunnen zien en dat het voor veel bedrijfen best nog verkeerd kan gaan.

[moonlander]

Niet iedereen heeft vakantie! Dit soort werk komt altijd ongelegen als het niet gepland is.

[downtime]

Ik kan je verzekeren dat er vaak meerdere mensen in een bedrijf aan het werk moeten voor zo'n klus. Als 6807 unieke klanten ook 6807 mensen betekent dan neem je dus aan dat het allemaal eenmans IT-afdelingen zijn.

[GreatDictator]

Je zal maar een weekje op vakantie zijn en je mail niet lezen in de veronderstelling dat je certificaat nog maanden geldig is.

Dan heb je je bedrijfsvoering erg slecht ingericht. Certificaten mogen binnen 24u worden ingetrokken, bijvoorbeeld in geval van beveiligingsprobleem. Dit is een harde eis vanuit CA's aan hun klanten (en CA's krijgen dit weer opgelegd vanuit CA/BF). Als je hele IT-afdeling dus lekker een maand op vakantie gaat kun je inderdaad een probleem hebben. Maar is dat de schuld van de CA?

[Mattashii]

Gelukkig hebben ze toestemming gekregen om die termijn een klein beetje te verlengen (voor specifieke klanten?)

Nee, ze hebben geen "toestemming gekregen om die termijn een klein beetje te verlengen". Er is vzviw geen mechanisme waarin toestemming gegeven kan worden om niet te voldoen aan de minimale eisen die gesteld worden aan certificaatuitgevers, de CA/B Forum Baseline Requirements, en dat Digicert die termijn eenszijdig verlengt is dus tegenstrijdig met die minimale eisen (waarvan Digicert overigens ook contractueel met hun klanten is overeengekomen dat zij hieraan zullen voldoen).

[Gazuhl]

Moeten ze nog mee oppassen ook, Google heeft Entrust public CA zo goed als de nek omgedraaid omdat ze de regels aan de laars lapten.

[MSalters]

De toestemming (verplichting zelfs) is door de Amerikaanse rechter gegeven. Een niet-overheidsorganisatie zoals dat forum kan de rechter niet overrulen. En zelfs als dat foum Digicert zou willen schorsen, dan nog zal Google niet tegen een Amerikaanse rechter in durven gaan.

[Mattashii]

Ik vind niet dat de verplichting van de rechter hier "toestemming" genoemd mag worden. "Toestemming" is voor mij een vrije mogelijkheid om iets te doen, niet een verplichting. Bij de Amerikaanse rechter was dit dus een verplichting en waren ze niet vrij om een kortere periode te gebruiken.

Ook was de verplichte periode niet "een klein beetje" verlengt: Wat 24 uur na ontdekking had moeten zijn, werd nu ongeveer 7 dagen en 22 uur (aangenomen dat de intrekdatum van de e-mail van Digicert correct is, en niet verder wordt uitgesteld). Dat is ruim 6x langer dan aangegeven in hun eigen voorwaarden.

[poldecrosmol]

Ons bedrijf had hier last van. Dit was wel op 30 juli, dus dit nieuws is al wat ouder?
Gelukkig was dit maar één specifieke certificaat voor onze website. We hadden wel maar 24 uur de tijd om een nieuwe csr te genereren en door hun verificatie te geraken. Dat laatste duurde meer dan 4 uur(!).

[kodak]

Hebben jullie al navraag bij digicert gedaan waarom de controle 4 uur moest duren terwijl dit geen normale omstandigheid was die ze zelf veroorzaakt hebben? 4 uur is gewoonlijk te overzien. Maar bij dit soort fouten mag je toch wel duidelijk wat meer medewerking van de veroorzaker verwachten. Ze laten klanten ruim 300 euro per jaar betalen voor service die zelfs bij de dienstverlening op basis van vrijwillige donatie beter is. Het jullie probleem maken is hun winst.

[Reactie gewijzigd door kodak op 1 augustus 2024 10:26]

[Tweakersgj]

Het treft alleen gebruikers met een cname validatie record. Gebruikers met een DNS TXT validatie record zijn hierdoor niet geraakt.

[martwoutnl]

Geen mail gehad inzake mijn PKIoverheid Private Server certificaat maar blijkbaar gaat het over andere certificaten.

[evers97]

Voor zover ik me kan herinneren is er bij de aanvraag van een pkioverheidscertificaat niet perse validatie via dns verplicht (CNAME record). Het mag ook met https validatie en emailvalidatie

[martwoutnl]

Ik heb even het mailverkeer toen opgezocht. Ze schreven toen

Voordat wij de aanvraag kunnen goedkeuren, dienen wij het domein te valideren. Dat kan door het toepassen van een DNS TXT Change. Dat houdt in dat er een TXT-record wordt toegevoegd aan het domein, met daarin een random value (GUID

Dit heb ik toen neergelegd bij degene die mijn website beheerd en heeft dat toen na check of dit wel bona fide was dit geregeld.

[GertMenkel]

Zelfs als je certificaat van Digicert kwam, was je hier niet door getroffen als gedaan is wat in de mail staat. Dit probleem gaat namelijk specifiek om CNAME-DNS-verificatie, en de procedure die je beschrijft gaat over TXT records.

[THM0]

Dat is dan ook een andere issuer.

[martwoutnl]

De factuur toen voor het certificaat kwam van DigiCert,

[Ruben279]

PKIoverheid heeft een samenwerking vier commerciele TSP's (Trust Service Provider) toegewezen om de certificaten voor PKIoverheid te mogen uitgeven. Nameijk, QuoVadis (DigiCert), KPN, Digidentity en Cleverbase.

[wildhagen]

Voor de duidelijkheid, het gaat dus enkel over een (klein deel van) certificaat waarvan de verificatie via een CNAME record in de publieke DNS is gedaan? Certificaten waarbij de verificatie via mail of telefonisch plaatsgevonden heeft zijn dus niet geraakt en blijven trusted?

Slordige fout dit, zeker als dit al 5 jaar speelt (sinds 2019). Heeft DigiCert geen audits oid waarin dit soort zaken periodiek bekeken worden?

[ComputerGekkie]

Uit benieuwdheid, hoe verloopt een verificatie via email of telefoon? Hoe kan je dan verifiieren dat iemand een domein heeft, en gemachtigd is om een certificate aan te vragen? Word er dan gebruik gemaakt van de contact details in de WHOIS database?

[Ruben279]

Validatie via telefoon is echt een lachertje (bij Xolphin iig).
Die bellen naar KVK nummer, die vragen naar de persoon die je 5 minuten daarvoor zelf in de aanvraag hebt gezet

"Bent u meneer Jan?"
"Ja"
"Oke, bent u op de hoogte van de certificaataanvraag voor huppedehup?"
"Ja"
"Mooi, dan is hierbij het certificaat uitgegeven"

Enige lastige is dat als je het telefoonnummer dat in de KVK staat als "hoofdnummer" gebruikt en daar ook een keuzemenu op hebt, daar geen validatie op gedaan mag worden.

Aanpassen was ook moeilijk, dus ik haalde dan stiekem even het keuzemenu eruit zodat alle inbound telefoontjes direct bij de servicedesk uit kwamen en dan de 2e lijn erbij kon halen. Tijdswindow is ook maar 60 minuutjes, valt best mee.

Echt een goede validatiemanier vind ik het niet, maar goed...

[vrow]

Nouja, als ze bellen naar het nummer wat bij de KvK staat ingevoerd - dan weet je zeker dat je dat bedrijf aan de lijn krijgt.
Je vraagt dan uiteraard door naar de naam die in de aanvraag staat.
Daarna weet je 99% zeker dat die persoon ook daadwerkelijk bij dat bedrijf werkt en dat het certificaat dus is aangevraagd door dat bedrijf.
Het is toch hetzelfde als je een pakketje ophaalt bij een PostNL-punt? Het nummer van je rijbewijs wordt dan genoteerd. Had je wel of niet toestemming om het pakketje af te halen? Dat wordt niet gecontroleerd, kan ook niet en hoeft ook niet.
Maar in het geval van een dispuut weet je later wel precies wie het heeft opgehaald.

Zo is deze telefonische controle ook.
In deze zelfde opzet is controle via CNAME of e-mail even veilig of onveilig.
Het betreft normale certificaten, geen extended validation. Hoewel dat laatste effectief ook al niet meer echt bestaat (geen groene balk meer in de browser).

Het doel van certificaten is het beveiligen van de verbinding. Het zegt verder totaal niets over wie de houder van een domein is en of een site wel of niet betrouwbaar is.

[deadinspace]

Nouja, als ze bellen naar het nummer wat bij de KvK staat ingevoerd - [...] Daarna weet je 99% zeker dat die persoon ook daadwerkelijk bij dat bedrijf werkt en dat het certificaat dus is aangevraagd door dat bedrijf.

99% zeker klinkt leuk, maar dat betekent dus dat er 1% kans is dat ze het niet zeker weten. En dus 1% kans dat een aanvaller zo een vals certificaat weet te bemachtigen. Dat is voor belangrijke targets (google.com, overheid.nl, jouwbank.nl, etc) echt een veel te grote kans.

Dat is het leipe met Certificate Authorities. Het moet niet 99% goed gaan, of zelfs 99.9%. Het moet eigenlijk altijd goed gaan, want elke fout kan grote gevolgen hebben.

[be3a18]

De telefonische validatie is niet de enige stap. Dit speelt overigens alleen bij Extended Validation certificaten.

[vrow]

Nee, dat klopt helemaal niet.
Je maakt de vergissing te denken dat een certificaat iets zegt over de partij 'erachter'.
DAT IS NIET WAAR!!
Sorry voor de hoofdletters, niet om te schreeuwen, maar wel om te benadrukken :-)

Dat een site een SSL (TLS)-certificaat heeft, zegt alleen maar dat de verbinding beveiligd is. En dan houdt het wel zo'n beetje op.
Het ingevoerde domein moet matchen met het domein in het certificaat, anders geeft je browser een foutmelding daarover.

Maar stel, ik bestel een certificaat voor jouwdomein.nl en kies voor telefoonvalidatie. Maar ik ben niet van jouwdomein.nl maar kom toch door die validatie heen.
Dan heb ik een certificaat voor jouwdomein.nl
Daar kan ik nog helemaal niets mee. Ik moet dan ook de controle hebben over de DNS van dat domein en/of hosts-file van een computer waarvan ik iemand wil beroven. Maar als ik de controle heb over de DNS van een domein wat niet van mij is, dan kan ik sowieso ook al een SSL-certificaat aanvragen via DNS-validatie. Of e-mailvalidatie, want ik pas het MX-record wel even aan.
En kan ik dat allemaal niet, dan kan ik ook niets met dat certificaat.

Dus certificaten zeggen niks, zijn totaal geen graadmeter voor betrouwbaarheid of met wie je van doen hebt. Controleer dus altijd het domein wat je zelf hebt ingevoerd, klik niet op linkjes in mails (maar bezoek altijd zelf de site via bijvoorbeeld een bladwijzer) etc etc.

[deadinspace]

Je maakt de vergissing te denken dat een certificaat iets zegt over de partij 'erachter'.

Ik heb echt geen flauw idee waar je dat vandaan haalt. Dat denk ik helemaal niet, en dat zeg ik ook helemaal niet.

Daar kan ik nog helemaal niets mee. Ik moet dan ook de controle hebben over de DNS van dat domein en/of hosts-file van een computer waarvan ik iemand wil beroven.

Ja, en dat is voor een targeted attack echt geen onrealistische aanname. DNS poisoning is nog steeds niet heel moeilijk, slecht beveiligde wifi netwerken zijn een veel voorkomende vector, en fysieke toegang tot iemands netwerk komt ook voor.

Maar als ik de controle heb over de DNS van een domein wat niet van mij is, dan kan ik sowieso ook al een SSL-certificaat aanvragen via DNS-validatie. Of e-mailvalidatie, want ik pas het MX-record wel even aan.

Om te beginnen hebben we het hier over OV- of EV-certificaten. Dat zijn de enige certificaten waarvoor telefoonvalidatie gebeurt. Dat soort certificaten zijn niet te krijgen met alleen DNS- of email-validatie, dus nee, dat kan niet.

Om verder te gaan, DNS kapen om een vals DV-certificaat te krijgen werkt alleen als je het DNS-record echt aangepast krijgt. Om iemand te MITMen met een vals certificaat is dat niet nodig, dan hoef je alleen iemands lokale DNS aan te vallen, wat veel makkelijker is. Dat is dus geen geldige vergelijking.

[vrow]

Ik denk dat we elkaar verkeerd begrijpen dan.

Ik bedoel vooral te zeggen dat je niet op certificaten moet vertrouwen om zeker te weten dat je met de juiste partij verbinding maakt.
Ook de EV-certificaten zeggen helemaal niks, uiteindelijk.
Daarom zijn de browsers ook al een tijdje geleden gestopt met het tonen van de groene balkjes.

In het algemeen is het aanzetten van 2FA altijd een goed idee, dat beschermt vaak ook tegen sites met valse certificaten die aan het phisen zijn, omdat de TOTP maar een beperkte tijd geldig is.

Passkeys zijn dan helemaal goed, want die werken niet op een valse site, ook al zou het domein kloppen en het certificaat kloppen, dan nog werken ze daar niet en kan de phiser er daarna ook niet mee inloggen.

[Paul]

Waarom is dat geen goede manier? Denk je dat mensen die een malafide certificaat aan willen vragen op jouw domeinnaam je KVK gaan hacken om je telefoonnummer te veranderen? Ik acht het waarschijnlijker dat ze dan ook bij je DNS kunnen (want een website die niemand bezoekt hebben ze niks aan, dus moeten ze zorgen dat je gebruikers/klanten naar hun webserver gaan ipv de jouwe) en dan kunnen ze gewoon DNS-validatie gebruiken.

Telefonische validatie is niet geschikt voor grotere bedrijven (zoals je al ondervonden hebt), maar daar is het ook niet voor bedoeld.

[deadinspace]

Waarom is dat geen goede manier? Denk je dat mensen die een malafide certificaat aan willen vragen op jouw domeinnaam je KVK gaan hacken om je telefoonnummer te veranderen?

Ja, waarom niet? De KvK phishen om dat voor elkaar te krijgen lijkt me verre van onmogelijk. Ook is het telefoonnetwerk slecht beveiligd. Nummers spoofen is makkelijk, inbound kapen is moeilijker maar ook niet onhaalbaar.

Allemaal teveel moeite en risico voor bakkeropdehoek.nl, maar voor high-value targets zijn dit echt wel attack vectors waar je rekening mee moet houden.

[Paul]

Maar geldt datzelfde niet voor je registrar, je DNS en je e-mail? Dan is er dus geen enkele goede manier om het te doen...

[deadinspace]

Die gebruiken als het goed is geen "ik bel een nummer en kijk of er iemand opneemt" verificatie.

Maar ja, dat zijn ook zeker vectors voor zo'n aanval ja.

[Paul]

Ze bellen niet zomaar een nummer, ze bellen het nummer dat je bij het KVK op hebt gegeven.
Ze e-mailen ook niet zomaar een e-mailadres, ze mailen het adres dat je bij je Registrar op hebt gegeven (en soms bieden ze meer opties).
Ze bekijken ook niet zomaar een DNS-record, ze bekijken het record dat jij op hebt gegeven.

Ik geef toe dat ik niet weet wat ze precies vragen tijdens dat telefoongesprek, maar het is echt niet zo dat ze maar wat doen.

[THM0]

Voor mail kun je kiezen uit een paar vaste adressen per domein. Admin@domein etc. Daar sturen ze dan een mail naartoe met een validatie link,

[wildhagen]

Je kan meestal een aantal predefined emailadressen selecteren. Denk aan [e-mail], [e-mail], [e-mail] etc.

Daar wordt dan een mail naar gestuurd, met daarin een lange random code en een URL waar je die code ter verificatie moet invoeren. Als dat matched is de verificatie geslaagd en wordt het certificaat gegenereerd.

[captain007]

DigiCert gebruikt ook nog validatie met TXT records (ook met vergelijkbare tokens die met een underscore beginnen overigens), die vallen ook niet onder deze fout.

[Blokker_1999]

Hoe ga je via mail of telefonisch een domein verificatie doen? Er zijn nog amper TLDs die dat vereisen dat die gegevens worden gepubliceerd in de whois informatie, net weer vanwege privacy problemen die je anders kunt krijgen. Je kan [e-mail] proberen, maar zovele domeinen hebben dat niet opgezet.

Het lijkt mij dan ook eerder om een fout te gaan in de code die de CNAME genereerd om te laten gebruiken door de gebruiker die in uitzonderlijke gevallen een CNAME genereerd zonder de _.

[CH4OS]

Is het niet zo dat EV certificaten de checks bij de 'lagere' validation ook moeten doorlopen die OV en DV dus ook hebben? Wellicht dat alleen DV certiicaten nu vervangen moeten worden, omdat ze dan alleen domain validation hebben?

[Reactie gewijzigd door CH4OS op 1 augustus 2024 09:48]

[TBK001]

Ik heb een artikel op LinkedIn geschreven met daarin uitgelegd:
- Wat certificaten zijn
- Wat certificaten doen
- Waarom je een certificaat wil hebben
- Waar certificaten gebruikt worden
- Hoe je aan een certificaat komt
- En wat er speelt met Digicert

Handig voor de mensen die wellicht net wat minder technisch onderlegd zijn en toch willen weten wat er speelt. Onderstaan staat een link opgenomen naar dit artikel van Tweakers.

https://www.linkedin.com/...-7224738633122017280-9aDw

[Lucb1e]

Het bedrijf zegt dan ook niet of het concrete problemen heeft opgemerkt, maar dat het om een standaardmaatregel gaat.

Deze zin spreekt zichzelf tegen, of lees ik het fout?

Wordt er bedoeld:

Het bedrijf zegt dan ook niet dat het concrete problemen heeft opgemerkt, maar dat het om een standaardmaatregel gaat.

of

Het bedrijf zegt dan ook niet of het concrete problemen heeft opgemerkt, of dat het om een standaardmaatregel gaat.

?

[Reactie gewijzigd door Lucb1e op 1 augustus 2024 21:03]