Mozilla vertrouwt nieuwe WoSign- en StartCom-certificaten niet

Mozilla heeft bekendgemaakt dat het nieuwe certificaten van WoSign en StartCom niet vertrouwt. De certificaatautoriteiten hebben verschillende fouten gemaakt, waaronder het antedateren van certificaten om de uitfasering van sha-1-certificaten te omzeilen.

Op zijn blog maakt Mozilla de ten opzichte van de certificaatautoriteiten genomen maatregelen bekend. Zo trekt de organisatie het vertrouwen in voor certificaten van WoSign en StartCom met een geldigheid na 21 oktober. Als Mozilla nogmaals rootcertificaten met antedatering tegenkomt, kondigt het aan deze 'onmiddellijk en permanent' te blokkeren. Deze verandering is onderdeel van de release van Firefox 51.

Daarnaast voegt het certificaten met een aangepaste datum toe aan OneCRL. Dit in 2015 geïntroduceerde systeem zorgt ervoor dat certificaten sneller teruggetrokken kunnen worden door lijsten met dergelijke certificaten naar de browser te pushen. Mozilla kondigt verder aan geen audits meer te accepteren die zijn uitgevoerd door Ernst & Young Hong Kong, waarvan de autoriteiten klant waren. In de lijst met vastgestelde problemen komt naar voren dat de misstanden bij de certificaatautoriteiten 'vastgesteld hadden moeten worden door een bekwame partij'.

Mozilla voegt daaraan toe dat tot het moment dat de certificaatautoriteiten met nieuwe rootcertificaten komen, de certificaten handmatig geïmporteerd moeten worden. De organisatie heeft de nu genomen maatregelen eerder al aangekondigd. Naast het feit dat de datum op bepaalde certificaten was aangepast, was het bijvoorbeeld mogelijk om een certificaat voor een ander domein aan te vragen. Bovendien nam WoSign de autoriteit StartCom over zonder dit te melden.

Naar aanleiding van de bekendmaking van de misstanden door Mozilla kondigden de certificaatautoriteiten maatregelen aan, waaronder een reorganisatie.

Reacties (70)

StartSSL / StartCom heeft nu een boodschap geplaatst als je inlogt:

Mozilla decided to distrust all StartCom root certificates as of 21st of October, this situation will have an impact in the upcoming release of Firefox in January. StartCom will provide an interim solution soon and will replace all the issued certificates from that date in case of requested. Meanwhile StartCom is updating all their systems and will generate new root CAs as requested by Mozilla.

Zo trekt de organisatie het vertrouwen in voor certificaten van WoSign en StartCom met een geldigheid na 21 oktober. Als Mozilla nogmaals rootcertificaten met antedatering tegenkomt, kondigt het aan deze 'onmiddellijk en permanent' te blokkeren. Deze verandering is onderdeel van de release van Firefox 51.

en

StartCom will provide an interim solution soon and will replace all the issued certificates from that date in case of requested.

Kan iemand mij uitleggen waarom Firefox (dev edition in mijn geval) 51.0a2 (2016-10-23) het certificaat van bijvoorbeeld startssl.com dan nog wel vertrouwt?

https://i.imgsafe.org/f1708b03b3.png

edit:
Een geldigheid "na 21 oktober" is dus "afgiftedatum na 21 oktober". Mag Tweakers wel aanpassen in de berichtgeving.

[Reactie gewijzigd door McOrmick op 25 oktober 2016 11:23]

Het gaat om nieuwe certificaten, niet om al verstrekte. Anders hebben de klanten last van het spel dat de twee certificaten boeren speelden, dus laat Mozilla alle certificaten voor datum van ingang vonnis met rust.

Goed dat Firefox doorbijt en dat een CA moet bloeden omdat ze laks zijn omgegaan met de veiligheid. Met de honderden zo niet duizenden CA's die we tegenwoordig hebben moeten er wel een paar rotte appels bij zitten. Het CA systeem kan niet tegen rotte appels, een enkele rotte appel maakt het hele systeem volledig onbetrouwbaar. Die moeten er dus zo snel mogelijk uit.

StartCom will provide an interim solution soon and will replace all the issued certificates from that date in case of requested.

De vraag is waar ze die certs mee gaan vervangen. Ik denk dat ze bij een concurrent moeten aankloppen en heel lief vragen om hun klanten over te nemen. Die concurrenten zullen echter wel extreem achterdochtig zijn, die weten ook dat WoSign/Startcom z'n werk niet goed heeft gedaan, en zullen bang zijn om zichzelf te besmetten met slechte klanten. Al die klanten moeten dus opnieuw gekeurd worden. Per klant is dat niet zo veel werk maar alles bij elkaar loopt het flink op.

Vervelend is alleen wel dat voor de consument nu een mooie gratis optie verdwijnt. Want StartSSL had mooie gratis certs met 1 jaar levensduur.

Letsencrypt is voor mij geen optie (hier meer toelichting) dus dat is wel jammer. Gelukkig had ik ze net vernieuwd en ik hoop dat dit gedoe met een jaar wel weer is opgelost.

[Reactie gewijzigd door GekkePrutser op 25 oktober 2016 18:48]

Klinkt ok, alhoewel het moeilijk is om een objectief oordeel te vormen (weet je nu alles?).
Is het daarnaast niet vreemd dat dit een actie is / lijkt van alleen Mozilla?
De discussie loopt al langer, zie bijv.: https://sslmate.com/blog/post/history_of_ca_sanctions
Ik heb na een korte zoekactie nog geen chrome of microsoft 'actie' kunnen vinden...
Zou het niet beter zijn als de verschillende browsers één lijn trekken voor certificaat 'problemen'?

Klinkt ok, alhoewel het moeilijk is om een objectief oordeel te vormen (weet je nu alles?).
Is het daarnaast niet vreemd dat dit een actie is / lijkt van alleen Mozilla?
De discussie loopt al langer, zie bijv.: https://sslmate.com/blog/post/history_of_ca_sanctions
Ik heb na een korte zoekactie nog geen chrome of microsoft 'actie' kunnen vinden...
Zou het niet beter zijn als de verschillende browsers één lijn trekken voor certificaat 'problemen'?

Het houdt niet op bij browsers, ieder OS heet z'n eigen set certificaten en sommige grote applicaties (zoals die webbrowsers) ook, er zijn dus honderden partijen die mee zouden moeten praten, dat maakt het wat lastiger. Daarbij gaan ook nog allerlei politiek belangen spelen. Als een Amerikaan voorstelt om de Russische Staats CA niet langer te erkennen zijn de poppen aan het dansen.
Niettemin is er wel wat voor te zeggen dat de grootste van die partijen maar samen moeten werken maar eigenlijk vind ik dat het hele CA-systeem op de schop moet. Wat mij betreft worden alle DV-certificaten vervangen door self-signed certs met DANE. Dat is 99% (?) van de markt die dan onafhankelijk is en geen CA of browser meer nodig heeft om te bepalen welke certificaten te vertrouwen zijn.

Het stukje dat overblijft is veel kleiner en beter te overzien en heeft relatief veel geld beschikbaar (de marges op DV zijn zo klein dat je daar geen goede controle voor kan doen). Het toezicht en de controle op die kleine groep kan dan veel intensiever zijn.

Ik denk dat het dan niet meer nodig dat iedere browser honderden CA's erkent. De meeste van die CA's richten zich op een niche (bv de overheid of het leger van een bepaald land) waar 99% van de wereld nooit mee te maken heeft, afgezien van een incidenteel bezoek aan de website van de ambassade ofzo. Dat soort gebruik kun je prima afhandelen via DANE. Wie speciale behoeftes heeft (overheid enzo) die installeert zo'n extra CA direct op z'n PC voor, de rest van de wereld doet het met DANE.


Ik besef dat de wereld groter is dan internet en DV. Voor sommige toepassingen blijven we CA's nodig hebben, maar we kunnen het probleem een stuk overzichtelijker en goedkoper maken.

Voor wie nog niet weet wat DANE is (zoals ik tot 1 minuut geleden): http://www.internetsociet...n-next-level-using-dnssec

En voor een ieder die geen idee heeft, DV zoals genoemd door CAPSLOCK2000 staat voor Domein Validatie. Dit is de simpelste (en goedkoopste) vorm van een SSL waarbij je dmv een email of bijvoorbeeld een DNS record aantoont dat het domein onder je controle valt.

Wie speciale behoeftes heeft (overheid enzo) die installeert zo'n extra CA direct op z'n PC voor, de rest van de wereld doet het met DANE.

Probleem is ecter dat de lead security van Google/Chrome heeft aangegeven weinig te zien in DANE. Zijn argumenten zijn de bekende oude koek van 'het is niet perfect genoeg' die hij ook al betreft certifciaat revocation gaf.

Om die reden zie ik DANE ook niet snel omvang krijgen. En dat is jammer inderdaad ...

Om die reden heeft Google ook bij de HPKP standaard geen methode voor revocation ingevoerd. Dat zou veel problemen oplossen. Dat had je mooi via DANE kunnen oplossen, maar Google was 'tegen'.

Ik ben het eens met de argumenten dat DANE niet handig is voor revocatie, maar ik ken niemand die het daar voor wil gebruiken, dus dat vind ik een beetje een stroman-argument.

DANE is handig om certificaten te controleren zonder CA. Daar heeft hij drie argumenten tegen die alle drie niet zo best zijn.

Ten eerste was de implementatie in Chrome slecht. Schrijf dan betere code! Dat mag geen argument tegen DAN in het algemeen zijn.

Ten tweede zou DNSSEC afhankelijk van RSA-1024, dat is niet meer waar. In theorie is het nooit waar geweest, alle encryptie in DNSSEC is modulair en vervangbaar, RSA-1024 kan eenvoudig vervangen worden door iets anders. In praktijk was het jarenlang wel waar omdat de root-key inderdaad RSA-1024 gebruikte. Dat is een paar weken geleden echter veranderd, de root gebruikt nu RSA-2048. Niet alleen heeft dat het probleem opgelost maar ook is bewezen dat we die encryptie kunnen vervangen door iets beters als het nodig is. Op andere punten wordt nog steeds veel RSA-1024 gebruikt maar alleen voor data die maar kort geldig is. Dat is een bewuste keuze, doordat de sleutels maar kort geldig zijn heeft een aanvaller niet de tijd om er eentje te kraken voor de sleutel vervangen wordt. Ooit moet het daar ook vervangen worden maar het is nu nog geen probleem.

Ten derde combineert DANE niet handig met Certificate-Transparency. Dat is jammer maar CT is een lapmiddel voor de gebreken van het CA-systeem, ik kan dat moeilijk als bezwaar tegen DANE zien. We verliezen inderdaad een paar mooie voordelen van CT maar ik hoop dat we daar een oplossing kunnen vinden zonder heel DANE weg te gooien.

Google heeft nauwe banden met Mozilla, zie HN, beslist uiteindelijk zelf.

Apple products will no longer trust the WoSign CA Free SSL Certificate G2 intermediate CA.

Waarom gebruikt Mozilla niet de certificate store van het OS? Certificates zijn toch 1 van de zaken die je just gecentraliseerd wil hebben op je systeem zodat je in geval van een probleem zoals bij Diginotar en dergelijke maar op 1 plek iets hoeft aan te passen. Als iedere applicatie zijn eigen store gebruik dan sluipt er vroeger of later 1 door en ben je kwetsbaar.

Waarom zou je 1 partij willen die bepaald wie je gaat vertrouwen of niet? Ik vind het net positief dat Mozilla niet zomaar alles van het OS over neemt maar ze hun eigen koers kunnen varen. Want als iedereen van 1 centraal systeem gebruik wenst te maken dan gaat men uiteindelijk ook inspraak willen. Dan moeten er nieuwe manieren gevonden worden om dat te gaan aansturen wat weer vertraging met zich mee zal brengen.

Nee, geef mij maar een decentraal beheeer waarbij de softwaremaker zelf de mogelijkheid heeft om in te grijpen, maar ook zelf in staat voor eventuele negatieve gevolgen.

Je kan perfect zelf je certificaten toevoegen aan de OS aangeboden faciliteit. Ik heb namelijk geen zin dat voor elke applicatie apart te doen.

Het is (imo) een tendens van applicatie ontwikkelaars schijt te hebben aan al beschikbare OS faciliteiten. Ik vermoed egos en wielen laten draaien. In FF zijn geval zal het lui/laks zijn vanwege multiplatform en de opportuniteit tot 'macht' (zie chrome en hun _manuele_ white-list, alsof we in pure '70s stijl host file updates uitwisselen).

[Reactie gewijzigd door analog_ op 25 oktober 2016 15:25]

Ondanks de valide redenen van Mozilla is het eng dat zo'n "stichting" zoveel macht heeft.

Van de andere kant; Op zo'n manier worden veel CA's doodgemaakt waardoor er maar een beperkt clubje overblijft. Ook niet wenselijk.

Mozilla heeft niet veel macht. Zij zien problemen en pakken deze aan. Jij hebt als eindgebruiker de keuze of je gebruik maakt van de software van Mozilla (en dus vertrouwt op hun oordeel) of dat je andere software gebruikt.

Heb je dan liever dat CAs niet gecontroleerd worden? Of dat de beslissing moet genomen worden in 1 of ander overleg orgaan waar diezelfde CAs gaan proberen invloed op uit te oefenen en waar het maandan kan duren voordat men een beslissing neemt?

Deze CAs hebben fouten gemaakt. Zware fouten. Het antidateren van een SSL certificaat is not done ... . Het heeft er o.a. voor gezorgd dat de lichtere straffen die men zou kunnen toepassen nu ook niet meer betrouwbaar zijn (bijv. door enkel certificaten te vertrouwen uitgegeven voor een bepaalde datum). Net door dat geknoei neemt Mozilla nu drastische maatregelen.

Je ziet toch zelf wel in dat Mozilla keuzes maakt wat betreft security waarmee mogelijk niet iedereen het eens is, zoals de gedupeerde klanten die voor hun cetjes betaald hebben en nu weer met extra werk opgezadeld zitten.

De cru vh verhaal is ook enkel dat sha1 idd niet recommended meer is tbhv cryptografie (in nieuw te ontwerpen systemen of als je nu iets in gebruik neemt, zie vrijwel elke richtlijn van
landelijke cryptografishe instituten; nist, de europese, franse, duitse en japanse clubjes wiens namen mij nu ontgaan) maar als methode is het nog altijd niet inherent onveilig.

De meerderheid vd certificaten maakt er nog gebruik van en sommige embedded systemen hebben geen ondersteuning of performantie om meer te doen.

(overdreven) Waar komt dan Mozillas arrogantie vandaan om de keuze voor ons te stellen dat dit wel onveilig is.

[Reactie gewijzigd door analog_ op 25 oktober 2016 15:24]

Mozilla zit in het CA/Browser Forum waar er afspraken worden gemaakt die door WoSign/Startcom zijn geschonden. Dat je dan op je donder krijgt lijkt me zelfs als je overdrijft weinig arrogants aan.

"Je ziet toch zelf wel in dat Mozilla keuzes maakt wat betreft security waarmee mogelijk niet iedereen het eens"

Ik geloof dat je de rol van een CA niet snapt. Het is lullig voor de klanten van de CA, maar dat maakt het niet minder belangrijk dat whoever-the-fuck een CA is zich nou eenmaal dient te houden aan bepaalde regels om niet het gehele systeem onbetrouwbaar te maken. Denk dan in de strekking "You had ONE job...", als iemand een taak heeft en die niet goed vervult verdient hij de taak vanzelfsprekend niet, zeker niet in deze situatie waar CAs CAs zouden moeten zijn vanwege hen capabiliteit CA te zijn. Al had je 50% van de certificaten vd wereld in handen, geldt dat onverminderd, al dan niet des-te-meer.

[Reactie gewijzigd door Annihlator op 25 oktober 2016 17:13]

Op cryptografische gebied is dat administratief geneuzel. Cas zijn arbitraire instanties die we toevallig vertrouwen verstrekken.

In principe is er maar 1 CA nodig voor het hele systeem. Beter 1 goede dan 300 met het risico dat het vertrouwen weg is. Economisch is dat niet wenselijk, maar voor de certificate is het niet slecht.

Ik zie het beetje zoals met chirurgen. Je behaald een diploma en je krijgt het recht en het vertrouwen om in mensen te snijden. Als je veel fouten begint te maken (en dat ook nog eens opzettelijk probeerd te verbergen) dan raak je je licentie kwijt. Je zegt dan toch ook niet: "maar dan worden de wachtlijsten langer, laat hem maar doorgaan"?

Zolang duidelijk, openbaar en met bewijs een CA wordt gewijgerd, dan weegt dat, wat mij betreft, makkelijk op tegen een klein economisch risico.

Van de andere kant; Op zo'n manier worden veel CA's doodgemaakt waardoor er maar een beperkt clubje overblijft. Ook niet wenselijk.

Het is wenselijk dat er CA's zijn die sjoemelen? Daar verschilen we dan toch echt van mening. Het is prima dat deze firma's de klep op de neus krijgen.

mmmmm.... dat is toch startssl.com dat startcom?! dat was wel een makkelijke site en daar heb ik voor m'n thuis servertje net m'n certificate gisteren opnieuw aangemaakt.
Iemand ervaringen met andere gratis SSL sites?



Dank voor de letsencrypt verwijzingen allen, tsja om de 3 jaar verloopt zoiets en in de tussentijd kijk je er niet naar. Dus onder een steen gelegen klopt wel op dit vlak

[Reactie gewijzigd door SKay op 25 oktober 2016 09:01]

Hebt ge onder een steen gelegen?
https://letsencrypt.org
Zijn zelfs netjes scriptjes om automagisch je cert te vernieuwen als 't daar tijd voor is.

LE werkt heel mooi zolang je het proces geautomatiseerd kunt laten verlopen. Helaas word ik op m'n werk geconfronteerd met verschillende toepassingen waarbij het niet te automatiseren is en dan is de bruikbaarheid van LE ineens dicht bij 0.

Getting started zegt het in feite zelf al:

We don’t recommend this option because it is time-consuming and you will need to repeat it several times per year as your certificate expires.

En dan dit...

For most people it is better to request Let’s Encrypt support from your hosting provider, or switch providers if they do not plan to implement it.

Helaas ligt het "even switchen" van provider lang niet altijd zo eenvoudig als hier wordt voorgespiegeld.

LE is prima bruikbaar als je zelf de controle over de server hebt. Heb je dat niet dan kun je altijd nog het certificateonly deel gebruiken maar dat werkt uiteraard niet zo mooi als een cronjob op je server die elke 89 dagen een nieuw certificaat ophaalt.

Als je iets dynamisch met de DNS van de domeinen kunt doen, dan is dat ook een optie. Als je DNS partij een API heeft waarmee records gewijzigd kunnen worden, dan zijn er plugins voor LetsEncrypt die validatie via die weg mogelijk maken. Ik gebruik dit o.a. voor een aantal van onze domeinen die op CloudFlare staan.

Je zult uiteraard nog steeds de certificaten moeten installeren, maar het vernieuwen kan gewoon automatisch blijven lopen.

In mijn geval heb ik één machine verantwoordelijk gemaakt voor het periodiek vervangen van de certificaten. Deze worden vervolgens via Puppet automatisch naar de juiste machines doorgezet. Werkt als een zonnetje. Betekent overigens wel dat die ene machine goed beveiligd moet worden, want daar staan al je private keys ook op.

Mva, valt mee. M'n vpn server bijvoorbeeld gebruikt wel SSL certificaten, en die laat ik via letsencrypt lopen. Enige wat ik dan moet doen is bijv. een eigen webroot opgeven voor de authenticatie, en --certonly erbij zodat alleen het certificaat wordt vernieuwd en verder niks. Je nieuwe certificaten staan dan in /etc/letsencrypt/live/<hostnaam>/ en die kan je dan weer via cron ofzo door deployen naar waar het nodig is

Als niet wil dat een of andere vreemd script aan je webserver configuratie zit kan je het ook handmatig doen. Met een python script een daarna zelfde de certificaten op de juiste locatie plaatsen.

https://github.com/veeti/manuale

Ook met de certbot hoef je niet per se de configuratie (automatisch) aan te laten passen, er zit namelijk ook een certonly optie in de certbot, zie deze blog (kopje The Webroot Plugin), met een mooi voorbeeld, op basis van webroots.

[Reactie gewijzigd door CH4OS op 25 oktober 2016 10:14]

Via een Synology NAS kun je gewoon met een paar klikken een nieuwe LE certificaat aanmaken/vernieuwen en direct inschakelen. Ideaal.

Een NAS ga je toch niet direct aan het internet open zetten? Dat zet je toch achter een VPN?!

Waar lees jij dat ik die nas open heb gezet? Ik heb alleen gezegd dat je zo een LE certificaat kan importeren op een NAS.

Fun fact: op die NAS draait ook een VPN

My bad, ik ging er van uit dat het over een SSL certificaat voor HTTPS ging.

Waar lees jij dat ik die nas open heb gezet? Ik heb alleen gezegd dat je zo een LE certificaat kan importeren op een NAS.

Fun fact: op die NAS draait ook een VPN

Je zegt zelf: met een paar klikken een nieuwe LE certificaat aanmaken.
Je zal in ieder geval poort 80 open moeten zetten richting je NAS, anders werkt Let's Encrypt niet op je Synology.

[Reactie gewijzigd door ASS-Ware op 25 oktober 2016 14:18]

Ik heb ze wel open gehad ja. Dus dat klopt. Maar na het aanmaken weer dicht gegooid.

Ik heb ze wel open gehad ja. Dus dat klopt. Maar na het aanmaken weer dicht gegooid.

Dan vernieuwt het systeem ze niet automatisch en dat is nou juist het mooie van LE.

https://www.synology.com/...er/connection_certificate


Note:

You can only register for certificates from Let's Encrypt with a limited number of email accounts. If the limit is exceeded, use an email account previously registered to get more certificates.
You can only register for a limited number of certificates per domain from Let's Encrypt. If the limit is exceeded, enter the current domain name as the Subject Alternative Name (SAN) and use another domain name for certificate request.
Let's Encrypt will perform domain validation before issuing certificates for your domains. Please make sure your Synology NAS and router have port 80 open for domain validation from the Internet. All the other communications with Let's Encrypt go over HTTPS and will keep your Synology NAS secure.
Certificates issued by Let's Encrypt are valid for 90 days. Before the certificates expire, DSM will automatically renew such certificates after successful domain validation. Please make sure your Synology NAS and router have port 80 open for certificate renewal.

[Reactie gewijzigd door ASS-Ware op 25 oktober 2016 14:32]

Gaaf, dan heb je nu dus een handmatig kunstje wat je 1x per 90 dagen mag herhalen.

Juist voor Nas'en is letsencypt niet echt toepasbaar.

Dat kost ook heel veel moeite... Paar klikken en kan weer verder.
Bij LE verlopen certificaten altijd na drie maanden al, dus had sowieso gemoeten.

Daar naast is het prima voor een NAS. Als je nou een drukbezochte website was, dan *kan* een betaald certificaat beter zijn.

[Reactie gewijzigd door krakendmodem op 26 oktober 2016 08:51]

Op bijv. een Synology kun je ook 2-factor authentication aanzetten om de boel wat meer dicht te timmeren. Maakt het al iets veiliger. Maar ik ben het met je eens, bij mij zitten dat soort zaken achter een VPN inderdaad.

Let's Encrypt? Zie green reden waarom je dat niet zou willen gebruiken (behalve wildcard certs, daarom is tweakblogs niet op LE)

Letsencrypt is niet handig in sommige gevallen. Bijvoorbeeld heb ik mijn webservers altijd zonder enige internet toegang draaien (dus alleen inkomend met een externe firewall en ook draaien ze in een echte DMZ op een lokaal IP). Dan kunnen ze nooit gebruikt worden om spam te verspreiden bijvoorbeeld. Dan is het automatisch vernieuwen van die certs niet mogelijk.

En op mijn mailservers die natuurlijk wel uitgaand verkeer hebben, heb ik weer geen webservers draaien die nodig zijn voor de automatische validatie.

Ik zou letsencrypt wel gebruiken als je handmatig gewoon certs van een jaar kreeg, maar elke 3 maanden al dat gedoe van handmatig vernieuwen is veel te veel gedoe.

Je zou DNS-validatie kunnen overwegen, zo doe ik het.
Ik heb ook systemen die niet via internet bereikbaar zijn en/of geen webserver draaien. Daarom gebruik ik DNS-validatie, in plaats van de validatie-code op je webserver te zetten laat ik het in DNS zetten. Het nadeel daarvan is dat je dan wel (geautomatiseerd) toegang tot je DNS nodig hebt. Dat is in mijn geval geen probleem omdat ik mijn certificaten centraal beheer via Puppet en m'n DNS ook door Puppet wordt beheerd.

Ik ben heel benieuwd hoe je DNS en certificaten via Puppet beheert. Met certificaten doe ik dat al met een zelf geschreven module. Wat gebruik jij en hoe doe je DNS?

Ten eerste gebruik ik getssl om de certificaten aan te maken en met LetsEncrypt te communiceren.
Getssl roept een klein scriptje aan dat de juiste DNS zone-file aanpast en dat wordt vervolgens door Puppet naar de DNS-servers gepushed.
Als een client om een certificaat vraagt dan kijkt Puppet of er al een certificaat is en roept anders getssl aan om er eentje te produceren.

Wat DNS betreft moet ik je teleurstellen, dat is allemaal vrij saai, het zijn vooral statische files die ik met de hand beheer (Puppet/caspar stuurt ze wel naar de servers) en een paar kleine scriptjes die info vanuit diverse bronnen (zoals getssl).

Ik gebruik ook dns validatie, maar dan in combinatie met de APi van transip. Dat werkt uitstekend.

Al is riviaal zijn om voor elke subdomein een cert aan te maken, al mag je er maar 2000 per week doen. Misschien is een wildcard dan toch makkelijker idd.
https://letsencrypt.org/docs/rate-limits/

letsencrypt...

https://letsencrypt.org/

Deze werkt wel prettig, en lijkt ook wel veel gebruikt te worden voor prive servertjes etc.

_{ik moet sneller typen zie ik al}

[Reactie gewijzigd door TheKmork op 25 oktober 2016 08:52]

Volkomen terecht, natuurlijk. De trusted authorities zijn de basis van het hele certificate systeem; als je toestaat dat ze maar raak signen dan sla je die basis weg en blijft er geen enkele trust meer over.

Ik meen ergens gelezen te hebben dat deze bedrijven in Chinese handen zijn. Gegeven de torenhoge corruptie in dat land verbaasd dit me niets, en feitelijk zou ik geen enkel Chinese CA willen vertrouwen...

Wat doen de andere brouwsers-bouwers eigenlijk met deze certificaten? Over Mozilla lees ik de nieuws-items, de rest wordt niet genoemd.

Dat lijkt me nog het ergste, ik ken de getallen niet, maar volgens mij is Mozilla niet de grootste, zelf ben ik een Chrome gebruiker, en ik zou toch verwachten dat Google (Alphabet) ook startcom/wosign niet vertrouwd !

Chrome gebruikt op Windows de Microsoft store die in het OS ingebouwd zit. Nu zal Chrome zelf best een uitzondering kunnen pushen in hun code, maar de vraag is of ze dat doen. Ze gebruiken niet voor niets een bestaand systeem. Als je daar al te veel zelf aan gaat rommelen, kun je net zo goed overstappen op een eigen store, zoals Firefox doet. Dan weten mensen in ieder geval waar ze aan toe zijn.

Volgens mij stond er in het vorige bericht hierover dat andere grote browsers het voorbeeld van Mozila hierin volgen, of zelf onderzoek gingen uitvoeren.

Ik zou geen bezwaar hebben tegen enkele extra schandaaltjes van dit formaat. Krijgen we misschien eindelijk eens wat tractie op DANE/TLSA dat SSL certificaten zonder CA mogelijk maakt. Heel dat systeem is zo slecht als maar zijn kan. Anderen gaan bepalen wie je wel of niet kan vertrouwen en als je zelf een beveiligde verbinding wil opzetten kan je gaan betalen. En wanneer je iets meer wenst dan het eenvoudige slotje betaal je er grof geld voor.

Ik help je het hopen, al zal ik er zelf voorlopig weinig profijt van hebben. Heb een .it domein en die spaghetti-eters hebben nog steeds geen werkende DNSSEC implementatie voor het .it domein (en tevens is het volstrekt onduidelijk of en wanneer ze daar eens klaar mee denken te gaan zijn).

Een overkoepelende controlerende organisatie is sowieso een risico, ongeacht welke technologieen er worden toegepast. Dat werd volgens mij ook van meerdere kanten geroepen toen ze met die certificaten begonnen. De consequenties ervan beginnen langzaam te komen. Ik verwacht dat het hele gecentraliseerde gedoe met certificaten met een paar jaar wel kapot is. Een organisatie in vertrouwen nemen voor veiligheid die niet eens aantoonbaar is lijkt me niet erg zinvol.

Ik meen ergens gelezen te hebben dat deze bedrijven in Chinese handen zijn.

Klopt, StartSSL was Israelisch, maar overgenomen door WoSign hetgeen Chinees is. Eén van de overtedingen was om deze overname niet te melden hetgeen verplicht is als CA. Dit is relevant omdat het process van aanmaken van certificaten daarna ook door de Chinese moedertak werd overgemomen en het oude vertrouwde bedrijf in feitre niet meer dan een merknaam was. Dat laatste wordt nu in ieder geval terugedraaid.

Iemand ervaring met Let's Encrypt en IIS op Windows? Het enige dat ik kan vinden is dat het blijkbaar enorm lastig is...

Dat zegt al iets over de haalbaarheid van je doel met de middelen die je wilt gebruiken

Installeer een overbekende linux distro met Apache of NGINX. Daar zijn genoeg tuto's voor.

Het is voor een Exchange server die ik thuis draai. En nee die ga ik niet ombouwen naar een Open Source oplossing. Ik werk in het dagelijks leven ook alleen met MS omgevingen.

Met de juiste tools kan je zo een certificaat importeren in IIS. Hoef je niet perse een CSR voor te hebben gemaakt in IIS (al maakt dat het importeren wel weer makkelijker).

Als je een CSR kan gebruiken met LetsEncrypt, dan zit je gebakken. Moet je maar even uitzoeken hoe/wie/wat/waar/wanneer.

Kennis van SSL is dan wel handig, wellicht kan dit je wat op weg helpen. Lastig zal het in ieder geval niet zijn, wel wat omslachtiger.

https://www.sslshopper.co...mon-openssl-commands.html

Volgens dit artikel is LetsEncrypt-Win-Simple vrij eenvoudig. Zie artikel voor een demo. Ik heb zelf geen ervaring op Windows.

Quote uit het OneCRL documnet van Mozilla

OCSP stapling can remove the need for live revocation checks, but currently, only only around 9% of TLS connections use it.

Quote Wikipedia over OCSP

OCSP checking creates a privacy concern for some users, since it requires the client to contact a third party (albeit a party trusted by the client software vendor) to confirm certificate validity. OCSP stapling is a way to verify validity without disclosing browsing behavior to the CA

Had altijd al een gevoel dat er privacy factor aan beveiligde verbinding zat. Jammer genoeg wordt men gedachten bevestigd. 81% van de checks gaat langs de CA's. Niet echt een privacy vriendelijk gevoel. OneCRL zou al een hele verbetering zijn boven OCSP op het gebied van privacy.

Had altijd al een gevoel dat er privacy factor aan beveiligde verbinding zat. Jammer genoeg wordt men gedachten bevestigd. 81% van de checks gaat langs de CA's. Niet echt een privacy vriendelijk gevoel. OneCRL zou al een hele verbetering zijn boven OCSP op het gebied van privacy.

Je leest het verkeerd of ik interpreteer jouw verkeerd...

In de praktijk vinden revocation checks op clients nu zo goed als niet plaats. Bijv op Windows gebeurt het standaard niet en bij een revocation wordt die gewoon door MS in een windows update gestopt.
Oftewel er zijn momenteel zo goed als 0 checks, dat er dan 81% van die 0 checks langs de CA's gaat is niet relevant.

Men wil het live gaan checken, maar dan krijg je dus OCSP stapling etc wat enkele bezwaren van de 1e draft weghaalt. Oftewel er gaat nooit 81% live gechecked worden bij CA's

Als er maar 9% OCSP stapling gebruikt blijft er 91% (geen 81% mijn fout) over die via OCSP bij de CA gecheckt gaat worden lijkt mij.
Wat jij beschrijft klinkt als of ze bijna het zelfde doen via Windows updates als bij Mozilla bij OneCRL. Gebruikt Firefox de certificaten van Windows?

Heb je er toevallig ook een link naar die informatie lijkt me interessant om te lezen

Is dat de reden dat pixabay niet neer opent in firefox?

Pixabay heeft hier een CloudFlare certificaat dat is uitgegeven door Comodo.

edit:
Dus, of ze hebben het gefixed door (tijdelijk) de DNS via Cloudflare te laten lopen, of dat is niet de reden dat het bij jou niet werkt.

[Reactie gewijzigd door McOrmick op 25 oktober 2016 10:18]

De eerste die hier last van heeft is LibreOffice, want ik krijg nu een waarschuwing in Firefox dat de verbinding niet secure is. Als ik naar het certificate kijkt dan blijkt deze van StartCom te zijn.