Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 69 reacties
Submitter: c337n

GlobalSign had donderdag problemen met het Online Certificate Status Protocol. Hierdoor toonden browsers onterecht waarschuwingen bij veel sites wereldwijd dat certificaten die zijn uitgegeven door GlobalSign ingetrokken zijn.

GlobalSign waarschuwde donderdagmiddag dat er problemen waren met het OCSP. Enkele uren later gaf de certificaatautoriteit aan dat de problemen verholpen waren, maar ook hierna werden veel certificaten van klanten van het bedrijf als revoked beschouwd.

Dat komt omdat besturingssystemen de Certificate Revocation Lists in de cache bewaren om met behulp van deze lijsten snel te kunnen verifiëren of certificaten ingetrokken zijn of niet. GlobalSign geeft naar aanleiding van de problemen uitleg hoe Windows- en macOS-gebruikers de cache van OCSP en CRL kunnen legen zodat nieuwe lijsten opgehaald worden.

Niet voor iedereen werkt het legen van de cache en bij de laatste update stelt GlobalSign nog aan een oplossing te werken. Dat certificaten van websites en webwinkels als ingetrokken gedetecteerd worden kan grote impact hebben op website en webwinkels. Browsers geven internetters waarschuwingen dat het certificaat ongeldig is en dat het onverstandig is de website te bezoeken.

GlobalSign is in 1996 in België opgericht en levert certificaten voor duizenden grote en kleinere sites wereldwijd.

Update, 19.30: GlobalSign heeft een update geplaatst. De oorzaak lag bij het intrekken van een cross-certificate die twee roots met elkaar verbond: sommige browser dachten dat de cross-signed root intermediates had ingetrokken, wat niet het geval was. Het probleem is opgelost en nieuwe opvragingen van de certificaten zouden zonder problemen moeten verlopen maar bij internetters die hun cache niet legen zullen de waarschuwingen pas na vier dagen verdwijnen. GlobalSign wil klanten een alternatief via een certificaatautoriteit van een andere root aanbieden.

Update 2, vrijdag 14.30: GlobalSign heeft een nieuwe update geplaatste met de mogelijkheid voor klanten om hun certificaat te vervangen door een alternatieve intermediate-certificaat. Op zijn site publiceert het bedrijf onder andere die alternatieven voor Alpha SSL, Domain SSL en Cloud SSL. Klanten met Extended SSL zouden geen actie hoeven ondernemen. Klanten hoeven met de vervanging geen nieuwe certificaten aan te vragen om de problemen op te lossen.

GlobalSign probleem 13 oktober 2016 Safari SoundCloudGlobalSign probleem 13 oktober 2016 Safari SoundCloud

Moderatie-faq Wijzig weergave

Reacties (69)

Officiele communicatie van GlobalSign via GlobalSign's status pagina

Dear Valued GlobalSign Customer,

As most of you are aware, we are experiencing an internal process issue (details below) that is impacting your business. While we have identified the root-cause, we deeply apologize for the problems this is causing you and wanted to ensure you that we are actively resolving the issue.

GlobalSign manages several root certificates and for compatibility and browser ubiquity reasons provides several cross-certificates between those roots to maximize the effectiveness across a variety of platforms. As part of a planned exercise to remove some of those links, a cross-certificate linking two roots together was revoked. CRL responses had been operational for 1 week, however an unexpected consequence of providing OCSP responses became apparent this morning, in that some browsers incorrectly inferred that the cross-signed root had revoked intermediates, which was not the case.

GlobalSign has since removed the cross-certificate from the OCSP database and cleared all caches. However, the global nature of CDNs and effectiveness of caching continued to push some of those responses out as far as end users. End users cannot always easily clear their caches, either through lack of knowledge or lack of permission. New users (visitors) are not affected as they will now receive good responses.

The problem will correct itself in 4 days as the cached responses expire, which we know is not ideal. However, in the meantime, GlobalSign will be providing an alternative issuing CA for customers to use instead, issued by a different root which was not affected by the cross that was revoked, but offering the same ubiquity and does not require to reissue the certificate itself.

We are currently working on the detailed instructions to help you resolve the issue and will communicate those instruction to you shortly.

Thank you for your patience.

Lila Kee
Chief Product Officer
GMO GlobalSign

US +1 603-570-7060 | UK +44 1622 766 766 | EU +32 16 89 1900
www.globalsign.com/en
Update: Het vervangen het intermediate root certificate heeft een onmiddelijk effect. Op de volgende pagina staat beschreven hoe je het intermediate certificate kan vervangen. Dat scheelt je weer aanvragen van een nieuw certiticate

https://support.globalsig...s---troubleshooting-guide
Grappig, helemaal geen één melding hiervan tegen gekomen (chrome). Toevallig specifieke niché die hier gebruik van maakt? Zelf gebruikte ik altijd comodo, en nu lets encrypt
Het was ook browser afhankelijk, viel mij op dat vooral Microsoft last had hiervan.
Toen we aan het troubleshooten waren kregen we op internet explorer/edge een error maar op firefox en chrome was er geen probleem (op dezelfde cliënt)

Idem dito met telefoons, alle Windows phones van het bedrijf gaven een certificaat error, de Androids niet. Soms kreeg je een optie om alsnog door te gaan maar dan werd de pagina met certificaat error opnieuw geladen, de rest kreeg enkel de optie op de pagina te sluiten.

Nog altijd geen idee hoe dit kwam (dat voor Microsoft producten last hadden) maar na nog meldingen van gebruikers met hetzelfde probleem op sites die niet van ons waren hebben we het twitter bericht van GlobalSign gevonden.
Mochten wel een boodschap plaatsen op hun portaal, daar zijn we namelijk eerst gaan kijken om te kijken of we toevallig vergeten waren het certificaat te vernieuwen.
Microsoft platforms zijn het beste in certificaat revication controle. Zij ondersteunen als enige alle 3 de officiele methoden plus hebben als bonus hun eigen Windows revocation lijst. Bovendien controleren zij als enige platform altijd. Opera is de enige andere die ook zoiets doet.

Dus die falen als eerste. Zij testen namelijk real-time met een kleine interne cache op OS niveau.

Android controleert geheel niets, al kunen individuele apps soms wel checken. Firefox heeft enkel een CRL en die wordt enkel om de X tijd gedownload. Chrome test geheel niets, behalve EV-certificaten want dan moet het van de standaard en doen ze het met grote tegenzin. Chrome heeft wel een eigen mini-lijst om de grootste gevaren tegen te gaan. Denk aan diginotar of zo.
Wij kregen vanuit meerdere richtingen en meerdere klanten klachten dat verscheidene websites niet meer werkte.
Na een uitgebreid onderzoek bleek dat de Certificate revocation list de veroorzaker was. Zelfs het opschonen van de locale cache had in dit geval geen zin binnen de windows omgeving.
Via Firefox en Chrome waren de websites wel te benaderen en volgens SSL Labs (https://www.ssllabs.com/ssltest/) bleek dat de websites die gerevoked waren het gewoon nog deden en gewoon aangaven dat de SSL Certificaten het nog deden.
Wat in dit geval opviel dat alle meldingen te maken hadden met GlobalSign Certificaten.
Binnen het huidige systeem is dit de beste methode maar juist zaken zoals deze storing en de DigiNotar problemen tonen eigenlijk al aan dat dit systeem van root-authority achterhaald kwetsbaar is. Distributed certification-control is beter. Je vertrouwd dan een site niet omdat diens certificaat gegarandeerd wordt door één root-authority maar eist meerdere authorities en dat laatste kan theoretisch ieder systeem zijn.

Als werknemer vertrouwdje je pc (client) de server van je werkgever als autoriteit primair binnen de scope van het domein van het bedrijf, secundair daarbuiten. Die vertrouwt de servers van zijn vaste leveranciers en klanten. Zo bouw je wederom een chain-of-authority op maar die hoeft niet meer afhankelijk te zijn van root-certificeerders.

Wat wel vereist is, is dat ieder certificaat door meerdere partijen vertrouwd wordt. Hoe meer partijen een certificaat garanderen, hoe meer jouw systeem dat certificaat vertrouwd. Root-authorities zijn niet volledig overbodig, want wie een nieuw systeem opzet zal ergens moeten beginnen en door deze een groter gewicht toe te kennen (wat door de check bij die root-authoriteit valide wordt) als andere autoriteiten, kan men dus toch een nieuw systeem een geldig/vertrouwd certificaat geven. Men dient daarvoor dan wel bij meerdere root-authoriteiten te beginnen. Is een certificaat eenmaal gekend dan zijn de root-autoriteiten niet meer nodig.

Valt een autoriteit uit dan zijn er nog genoeg anderen die een certificaat kunnen valideren. Wordt een autoriteit gehackt, dan zullen de door die alleen die autoriteit gevalideerde certificaten onvoldoende vertrouwd worden. Root-autoriteiten mogen dus niet elkaars validaties overnemen/doorgeven. Dat mogen alleen gewone autoriteiten maar bij iedere volgend level daalt de validatie inwaarde.
Grappig, helemaal geen één melding hiervan tegen gekomen (chrome).

Niet toevallig, want Chrome controleert niet op intrekken van certificaten anders dan een piepkleine eigen lijst.

Chrome beschermt dus minder, maar had dus daardoor geen last van deze fout.
IK heb de foutmelding hier bij Chrome ook hoor!

net::ERR_CERT_REVOKED
Chrome checkt enkel haar eigen mini-CRL, *behalve* bij EV-certificaten omdat het daar verplicht moet van de standaard. Dus daar moet Chrome het knarsentanden doen.

Maar standaard checkt het niet op revocation omdat één van de lead security experts daar het nut niet inziet. Je kunt het wel aanzetten via policy editor.
Ik kreeg op Chrome anders ook gewoon revoked hoor. Dat artikel is ook van 2014 wellicht is er iets veranderd.

Nu ben ik het wel deels eens revocation checks maken een site of applicatie vaak een stuk trager. Bij Java zet ik het bijv ook standaard uit.
Ik kreeg op Chrome anders ook gewoon revoked hoor. Dat artikel is ook van 2014 wellicht is er iets veranderd.

Zoals ik zei (in de post waar je op reageerde O-) ) :

*behalve* bij EV-certificaten omdat het daar verplicht moet van de standaard. Dus daar moet Chrome het knarsentanden doen.

;)
Nee want wij gebruiken ook globalsign zonder EV en die gaf ook expired. Ik moet wel zeggen niet op alle Chrome browsers.
Dan zal het intermediate certificaat in de mini-CRL zitten, of je hebt via policy editor (voor bedrijven) de check aangezet op de betreffende PC's.

Ik gok op het eerste, want Chrome checked anno 2016 nog steeds niet. Dat past ook beter bij de observatie dat enkel sommige een error geaven. De andere hadden nog een oude mini-CRL.
Is dit zo? Vanmiddag bij o.a. Wikipedia problemen via Chrome. Daarna ook via Edge.
Wikipedia is EV-certified en dan moet van de standaard een revocation check gedaan worden en faalt dus inderdaad elke browser, tenzij het nog in de korte cache zit (Windows heeft een cache en dus Edge ook, Chrome, Firefox niet).

Non-EV certificaten falen niet op Chrome, want die worden domweg niet gecontroleerd.
Massale paniek op GoT over Tweakblogs:
Certificaat van Tweakblog.net verlopen ?
User shoombak had het dus ook al gespot.
Merk het nu net ook op content.tweakers.net en andere aan Tweakers gelinkte sites... Certificate revoked is de melding volgens Chrome. Daardoor spelen video's van Tweakers ook niet meer af in m'n browser.
In ieder geval een verklaring waardoor ik gisteren avond bij een aantal sites problemen had bij ssl.
Apart, waarom is dat geen Let's Encrypt geworden net als Tweakers?
Omdat letsencrypt geen wildcard certificaten uitgeeft waarmee je elk subdomain bijvoorbeeld soldaatje.tweakblogs.net kan ondertekenen.
en dat word gedaan omdat wildcards ook maar een vals gevoel van veiligheid geven. Echter kun je ze gewoon aanvragen in letsencrypt volgensmij ;)

Edit; bedoel dus sub-domeinen niet wildcards @ letsencrypt

[Reactie gewijzigd door aadje93 op 13 oktober 2016 18:43]

Nee je kan geen wildcards aanvragen bij LE, je kan wel apart voor ieder subdomein een nieuw certificaat aanvragen, maar dan is een wildcard certificaat natuurlijk veel handiger.

[Reactie gewijzigd door Milosonator op 13 oktober 2016 18:54]

Het aanvragen kan toch geautomatiseerd worden?
Het moet toch elke 3 maanden vernieuwd worden bij Let's Encrypt.
Tenzij Let's Encrypt hier een limiet op heeft zitten?
Het is in ieder geval goedkoper dan een wildcard.
Goedkoper dan een wildcard? Een wildcard kost 75¤ per jaar. Een geautomatiseerd systeem opzetten die voor elke nieuwe tweakblog een nieuw certificaat gaat aanvragen en alle andere certificaten automatisch update zal minstens een programmeur een paar dagen of meer kosten. Dat is dus al gauw een paar honderd of duizend euro. Dan is een certificaatje van 75 piek niet alleen makkelijker maar ook goedkoper.
Die van GlobalSign is vanaf 629 euro per jaar.
https://www.globalsign.com/en/ssl/wildcard-multi-domain/
Maar goed, Let's encrypt heeft limieten dus dat kan ook niet.
https://letsencrypt.org/docs/rate-limits/

[Reactie gewijzigd door Soldaatje op 13 oktober 2016 19:20]

Misschien als je alleen naar de prijs kijkt van het certificaat maar misschien niet als je kijkt naar de hoeveelheid tijd die ze erin zouden moeten steken om iets te maken dat voor iedere blog een apart let's encrypt certificaat aanvraagt en ook elke 3 maanden weer vernieuwd. Denk namelijk dat de prio voor de ontwikkelaars en beheerders van tweakers ergens anders ligt dan dat op dit moment en dan is dus een wildcard certificaat gewoon goedkoper.
Helaas kun je maar 500 certificaten per domein aanvragen. Met 100 namen per certificaat kom je dan een heel eind, maar als je van plan bent flink te schalen is het wel iets om rekening mee te houden.
Misschien zat het nog in de cache van je computer?
Ik wel, vanmisdag net aangekomen in air bnb in Barcelona en wilde kaartjes bestellen online voor toeristische dingen in plaats van in de rij staan, heb ondanks alle browser waarschuwingen toch mijn Credit Card gegevens ingevoerd en gelukkig lees ik nu dit bericht op Tweakers :D
Toevallig specifieke niché die hier gebruik van maakt?
Wikipedia.
Ah, dat verklaart de fout op GitHub vandaag ineens :o
Gelukkig is hiervoor OCSP Stapling uitgevonden... :) Waarom veel websites hiervan geen gebruik maken is mij dan weer een raadsel.
Ik zie niet in waarom dit het probleem zou verhelpen...
In plaats van de client checkt de webserver dan de geldigheid van de certificate chain. Als GlobalSign problemen heeft met OCSP zal de webserver toch ook de validiteit niet kunnen controleren...
Meeste webservers slaan de OCSP response op in de cache en gebruiken de cache voor een bepaalde tijd. Als de webserver de OCSP response wilt updaten net tijdens deze storing dan maakt het niet veel uit nee. Maar als de server bijvoorbeeld gisteren het certificaat heeft gevalideerd en de volgende update morgen is dan had niemand last van deze storing.
Oftewel, de kans is wat kleiner dat je er last van hebt...
Het sluit het probleem dus niet uit.
Ik weet niet precies wat de problemen waren maar het verlaagd in ieder geval de druk significant.

Sowieso is OCSP een slechte oplossing: technisch omdat het een SPOF introduceert en ook voor privacy, want trackng. Ik heb OCSP altijd ook uitstaan. Certificaten geven sowieso een vals gevoel van veiligheid, organisaties zoals de Nederlandse overheid, maar elke certificaatboer ook natuurlijk, kan zonder problemen vrijwillig (of onder overheidsdwang) valse certificaten uitgeven. OCSP helpt daar niets voor. Dan doet Let's Encrypt het in ieder geval nog beter met certificaten met een zeer korte geldigheid, dan is het intrekken van certificaten een beetje een non-issue.
Sowieso is OCSP een slechte oplossing: technisch omdat het een SPOF introduceert en ook voor privacy, want trackng. Ik heb OCSP altijd ook uitstaan.

Wat je zegt is deels waar, doch perfectie is de vijand van een goede oplossing. OCSP is niet perfect, maar lost wel veel op.

Privacy is een probleem, doch enkel bij OCSP, niet bij CRL en OCSP staple. Ook hebben OS'en vaak cache zodat men niet voortdurend checkt.

elke certificaatboer ook natuurlijk, kan zonder problemen vrijwillig (of onder overheidsdwang) valse certificaten uitgeven

Dat kan in theorie, maar in de praktijk gebeurd het niet. Immers dan wordt zo'n autoriteit verbannen. Niet voor niets met honderden miljoenen certificaten uitgegeven is het elke keer weer voorpagina nieuws als het dan bij een handjevol een beetje fout gaat (het gaat immers zelden echt fout).

OCSP helpt daar niets voor

Certifciaat revocation, waaronder OCSP is juist het enige wat hier tegen beschermd zolang certifciaat pinning niet breed ingevoerd is. Welliswaar achteraf, maar vandaar dat ik begon met zeggen dat perfectie een vijand is van het goede.
Dan zit ik 3 uur te klooien met webservers/klanten die problemen geven... Toch even tweakers checken... Jahoor... Toch problemen met Globalsign...

Edit. Helaas heeft het legen van de cache bij mij geen effect. Iemand nog tips?

[Reactie gewijzigd door FordDriver op 13 oktober 2016 19:01]

Mocht je uitvinden hoe je dit kan oplossen laat het mij graag even weten.
Probeer het volgende commando eens vanuit een elevated command prompt:
certutil -setreg chain\ChainCacheResyncFiletime @now
of deze (werkt bij mij ook zonder elevation):
certutil -urlcache * delete

bron: globalsign
Die optie is om wat op disk staat te verwijderen. Die ik gaf verwijderd de cache uit memory.

Forddriver & milosonator gaven aan dat ze de '-urlcache * delete' zonder succes hadden uitgevoerd, vandaar mn opmerking om het met 'ChainCacheResyncFiletime' te proberen; daarmee 'invalideer' je alle CRLs en zou het opnieuw gedownload moeten worden.

Helaas bleek dat dus echter ook niet te werken :(
Ah, dat had ik gemist.
Thx! dat werkt voor mij! :)
Helaas na dat commando + herstart kan ik nog geen sites openen.. maar bedankt voor het meedenken :)

Firefox werkt wel.. maar Chrome en IE niet, en ben nog maar net een uurtje thuis.

[Reactie gewijzigd door dennisdegroot op 13 oktober 2016 21:10]

Thanks! Dit werkte na een reboot
Ik gok dat ze in 1996 zijn opgericht. Niet in 1966.
Waren er op dat moment al soortgelijke certificaten, zoals we die tegenwoordig kennen, maar dan voor via de post?
In 1966 nog niet, het werd pas eind jaren '90 populair voor HTTPS.
PKI is een uitvinden uit 1976: https://en.wikipedia.org/...ey_infrastructure#History
Weet iemand hoe lang het duurt voordat de caches zichzelf weer legen/hoe lang het duur voordat dit probleem 'zichzelf' oplost?
Zoals in het artikel al staat: "Enkele uren later gaf de certificaatautoriteit aan dat de problemen verholpen waren, maar ook hierna werden veel certificaten van klanten van het bedrijf als revoked beschouwd."
Ik heb al een paar keer mijn cache verwijderd, maar ik heb nog steeds problemen met een aantal sites....
Heb inmiddels andere certificaten geïnstalleerd want dat is natuurlijk veel te lang. Bedankt.
Hé, dus dit was het. Ik allerlei dingen uitsluiten. Weet ik in elk geval nu dat ik morgen niet verder hoef te kijken waarom we ineens certificaat problemen hadden op verschillende werkstations. Het vervelende was dat het bij sommige plekken wel werkte en bij andere weer niet, nu is het helder waarom dat het geval was. Had al zo'n vermoeden.

[Reactie gewijzigd door arjentjuh op 13 oktober 2016 18:33]

Wij zijn hier goed de Sjaak, hebben certificaten op o.a. Exchange en RDS die niet meer werken hierdoor :'(
Ik had al een vermoeden. Eerst een vriend die mkij vroeg hoe het kon dat hij een bepaalde site niet kon bezoeken, later kreeg ik zelf ook ergens een certificaat gerelateerde foutmelding. Mij was inderdaad al opgevallen dat het de zelfde cerrificate authority was.
Dus als je een OCSP server/cluster van een bepaalde grote CA, weet plat te krijgen. Krijg je dit soort dingen.
Intressant.

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True