DigiCert trekt 23.000 certificaten in na ontvangen privésleutels

De Amerikaanse certificaatautoriteit DigiCert heeft besloten 23.000 certificaten in te trekken die toebehoren aan klanten van de reseller Trustico. Deze beslissing was het gevolg van het ontvangen van de bijbehorende privésleutels via een e-mail van Trustico.

DigiCert schrijft in een verklaring dat het ontvangen van de privésleutels betekende dat het intrekkingsproces volgens de regels van het CA/Browser Forum in gang gezet moest worden, omdat de veiligheid daarvan niet meer vaststaat. Dat betekent dat de certificaten binnen 24 uur teruggetrokken moeten worden. The Register schrijft dat het bedrijf vervolgens de getroffen klanten van Trustico, dat de certificaten had verkocht, een e-mail heeft gestuurd om ze hierover te informeren. Trustico zegt dat die e-mail nooit door DigiCert verstuurd had mogen worden.

Op een Mozilla-mailinglijst beschrijft Jeremy Rowley van DigiCert zijn kant van het verhaal en claimt dat Trustico begin februari DigiCert verzocht om 50.000 certificaten in te trekken. Dat deed DigiCert niet meteen, omdat het voor het bedrijf niet duidelijk was of een reseller dit wel kan doen in plaats van de klant. Trustico claimde vervolgens dat de certificaten niet langer veilig waren en dat ze daarom ingetrokken moesten worden, aldus Rowley. Toen DigiCert om bewijs vroeg, stuurde het bedrijf de bijbehorende privésleutels via e-mail. Dit betekende dat DigiCert geen andere keuze had dan de certificaten in te trekken.

Trustico heeft in een blogpost een eigen versie van de gebeurtenissen weergegeven. Daarin claimt het dat het niet meer geloofde in de veiligheid van de certificaten die het had afgenomen van Symantec, dat vorig jaar zijn certificatenonderdeel verkocht aan DigiCert. Daarom wilde het deze door DigiCert laten intrekken. In de blogpost maakt het eveneens melding van een e-mailwisseling, waarbij het uiteindelijk overging tot het versturen van de eerdergenoemde privésleutels.

Deze had het bedrijf in zijn bezit, omdat 'het de sleutels na het aanmaken ervan in cold storage opsloeg voor intrekkingsdoeleinden'. Verschillende beveiligingsexperts stellen dat het niet de bedoeling is dat iemand anders dan de certificaathouder, in dit geval de klanten van Trustico, toegang heeft tot de privésleutel. Dit zou neerkomen op een 'enorm beveiligingslek'. Door in het bezit te zijn van een privésleutel kan iemand zich immers voordoen als de eigenaar van het certificaat.

Volgens The Register speelt op de achtergrond dat Trustico deze maand besloot om geen Symantec-certificaten meer aan te bieden. Het zei dat de beslissing samenhangt met het punt dat Google zijn vertrouwen in deze certificaten in de komende maanden zal intrekken. Trustico zei daarom over te gaan naar Comodo-certificaten. The Register schrijft dat het erop lijkt dat websitehouders het slachtoffer zijn geworden van een 'territoriumstrijd' tussen DigiCert en Trustico.

Reacties (89)

[maescool]

Blijkt nu ook dat op de site van Trustico je doodleuk bash scripts kan laten draaien op hun webserver (als root notabene)
https://twitter.com/svblxyz/status/969220402768736258

Dit wilt dus zeggen, alle certs dat deze leverancier ooit geleverd heeft, als compromised kan aanzien. (indien zij private key gegenereerd hebben)
vermoed dat dit nog een serieus staartje gaat krijgen

[Mel33]

De https://www.trustico.com site is nu 503

[Joris]

Wat ik het meest idiote van het verhaal vindt, is dat Trustico geen andere manier kon bedenken om het geschil op te lossen dan het sturen van de private keys. Immers, hoe meer partijen de sleutel hebben, hoe groter de kans dat het fout gaat.

Juist met private keys is het heel makkelijk om aan te tonen dat je ervan in het bezit bent zonder de keys zelf te delen. Trustico had prima een (door Digicert aangeleverd) berichtje kunnen ondertekenen met de sleutels en vervolgens alle sleutels kunnen verwijderen. Wanneer Digicert een dergelijk ondertekend bericht ontvangt, kan het niet anders dan concluderen dat Trustico de private keys in handen heeft. Dat zonder dat Trustico de sleutels met nóg een partij hoeft te delen.

Het is immers heel leuk dat al die certificaten worden ingetrokken, maar dat is verre van waterdicht (als de client de revocation list niet kan opvragen, kan het ook niet controleren of het certificaat is ingetrokken).

[Slaut]

Voor iedereen die meer over public/private keys wil weten: https://www.youtube.com/watch?v=GSIDS_lvRv4

[Keneo]

Dit heet een 'certificate revocation request'
Iedereen met een private key zou zo een request kunnen ondertekenen, waarna de revocation procedure van start gaat. Maar dit lijkt door digicert niet ondersteund, of toch geen automatische/gebruiksfriendelijke methode voor.
https://www.digicert.com/certificate-revocation.htm

[L01]

Dus als ik het goed begrijp zijn nu de certificaten ingetrokken omdat Trustico de private keys van alle 23.000 certificaten via mail heeft verstuurd naar Diginotar en niet perse omdat Trustico daar om vroeg?

[thomasbaart]

DigiCert weigerde inderdaad in eerste instantie om de certificaten in te trekken, omdat Trustico niet de eigenaar is van de certificaten. De klanten van Trustico hadden dat aan moeten vragen.

Daar was Trustico het niet mee eens, dus stuurden ze private keys op waardoor DigiCert volgens protocollen genoodzaakt was de certificaten te verwijderen.

Wat ook belangrijk is, is de vraag of het wel juist was van Trustico om alle private keys op te slaan. Dat vergroot je attack surface enorm en dat maakt het risico van een lek voor eindklanten ook groter.

Diginotar staat hier volledig buiten

[Aaargh!]

Wat ook belangrijk is, is de vraag of het wel juist was van Trustico om alle private keys op te slaan.

Dat is zeer zeker niet de bedoeling, Trustico had NOOIT de private keys mogen hebben, voor een certificaat maak je zelf een key pair, dan stuur je een CSR om het certificaat (met daarin de public key) te laten ondertekenen. Die private key is zoals de naam al zegt private, en ook je SSL provider mag deze niet hebben. Dat is ook de reden dat deze certificaten worden ingetrokken, Trustico heeft laten zien dat ze private keys hebben voor die certificaten en die hadden ze nooit mogen hebben, als gevolg daarvan worden de certificaten als gecompromitteerd beschouwd.

[CAPSLOCK2000]

Dat is zeer zeker niet de bedoeling, Trustico had NOOIT de private keys mogen hebben, voor een certificaat maak je zelf een key pair, dan stuur je een CSR om het certificaat (met daarin de public key) te laten ondertekenen.

Dat is de theorie. In praktijk is 80% daar niet toe in staat; die moeten zo'n webinterface hebben die alles voor ze regelt en andres gaan ze wel naar een andere partij.

[Aaargh!]

Misschien moet je je in dat geval niet bezighouden met het beveiligen van servers.

Of je installeert een Let's Encrypt client, die doet het automatisch goed.

[CAPSLOCK2000]

Misschien moet je je in dat geval niet bezighouden met het beveiligen van servers.

Ga jij het ze vertellen?
Ik zou ook liever hebben dat dit soort clubs niet verantwoordelijk zijn voor veiligheid, maar dat is nu eenmaal de praktijk. Dat is nu net mijn punt. We kunnen hier prachtige ideetjes hebben over hoe het zou moeten, maar ondertussen gaan die bedrijven gewoon verder met rommelen want ze verdienen er goed aan.

[Olaf van der Spek]

Wat ook belangrijk is, is de vraag of het wel juist was van Trustico om alle private keys op te slaan.

Is de juiste vraag niet waarom Trustico uberhaupt de private keys in handen heeft gehad?
Voor zover ik weet is dat niet nodig om een certificaat te laten ondertekenen.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 20:26]

[GekkePrutser]

Precies... Je stuurt alleen een CSR. De private key hou je zelf.

Maar veel PKI boeren geven wel de mogelijkheid om zelf een key te genereren als je dat per se wil. Als dat het geval is dan kan je dat wel doen ja, alleen is het natuurlijk absoluut niet aan te traden.

[Olaf van der Spek]

Die mogelijkheid zou gewoon verboden moeten worden..

[CAPSLOCK2000]

Ik weet werkelijk niet of ik daar achter zou staan. Mijn eerste reactie is we dit inderdaad moeten verbieden want het is niet in lijn met hoe SSL bedoeld is en het kan dramatisch fout gaan, zoals we hier zien
Mijn tweede reactie is echter "Wat gaan we dan doen?". Ik heb niet de illusie dat mensen opeens iets over IT gaan leren als ze hun certs niet meer via de website van de leverancier kunnen aanmaken. Ze gaan echt niet zelf met openssl aan de slag
In praktijk zou het dus betekenen dat derde partijen websites gaan opzetten om je te helpen met het aanmaken van een private key (of om te "helpen"), dat er allerlei gare apps geschreven gaan worden om certs aan te maken en dat er op grote schale private keys heen en weer gemailed gaan worden.

Welbeschouwd is de website van de leverancier misschien wel de minst slechte oplossing. Die leverancier zal je toch moeten vertrouwen anders heeft de hele exercitie sowieso geen zin. Nu zijn daar ook nog wel wat kanttekeningen bij te plaatsen, maar voor de meeste organisaties gaat dat veel te ver. De echte grote jongens, die rekening moeten houden met problemen bij een SSL-boer, die hebben de kennis en de techniek wel om hun eigen private keys te beheren. De rest gaat het waarschijnlijk toch niet beter doen dan wat de leverancier verzorgt.

[zenlord]

Volledig akkoord, met 1 kanttekening: het is niet omdat de website van de leverancier voor jou een private key genereert, dat de website deze private key ook moet opslaan. De website kan deze tijdelijke data ook gewoon vergeten.

Voorts vind ik het een interessante discussie - maar ik begrijp de feitelijke situatie niet zo goed: zoals het wordt voorgesteld door DigiCert, heeft Trustico eerst enige tijd de private keys bewaard, en vervolgens tot inzicht gekomen dat deze praktijk verkeerd is. In dat verhaal lees ik ook dat Trustico een partij certificaten van Symantec heeft overgenomen - dus misschien heeft Symantec deze private keys mee ontvangen van Symantec?

[:murb:]

DigiCert heeft de certificatenuitgifte tak van Symantec overgenomen nadat voor top. Van mijn eigen blog over de Symantec-certificaten:

Symantec heeft het uitgeven van certificaten uitbesteed aan andere partijen en door gebrekkig toezicht op deze partijen heeft het kunnen voorkomen dat er ten onrechte certificaten zijn verstrekt aan derden die geen eigenaren waren van de domeinnaam.

Dit is de aanleiding geweest van Trustico, die, zo vermoed ik, een "stoere publiceitsstunt" heeft willen uithalen, die vervolgens pijnlijk hun eigen onzorgvuldigheid bloot heeft gelegd.

[Reactie gewijzigd door :murb: op 23 juli 2024 20:26]

[Olaf van der Spek]

Mijn tweede reactie is echter "Wat gaan we dan doen?".

LetsEncrypt?

[CAPSLOCK2000]

LetsEncrypt is een oplossing voor een groot deel van het probleem, maar je hebt wel medewerking van de hoster nodig. Dat is nog niet standaard, al gaat het steeds beter. Als jouw hoster geen Letsencrypt ondersteunt dan kan niemand je daar mee helpen. Je kan wel naar Digicert (of een concurrent) gaan en via de website een cert in elkaar klikken. Tot LE zo standaard wordt dat de meeste hosters het ondersteunen zal er een behoefte blijven aan traditionel CA's (daarna ook nog, maar niet meer voor eenvoudige certs voor websites).

[robvanwijk]

Diginotar staat hier volledig buiten

Ik snap dat het een typo was, maar op zich, als de rest van de beveiligingsgemeenschap het onacceptabel vindt dat Trustico die private keys in beheer had, dan kunnen we heel snel het punt bereiken waarop Trustico "Diginotar 2.0" wordt. Als een paar grote partijen alles wat Trustico doet blacklisten, dan zijn ze volgende week failliet.

[Pizzalucht]

Trustico is geen CA, maar een reseller.

[Verwijderd]

Trustico is er dus in geslaagd om zichzelf te compromisen? Knap! :-D

Het blijft bizar dat Trustico uberhaupt al toegang had tot de prive-sleutels. Normaal gezien hoort een CA enkel de CSR te ondertekenen, en blijft de prive-sleutel in handen van de klant.

[Terrestrial]

Ik ben ook klant bij Trustico en mijn certificaat valt ook onder de getroffende. Naar mijn idee behoren hun de private key(s) niet zelf te bewaren dus zijn ze hierbij al niet betrouwbaar gebleken.

Nu zit ik dus met 2 bedrijven (trustico en Symantec digitcert) die elkaar tegen spreken en mij beide een nieuwe gratis certificaat aanbieden. Enerzijds gunstig aangezien het certificaat over een paar maanden zou verlopen. Maar welke moeten we nu kiezen?

[Robbaman]

Ik zou geen vertrouwen meer hebben in deze partijen en gewoon lekker voor een paar tientjes bij een andere partij nieuwe certificaten aanvragen...

[Raypie]

Gebruik sinds kort Let's Enrypt. Gratis. En met Certbot wordt het certificaat automatisch elke paar maanden vernieuwd.

[GekkePrutser]

Ik heb er ook naar gekeken maar het is erg lastig als je het alleen voor je mailserver wil hebben. Dan moet je per se een open webserver draaien voor certbot.

Jammer dat dat niet op een andere manier kan.

[Inny]

Dat is onjuist.
Er zijn andere methodes voor verificatie, zoals DNS.
Het automatiseren hiervan is in de regel echter complexer.
Tevens bestaat uiteraard de mogelijkheid om je 'open webserver' dicht te timmeren.

[GekkePrutser]

Snap ik maar ik wil gewoon geen webserver draaien, en al helemaal niet op mijn mailserver Veel te veel extra gedoe voor alleen een gratis SSL cert.

Die DNS methode kan bij mij ook niet omdat ik die via een provider doe, ik heb daar geen volledige controle over en niet geautomatiseerd.

Ik vind het alleen jammer dat ze zo gefocused zijn op webservers, terwijl ze bijv. ook validatie via email zouden kunnen doen.

Maar het is niet zo'n probleem, SSL certificaten kosten toch niet zoveel meer dus ik koop ze gewoon.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 20:26]

[rbr320]

Validatie via email lijkt me voor Let's Encrypt niet werkbaar, tenzij je dit op een of andere manier kan automatiseren. Aangezien de certbot software en het ACME protocol volledig open zijn zou je hier in theorie een plugin voor certbot voor kunnen schrijven die een mailbox monitort voor de challenge, een response mailt en uiteindelijk het certificaat uit de mailbox pakt en installeert. Uiteraard moet de server ook gaan ondersteunen dat de challenge over SMTP gaat, maar dat zie ik eigenlijk niet snel gebeuren.

Overigens hoef je helemaal niet permanent een webserver te draaien op de server waar je een Let's Encrypt certificaat op wilt hebben. Ik maak zelf gebruik van de "standalone" methode om certificaten aan te vragen waarbij de certbot software tijdens het proces zelf voor webservertje speelt. Uiteraard moet dan wel poort 80 of 443 open staan (afhankelijk van of je http of tls-sni gebruikt), maar dat is met een pre-hook en post-hook wel te scripten.

[The Zep Man]

Snap ik maar ik wil gewoon geen webserver draaien, en al helemaal niet op mijn mailserver Veel te veel extra gedoe voor alleen een gratis SSL cert.

Je bent erg dramatisch. Alsof een certificaat aanschaffen en handmatig installeren geen gedoe is.

Het hoeft geen permanente webserver te zijn. Een tijdelijke webserver is ook te automatiseren. Veel minder gedoe.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 20:26]

[GekkePrutser]

Het is maar weinig gedoe omdat het eens in de paar jaar moet, immers zijn commerciele certificaten veel langer geldig.

[zenlord]

Je hebt nog altijd twee opties:
1. Ofwel doe je het om de drie maanden manueel - het neemt echt niet zo veel tijd in beslag;
2. Ofwel laat je certbot volautomatisch een eigen standalone webserver opstarten voor de duurtijd van de challenge. Met een eenvoudige pre- en post-hook kan je desgewenst ook tijdelijk een gaatje prikken in je firewall op poorten 80 en 443.
Easy peasy.
Ik ben het voorbije weekend bezig geweest met DNS-01 challenge via certbot op mijn servers. Vooralsnog is automatische renewal niet mogelijk via de Debian packages in stretch-backports (maar dat wordt in de komende 2-3 maanden verholpen).
Ik zie geen enkele reden meer om betalende certificaten te gebruiken, tenzij je Extended Validation Certificates nodig hebt.

[GekkePrutser]

Het is niet zo eenvoudig want al mijn servers draaien als aparte VM's (en docker containers in sommige gevallen). Dus die poorten worden niet doorgezet en vaak al door andere servers gebruikt. 80 gebruik ik helemaal niet maar 443 is al in gebruik. En Let's Encrypt ondersteunt alleen de standaard poorten. Ik heb niet voor elke service een apart IP.

En de DNS methode is lastig omdat de provider waar ik mijn domeinen heb gekocht de DNS beheert, vind ik ook wel handig zo. Maar ik heb daar geen API van.

Sowieso is het een beetje vreemd dat Letsencrypt 80 en 443 vereist in plaats van alleen 443.

Maargoed juist door de concurrentie van Letsencrypt is de prijs erg omlaag gegaan dus ik vind het wel prima zo.

[mrdemc]

Nee je kunt de webserver niet dichttimmeren want dan kan Letsencrypt het niet controleren.
https://community.letsenc...anges-in-firewall/45190/7

De andere validatie opties zijn wel mogelijk natuurlijk.

[zenlord]

Tip: certbot hooks. Bvb: https://www.digitalocean....-encrypt-ssl-certificates

[!GN!T!ON]

DNS verification geen optie?

[Yggdrasil]

Je kunt ook valideren via DNS als je een DNS server hebt die via een API aangestuurd kan worden. Als je certbot niet handig vindt zijn er ook andere acme clients die soms betere support voor DNS validatie hebben.

HTTP validatie is inderdaad de makkelijkste methode.

[Blokker_1999]

Tjah, LE is op dit moment dan ook niet bedoeld voor mail servers. Dat het werkt is mooi meegenomen, maar is niet het doel op zich. Neemt niet weg dat ik het zelf ook gebruik, al heb ik wel het voordeel dat er reeds een webserver aanwezig is voor de webmail. Je zou eventueel een zeer lichte webserver kunnen opzetten die je enkel lanceert op het moment dat certbot draait (certbot heeft de mogelijkheid om commandos uit te voeren voor/na).

[XFlame]

Gezien de handelswijze van Trustico is het niet aan te raden om bij deze partij te blijven. Wanneer je een mass-revoke forceert door de keys via emailverkeer te versturen, dan is het duidelijk dat je niet betrouwbaar bent en dat je niet denkt aan het belang van de klant.

[SuBBaSS]

++

Het is toch wat dat het bedrijf nota bene "Trust" in z'n naam heeft staan en het zo te grabbel gooit.
En dan helemaal op een gebied waar juist alles om dat vertrouwen draait.

_{Ja, hier kan ik wel een opzetje in zien. Met "foutje, bedankt" komen ze hier natuurlijk niet weg.}

[rbr320]

Mijn vuistregel is dat hoe meer een bedrijf er op hamert dat ze echt te vertrouwen zijn (door middel van hun naam, logo, persberichten, mission statement, etc.) hoe minder ze dat vertrouwen waard zijn.

Overigens hanteer ik deze vuistregel ook bij politici en wetsvoorstellen

[mjz2cool]

is het niet zo dat trustico de certificaten wou laten intrekken juist omdat ze de private keys in bezit hadden en de certificaten dus compromised waren?

[XFlame]

Dat maakt het verhaal er voor Trustico niet beter op, want als reseller is het bezit van de private key een extra veiligheidsrisico.

Digicert heeft in dit alles niets fout gedaan, dit ligt volledig bij Trustico.

[robvanwijk]

is het niet zo dat trustico de certificaten wou laten intrekken juist omdat ze de private keys in bezit hadden en de certificaten dus compromised waren?

Die redenering werkt alleen als ze oorspronkelijk niet wisten dat ze alle private keys bewaarden en daar opeens achter komen. Geen heel realistisch scenario.

Wat er wel gebeurd is ("gebeurd lijkt te zijn"?) staat overigens gewoon in het artikel:

Daarin claimt [Trustico] dat het niet meer geloofde in de veiligheid van de certificaten die het had afgenomen van Symantec, dat vorig jaar zijn certificatenonderdeel verkocht aan DigiCert. Daarom wilde het deze door DigiCert laten intrekken.

[locke960]

Ik ben ook klant bij Trustico en mijn certificaat valt ook onder de getroffende. Naar mijn idee behoren hun de private key(s) niet zelf te bewaren dus zijn ze hierbij al niet betrouwbaar gebleken.

Waarom heb je jou private key überhaupt aan Trustico gegeven? Dat lijkt me de eerste fout te zijn.

[:murb:]

Rustig Punt wat @locke960 maakt is dat je de volgende keer Trustico, maar ook iedere andere partij links moet laten liggen die jou het genereren van een private key aanbiedt, hoe gemakkelijk het ook lijkt: een professionele partij weigert zoiets te doen, want het is te riskant. Zelfs al beloven ze de private key niet op te slaan, het risico dat de private key op een plek terecht komt waar deze niet hoort te zijn is te groot. Het certificaat biedt dus mogelijk slechts schijnveiligheid, iets dat nog erger is dan expliciet geen veiligheid.

Zoek hoe je een Certificaat Signing Request op je eigen server kunt aanmaken, zoals meerderen in deze reacties al hebben aangegeven en dan is het gewoon niet mogelijk dat een andere partij kan beschikken over over jou private key (tenzij je eigen server is gecompromised natuurlijk).

[:murb:]

De browser is geen veilige plek voor een private key. De server die de dienst levert kan sowieso de private key uitlezen en opslaan zonder dat jij het door hebt, en met wat ongeluk zit er nog ergens een XSS bugje waardoor een andere partij ook nog rustig mee kan kijken: Vandaar dat je in het vervolg slechts certificaten aan moet vragen middels een Certificaat Signing Request, je hoeft niet eens een private key te cat'en op je server.

Vraag gewoon via een andere verkoper een DigiCert certificaat aan met een CSR. DigiCert heeft niets verkeerd gedaan, Trustico is gewoon, anders dan de naam probeert te suggereren, niet betrouwbaar geweest. Geen zaken met hen meer doen.

[SibboNL]

Even ter verduidelijking: Symantec is hierin geen partij: de werkzaamheden van Symantec zijn verkocht aan DigiCert.
Het lijkt me sterk dat ze je allebei een certificaat aanbieden: DigiCert is in deze alleen de authoriteit, niet waar je je certificaat aanvraagt.

[Terrestrial]

Nee mail is duidelijk van Symantec

Symantec Website Security, provided by DigiCert <[e-mail]> met Act Now: Replace Your SSL Certificate en een link om 'm gratis te vervangen.

[Fido]

Een private key zou je per definitie zelf moeten genereren zodat de CA alleen de signing request hoeft te krijgen.

[CH4OS]

Ik zou Trustico als bedrijf niet meer vertrouwen. Je kunt ook overwegen om Let's Encrypt certificaten te gaan gebruiken, kosten bovendien ook niets!

[Aaargh!]

Het blijft bizar dat Trustico uberhaupt al toegang had tot de prive-sleutels.

Dat is het ook, en dat was ook de reden dat Trustico die certifaten gerevoked wilde hebben. Toen DigiCert dit weigerde stuurden ze de private keys op (die ze nooit hadden mogen hebben) om daarmee aan te tonen dat de certificaten gecompromitteerd waren.

[Mathijs]

Die ze zelf speciaal tegen alle regels in opsloegen voor juist dit soort misbruik.
Wat mij betreft hebben ze hun eigen doodvonnis hiermee in gang gezet en zelf ondertekend.

Trustico zegt dat die e-mail nooit door DigiCert verstuurd had mogen worden.

Dit bedrijf heeft wel een heel vreemde gedachtegang dan. Ze resellen DigiCert certificaten, dan is het toch niet gek dat DigiCert contact zou kunnen opnemen met de eindgebruikers die hun certificaat gebruiken?
Als er bij bijvoorbeeld een telefoonfabrikant accu's in brand vliegen krijg je toch ook een grote terugneem-actie vanuit de fabrikant en niet vanuit de specifieke winkels die de telefoons verkocht hebben? Die gebruiken dan zelfs de media om alle eindgebruikers te bereiken.

[Reactie gewijzigd door Mathijs op 23 juli 2024 20:26]

[etiennebruines]

Trustico heeft aan DigiCert gevraagd de certificaten in te trekken, omdat ze 'compromised' waren. Toen vroeg DigiCert hoezo, en mailde Trustico de private keys. Toen moest DigiCert ze wel intrekken.

[Jazzy]

Ik snap waar de verwarring vandaan komt, maar het gaat om DigiCert en dit keer in over Diginotar.

[Jefrey Lijffijt]

Ja, het 'lekken' van de private keys is reden om ze in te trekken. Een verzoek van een reseller blijkbaar niet. Blijkbaar wist Trustico al precies hoe de regelgeving in elkaar zit en hebben ze specifiek daarvoor dus een database met private keys bijgehouden. Ze vonden het risico daarvan dus het waard, wellicht omdat ze hun klanten zelf niet betrouwbaar genoeg achten.

[ExIT]

Wauw. Dit is een bijzonder verhaal om meer dan 1 reden:

- Drama in een wereld waar vertrouwen het product is
- Trustico welke als 10 jaar lange Symantec afnemer afscheid wil nemen omdat Google in Chrome die certs niet meer gelijk (zal) behandelen
- Trustico welke een kopie van private keys bleek te houden voor zichzelf
- DigiCert welke van 50.000 individuen de private keys terug eist via Trustico neigt ook naar een poging tot “je kan niet weg, zoek het maar uit, lukt je toch niet” (adm. praktisch onmogelijk)
- 23.000 van de 50.000 zijn ingetrokken. Is de rest niet aangeleverd of blijft DigiCert vastklampen aan een laatste strohalm?

Dit geeft certs opnieuw een imagodeuk, ook al is het wellicht een strijd tussen concurrenten. Onwenselijk.

[Reactie gewijzigd door ExIT op 23 juli 2024 20:26]

[daredevil__2000]

- DigiCert welke van 50.000 individuen de private keys terug eist via Trustico neigt ook naar een poging tot “je kan niet weg, zoek het maar uit, lukt je toch niet” (adm. praktisch onmogelijk)

DigiCert heeft aangegeven dat Trustico geen partij is in het intrekken van certificaten omdat de eindgebruiker de eigenaar is van het certificaat en niet Trustico. DigiCert heeft niet gezegd geef mij die private keys, mede omdat je die als reseller normaal niet zou hebben. Trustico blijkt dus gewoon volledig onbetrouwbaar te zijn en DigiCert heeft gewoon netjes gehandeld binnen wat er mag.

[killercow]

Je kunt altijd weg bij een club als DigiCert, gewoon elders een ssl cert aanmaken is genoeg. Intrekken is niet persee nodig, en in het geval van Chrome dus al helemaal niet meer nodig over een maandje of wat.

[Pizzalucht]

- DigiCert welke van 50.000 individuen de private keys terug eist via Trustico neigt ook naar een poging tot “je kan niet weg, zoek het maar uit, lukt je toch niet” (adm. praktisch onmogelijk)

Trustico kan wel weg, ze kunnen gewoon naar een andere CA en daar nieuwe ceritficaten genereren. Je hoeft certificaten niet per se in te trekken, al helemaal niet als ze nog gewoon veilig zijn.

- 23.000 van de 50.000 zijn ingetrokken. Is de rest niet aangeleverd of blijft DigiCert vastklampen aan een laatste strohalm?

Waarschijnlijk heeft Trustico alleen de private keys van de certificaten die via hun web-portal zijn aangemaakt. Van de overige 27.000 certificaten hebben de eigenaren waarschijnlijk alleen de CSR aangeleverd en zelf de private key gegenereerd.

===

Naar mijn inzien probeerde Trustico een mass re-issue voor al zijn klanten in 1x te regelen, dit scheelt voor Trustico veel werk, en voor de klanten van Trustico ook. Hierbij is ergens door Trustico een denkfout gemaakt waardoor 23.000 certificaten zijn ingetrokken.
De betere manier was echter geweest als Trustico met zijn klanten had gecommuniceerd, de klanten hadden dan een nieuwe CSR kunnen uploaden en hun private key kunnen vervangen.

Overigens had Trustico natuurlijk gewoon de CSR's kunnen bewaren ipv de private keys, en met die CSR's bij een andere CA kunnen aankloppen.

[Wim-Bart]

Lijkt mij meer dat Trustico als onveilige partij moet worden beschouwd, want hoe komen zij aan de Private key's.

[Mel33]

Trustico is doorverkoper, en het is helemaal niet normaal dat ‘anderen’ dan de ‘eigenaar zelf’ van een certificaat, de sleutel hebben.

Dus de uitgever verzuimd hier, trustico verkocht ze door en merkte op dat de sleutel erbij zat.

Zo lees ik het

[Reactie gewijzigd door Mel33 op 23 juli 2024 20:26]

[MDKlapwijk]

Denk dat Trustico de privates zelf gegenereerd heeft voor de klant en deze bewaard heeft. Met de bijbehorende csr hebben ze het certificaat vervolgens bij hun leverenacier aangevraagd....

[Fido]

Bij de meeste resellers is het mogelijk om voor het gemak via de clientportal een certificaat te genereren zodat je dit niet zelf hoeft te doen. In dat geval heeft de reseller dus de private key gegenereerd en krijg je die geleverd van de reseller. Trustico heeft dat in dit geval waarschijnlijk ook gedaan en de private keys tevens bewaard, waarschijnlijk voor eventueel toekomstig gebruik bij een supportvraag van de eindklant.

Dus eigenlijk is het gewoon de schuld van de eindgebruiker. Die had z'n private key en signing request zelf moeten genereren.

[Reactie gewijzigd door Fido op 23 juli 2024 20:26]

[Wim-Bart]

Ik lees het als: Trustico verkocht de certificaten en legde een database aan van deze certificaten en extraheerde tevens de private key.

Ik kan namelijk als klant bij een request aangeven of ik de Private key exportable maak. Maar dat wil nog niet zeggen dat de leverancier deze key zo maar uit het certificaat mag halen.

[Yggdrasil]

Als je normaal via een CSR een certificaat aanvraagt vanaf je eigen server of pc dan verlaat de private key de computer van de klant niet. Er is dus niks te exporteren.

Trustico kan er alleen aangekomen zijn als ze een soort web-gebaseerd tool hebben waarmee je certificaten kunt aanvragen waarna ze de private en public key beiden naar de klant toe sturen (en stiekem een kopie van de private key houden). Dat gaat tegen de regels in.

[BrightSilence]

Right, dus ze schakelen nu over naar Comodo. Die in het verleden ook regelmatig niet volgens de afspraken heeft gehandeld bij het uitlekken van keys. En recent nog volledig het CAA DNS record negeerde.

[Terr-E]

Vergeef me mijn onwetendheid, maar welke CA is er tegenwoordig nog wel te vertrouwen ? Volgens mij hebben ze allemaal wel ooit dingen gedaan die niet door de beugel kunnen. (en zeg ajb niet Let's Encrypt)

[Verwijderd]

Wij zijn al heel wat jaren klant bij Digicert en ik hoop dat wij daar nog heel lang klant blijven. Digicert is heel snel, heel betrouwbaar levert mooie tooling en doet veel aan security bijv. multifactor login's, delegation etc etc.

En Let's Encrypt is wel leuk maar probeer maar eens OV, EV of client certificaten om maar paar te noemen via Let's Encrypt te verkrijgen

[MDKlapwijk]

Vergeet niet de onglimiteerde duplicates van wildcards te vermelden. Elke server of servergroep zijn eigen private....

[wica]

Wat is er mis met Let's Encrypt als ik vragen mag?

Verder moet je elke CA, maar op hun "blauwe" ogen vertrouwen.

[Blokker_1999]

Geen wildcard bijvoorbeeld. Alleen maar bedoeld voor https (hoewel je er ook enkele andere dingen mee kunt doen). Een mooi project (maak er zelf ook gebruik van) maar dus met wat beperkingen.

[Mathijs]

Geen wildcard is toch geen probleem wanneer je zo makkelijk geautomatiseerd kunt aanmaken wat je nodig hebt?

[Yggdrasil]

Het gaat in dit topic over vertrouwen, niet features! Het enige dat ik Let's Encrypt qua vertrouwen kan aanrekenen is de recente kwetsbaarheid in TLS-SNI-01 validatie waardoor onterecht certificaten konden worden uitgegeven.

[wica]

Geen wildcard zie ik niet als een probleem. Je kan voldoende domeinen toevoegen aan 1 certificaat.
En als je het toch nodig hebt, maakt die paar honderd euro ook niet uit.

En het is idd een mooi project voor gratis certificaten en het vernieuwen er van weg te automatiseren.

(en zeg ajb niet Let's Encrypt)

Hier reageerde ik op, als of er iets mis is met Let's Encrypt. Vandaar de vraag.

[Terr-E]

Met name dat ze geen Organisation Validation en Extended Validation certificaten doen (alleen Domain Validation), en nog te kort bestaan om een betrouwbaarheidsgeschiedenis te hebben opgebouwd.

[wica]

Maar voor OV en EV gelden toch hele anderen eisen voor het aanvragen van een certificaat, dan voor een gewone?

Ik denk ook niet dat het wenselijk is, dat een OV/EV automatische geupdate kunnen worden.

Is een beetje appels met peren vergelijken.

[Terr-E]

Daarom. Mijn oorspronkelijke vraag was dan ook "welke CA is er tegenwoordig nog wel te vertrouwen ?"
Let'sEncrypt valt dus af omdat ze geen OV en EV doen, en omdat ze pas sinds kort bestaan en er dus geen geschiedenis is, zoals wel het geval is bij Symantec, Comodo, Digicert etc.

[CorbataGames]

Het CAA record is pas sinds september 2017 een verplichte controle voor SSL uitgevers (zoals Comodo). Op zich netjes als ze zich er al eerder aan hadden gehouden, maar toch, ze stonden in hun recht.

[BrightSilence]

Ze hielden zich er na die deadline ook niet aan. Misschien inmiddels wel. Maar in september zeker nog niet.

[CAPSLOCK2000]

Wat een verhaal, er gaat hier zo veel mis dat ik door de bomen het bos niet meer zie. Er is hier weer eens blunder op blunder gestapeld:
- bewaren van de private keys. Ik weet dat het haast standaard is, maar het is fundamenteel een slecht idee.
- blijkbaar heeft digicert nooit nagedacht over de relatie met resellers
- encrypted e-mail is zelfs bij deze partijen niet in gebruik
- de CEO heeft toegang tot dergelijke gevoelige data (zonder dat er techneuten tussen zitten die hem beschermen tegen dit soort blunders)
- de CEO weet zo weinig van z'n vakgebied dat hij een dergelijke blunder begaat
- dergelijke bedrijven lijken te communiceren via hun helpdesk
- alles wat de helpdesk zegt wordt blind uitgevoerd


Ik hoop eigenlijk dat Trustico met open ogen die private keys via onbeveiligde mail heeft verstuurd om Digicert te dwingen om mee te werken, maar links of rechts om blijft het erg dom.

[Twixie]

"Verschillende beveiligingsexperts stellen dat het niet de bedoeling is dat iemand anders dan de certificaathouder, in dit geval de klanten van Trustico, toegang heeft tot de privésleutel."

Erm, daarvoor moet je toch geen beveiligingsexpert zijn ?
Zoiets van: slotenmakers waarschuwen dat het niet veilig is je sleutel onder de deurmat te bewaren.

[daredevil__2000]

"Verschillende beveiligingsexperts stellen dat het niet de bedoeling is dat iemand anders dan de certificaathouder, in dit geval de klanten van Trustico, toegang heeft tot de privésleutel."

Erm, daarvoor moet je toch geen beveiligingsexpert zijn ?
Zoiets van: slotenmakers waarschuwen dat het niet veilig is je sleutel onder de deurmat te bewaren.

Voorbeeld zou eerder zijn dat de fabrikant van sloten een waarschuwing doet dat het niet veilig als je slotenmaker of de winkel waar je het slot gekocht hebt een kopie in zijn bezit heeft van jouw slot

[Jantimon]

De metafoor zou moeten zijn:

Fabrikant roept sloten terug omdat de winkel een kopie van de sleutel blijkt te hebben voor het slot dat je bij hun kocht.

[Reactie gewijzigd door Jantimon op 23 juli 2024 20:26]

[uiltje]

Ik denk niet dat Diginotar hiermee iets te maken heeft. Behalve dan dat die zich ook van idiote methoden zoals het zelf genereren van de private sleutel bezig hield.

[Reactie gewijzigd door uiltje op 23 juli 2024 20:26]

[Origin64]

Deze had het bedrijf in zijn bezit, omdat 'het de sleutels na het aanmaken ervan in cold storage opsloeg voor intrekkingsdoeleinden'. Verschillende beveiligingsexperts stellen dat het niet de bedoeling is dat iemand anders dan de certificaathouder, in dit geval de klanten van Trustico, toegang heeft tot de privésleutel. Dit zou neerkomen op een 'enorm beveiligingslek'. Door in het bezit te zijn van een privésleutel kan iemand zich immers voordoen als de eigenaar van het certificaat.

Zoals ik al jaren zeg, hoeveel zin heeft encryptie als je je privesleutels aan een ander toevertrouwt? Hetzelfde geld bijv voor encrypted chats in whatsapp of een andere chat app. Het encryptie algoritme kan zo sterk zijn als je wilt, de key die voor jou is gegenereerd staat gewoon in een db en dan is het niet veilig.