Firefox-gebruikers hebben problemen met verbinding met Microsoft-diensten

Firefox-gebruikers melden dat zij problemen hebben bij het gebruik van verschillende Microsoft-diensten, waaronder Azure en webmail. Ze krijgen een melding te zien dat er vanwege een ongeldig OCSP-certificaat geen veilige verbinding tot stand gebracht kan worden.

Op de statuspagina van Visual Studio Team Services schrijft Microsoft dat het op de hoogte is van de problemen. Een oorzaak is nog niet achterhaald; het bedrijf stelt dat de problemen mogelijk te maken hebben met 'een certificaat dat gerelateerd is aan OCSP'. Dat is een protocol waarmee de geldigheid van digitale certificaten gecontroleerd kan worden. Firefox maakt hiervan gebruik, maar bijvoorbeeld Chrome niet. Microsoft raadt dan ook aan tijdelijk een andere browser te gebruiken.

Een twitteraar laat weten dat hij een verlopen OCSP-certificaat heeft gevonden, dat mogelijk de oorzaak van de problemen is. Verschillende Microsoft-diensten zijn niet bereikbaar voor Firefox-gebruikers, waaronder Azure, Outlook en de webversie van Skype. Getroffen gebruikers kunnen tijdelijk ocsp stapling uitschakelen, waardoor de diensten weer te gebruiken zijn. Het is vooralsnog onbekend wanneer Microsoft met een oplossing komt.

Waarschuwing die Firefox-gebruikers te zien krijgen

Reacties (93)

[johnny2000]

Lijkt me meer "Microsoft heeft problemen met hun OCSP server"? Het is toch echt MS die problemen heeft en als gevolg hebben FF gebruikers problemen.

[Ayporos]

Klopt.

Het certificaat is niet per se verlopen van wat ik gezien heb want als ik een (paar) keer op refresh of 'try again' druk dan komt hij er wel gewoon door... Wel naar natuurlijk maar ja.

[MacD]

En verdomd. Lijkt dan op een stel servers waarvan een aantal een onjuist certificaat hebben ...

[elbowlessgoat]

daar lijkt het inderdaad op. Voor FF is dit een gevalletje "works as intended", voor MS een gevalletje "oops". Niet het ergste, maar als het inderdaad een verlopen certificaat betreft is de server simpelweg niet geldig. Het feit dat FF deze check ingebakken heeft is wel een plus natuurlijk, alleen jammer van MS.

[mcDavid]

Vooral jammer dat de "oplossing" van Microsoft is om een minder veilige browser te gebruiken.

[CAPSLOCK2000]

Daar ben ik een beetje boos om. Het is een snelle work-around maar het is toch helemaal voorspelbaar dat mensen het nooit meer terug zetten?

Hoe weet ik trouwens dat dit advies echt van Microsoft komt? Normaal gesproken zou ik zeggen "Kijk maar op de website van Microsoft" maar als we eerst de beveiliging uitschakelen heeft dat ook niet zo veel zin meer. Misschien is die website wel vervangen door een hacker en is dat advies om OCSP uit te schakelen alleen bedoelt om te verbergen dat de site is gekraakt.

In plaats van een andere browser te gebruiken adviseer ik mensen om een andere cloud-provider te zoeken.

[Dysmael]

Dan heb je al snel geen optie meer dus. Volgende keer heeft Google zo'n probleem, daarna Amazon en na nog een paar keer gewisseld te hebben van provider ben je door je opties heen.

Overal wordt wel eens een fout gemaakt.

[mcDavid]

Het probleem is niet dat er fouten gemaakt worden, het probleem is de reactie. Je mag verwachten dat er in zo'n geval een reactie komt met de precieze oorzaak, en bovendien een snelle oplossing.

Aanraden beveiliging uit te schakelen is niet een oplossing en zeker niet de reactie die je in zo'n geval wilt horen.

[prutsger]

Eens, als je als bedrijf je data in de EU moet houden kun je niet eens kiezen voor Google of Amazon.

Zoals @mcDavid al zegt is de reactie het probleem. Nee, ik ga geen andere browser gebruiken omdat MS de zaakjes niet op orde heeft. (Trouwens niet makkelijk omdat te communiceren naar 300+ medewerkers op meerdere locaties als zowel Yammer als Outlook online niet werkt en 50+% geen Outlook applicatie gebruikt).
Ook enorm vervelend dat dit nu al de hele (werk)dag duurt... dit moet toch in 30 minuutjes opgelost kunnen zijn...?

[MacD]

Eens, als je als bedrijf je data in de EU moet houden kun je niet eens kiezen voor Google of Amazon.

Ja ... en nee. Je kan iig bij google ervoor zorgen dat al die data op een EU server staat. Nadeel is dat het amerikaanse wel laatst heeft geordeeld dat ze met een juridisch dwangbevel uiteindelijk wel die data kunnen bekijken.

Zoals @mcDavid al zegt is de reactie het probleem. Nee, ik ga geen andere browser gebruiken omdat MS de zaakjes niet op orde heeft. (Trouwens niet makkelijk omdat te communiceren naar 300+ medewerkers op meerdere locaties als zowel Yammer als Outlook online niet werkt en 50+% geen Outlook applicatie gebruikt).
Ook enorm vervelend dat dit nu al de hele (werk)dag duurt... dit moet toch in 30 minuutjes opgelost kunnen zijn...?

Mee eens, behalve het tijdsschema: dit soort dingen kunnen best lang duren om te ontdekken, de fix te bedenken, realiseren en uiteindelijk door te propageren, Aan de andere kant, het is nu 0:36 de volgende dag en het is nog niet opgelost ...

[MacD]

Nee, dus. Propagatie kan makkelijk 24 uur duren.

En als je denkt dat dat niet zo is dan moet je over dit soort zaken niet spreken op een forum als dit omdat je heel duidelijk maakt dat je niets wet over dit soort zaken.

En dat meen ik oprecht: Tweakers was vroeger een nerd-haven; een plek waar technici posten. De meeste posts waren gemaakt door mensen die wisten waar ze het over hadden en dus kon je erop aan dat vaak de info daadwerkelijk correct zou zijn.

En als jij denkt dat wereldwijde certificatie-propagatie een kwartier duurt dan hoor je ...

Weet je wat? ik ga het gewoon hard zeggen:

Dan hoor je je bek te houden en de professionals te laten praten.

[dasiro]

ik ben niet echt op de hoogte van OCSP, maar ik veronderstel dat dit slechts 1 van de verschillende types van beveiliging is die ze toepassen. Ze zullen heus nog wel andere manieren hebben om toch op een betrouwbare manier te communiceren, want anders zou énkel firefox "veilig" zijn.
Bovendien is HUN advies een andere browser te gebruiken, de workaround is echter ook niet meer dan dat: een tijdelijke oplossing om verder te kunnen. Dat dit een client-actie is die potentieel op andere sites wél een gevaar kan opleveren (in het geval die énkel OCSP ondersteund), dat valt op dat moment buiten hun scope en is hun service niet meer unavailable maar slechts distorted.

[CAPSLOCK2000]

ik ben niet echt op de hoogte van OCSP, maar ik veronderstel dat dit slechts 1 van de verschillende types van beveiliging is die ze toepassen.

Dat is zo, maar OCSP is het sluitstuk. Zonder OCSP kun je die andere middelen eigenlijk niet vertrouwen.

Ze zullen heus nog wel andere manieren hebben om toch op een betrouwbare manier te communiceren, want anders zou énkel firefox "veilig" zijn.

Nope, het is het tweede geval. Alleen Firefox doet het echt goed, de rest heeft zitten suffen of vindt veiligheid niet echt belangrijk.

Bovendien is HUN advies een andere browser te gebruiken, de workaround is echter ook niet meer dan dat: een tijdelijke oplossing om verder te kunnen.

Ik vindt het een slechte gewoonte om de beveiliging maar uit te schakelen of te omzeilen als je er last van hebt. Als er een keer echt iets gebeurt dan zal iedereen op dezelfde manier reageren en het probleem negeren.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 21:46]

[Ayporos]

Mee eens, is een beetje hetzelfde als UAC uitschakelen omdat je die popups die vragen om toestemming irritant vind.

[Ayporos]

hahaha ja microsoft boeit het natuurlijk niet welke browser jij gebruikt (zolang je toch al geen IE/Edge gebruikte).

Doet me denken aan Ziggo die gewoon weigerde mensen te adviseren een andere (non-ziggo) DNS in te stellen om toch het internet op te kunnen wanneer hun DNS servers plat lagen.. zij wisten natuurlijk donders goed dat je die mensen dan niet meer terug ziet op hun eigen DNS..

[Nox]

Dit doet me denken aan de office 365 apps en websites die langzamer werkten op linux, na de user agent aangepast te hebben liep het weer als een trein.

[TWyk]

Bij het hoofdcertificate van mail.live.com is aangegeven
OCSP Must Staple: No
https://www.ssllabs.com/ssltest/analyze.html?d=mail.live.com

Maar blijkbaar kiest Firefox dus toch voor OCSP stapling?!

[PTR]

Moet niet, mag wel. Als je OCSP stapling dan beschikbaar stelt, zorg dat het er goed staat. Verlopen certificaat, het is een klassieker en maakt ms toch een beetje menselijk ;-)

[MadEgg]

OCSP uitschakelen werkt niet. Ik heb OCSP altijd uit namelijk - de certificaatboeren hoeven mij ook niet te tracken. Microsoft-sites kan ik echter niet openen op dit moment.

Het lijkt erop dat Microsoft OCSP-stapling gebruikt, waarbij het OCSP-request aan de kant van de server gedaan wordt. Dit kun je als gebruiker dus niet uitschakelen en het komt er effectief op neer dat je een bericht van de server krijgt: Dit is mijn certificaat, en we hebben het gecontroleerd, en hij is niet geldig.

Microsoft moet dus aan de bak: ofwel hun OCSP-stapling fixen, ofwel OCSP-stapling uitzetten.

[update]Hmm, de preference waarnaar gelinkt wordt zet OCSP-stapling support in de browser uit. Tja, dat kan inderdaad ook natuurlijk, maar dat is wel een erg matige oplossing.

[Reactie gewijzigd door MadEgg op 22 juli 2024 21:46]

[MadEgg]

Waarom gaat dat te ver? Data is goud. Dat blijkt maar uit de winstcijfers van Facebook en Google.

We komen de certificaatboeren massaal op een serveerplaatje aandragen welke websites wij bezoeken en het is te ver gezocht om te verwachten dat ze die data gaan verzamelen en analyseren om er geld mee te verdienen? Denken dat dat te ver gaat vind ik dan weer vrij naïef.

[Fuzzillogic]

Juist met stapling gaat er geen request meer naar de certificaatboer. Het is juist een techniek om het aantal request naar de certboer te beperken. Mogelijk dat met stapling de certboer juist helemaal geen info van jou krijgt omdat je browser nooit een request doet naar de certboer, mits de server waar je mee verbindt stapling ondersteunt. Dat weet ik echter niet zeker.

[MadEgg]

Ja, daar gaat het me toch om? OCSP stapling = goed, OCSP zonder stapling = niet goed. Naar mijn opvatting in ieder geval

[Fuzzillogic]

Een aanvaller zou met MitM stapling kunnen weglaten. Dan ga je dus nat. En ik vraag me af of je door het uitschakelen niet het hele systeem van revocation uitschakelt.

[MadEgg]

Daar is Must-Staple dan weer voor. Zie bijvoorbeeld https://www.grc.com/revocation/ocsp-must-staple.htm

Als je in Firefox OCSP requests uitschakelt is OCSP stapling nog steeds beschikbaar en wordt ook toegepast. Maar de soft-fail is inderdaad een probleem, dat moet in het hele systeem opgelost en geforceerd worden. Browsers zouden feitelijk gewoon non-stapled certificate responses moeten weigeren.

[vanbroup]

Het gaat om een OCSP status welke is bijgevoegd door de server (stapling). Toen de status is bijgevoegd was het OCSP signing certificaat bijna verlopen maar nog wel geldig.

Je kan dit probleem duidelijk zien op revocationcheck.com, de huidige OCSP status is geldig maar Microsoft stuurt een response met een verlopen certificaat naar de gebruikers via OCSP stapling.

Zie het volledige report:
https://certificate.revocationcheck.com/www.live.com

[runnershigh]

Dat OCSP is er natuurlijk ook niet voor niks. Hoe erg is het dan dat andere browsers dat niet gebruiken?

[MadEgg]

Chrome doet het anders: http://www.zdnet.com/arti...ficate-revocation-better/

Op zich is OCSP een ramp, met name in de naïeve implementatie. Het oorspronkelijke idee was dat de browser voor elke SSL certificaat wat hij krijgt bij de Certificate Authority gaat navragen of dat certificaat niet verlopen is. Veel extra data wat niet nodig is, en bovendien weet de CA zo welke sites je wanneer bezoekt, en dat is vanuit een privacy-oogpunt niet gunstig.

OCSP Stapling is heel veel beter: je laat de klus aan de server. De server vraagt regelmatig aan CA om te bevestigen dat zijn certificaat niet verlopen is, en krijgt daartoe een handtekening van de CA. Deze bevestiging wordt meegestuurd met het certificaat. De browser kijkt naar die handtekening en verifieert of de handtekening door de juiste partij (de CA dus) gezet is, en zo ja, dan wordt het certificaat vertrouwt.

Nu is het wel zaak dat deze handtekening met het juiste certificaat van de CA ondertekend wordt, en dat is wat er nu bij MS misgaat: de ondertekening gebeurt met een verlopen certificaat. Hierdoor is de OCSP handtekening niet te vertrouwen en daar geeft de browser een foutmelding over.

Google heeft in 2012 al, terecht, geconcludeerd dat de OCSP-implementatie waarbij de verificatie aan de browser overgelaten wordt inefficiënt en slecht voor de privacy is (als anderen inbreuk maken op privacy interesseert het Google blijkbaar ineens wel ). In plaats daarvan hebben ze een alternatieve implementatie gedaan. Google verzamelt ingetrokken certificaten (in essentie Certificate Revocation Lists, CRL's) van CA's en bundelt die en stuurt die naar de browser, gelijk met andere updates aan de browser. Hiermee worden ingetrokken certificaten ook redelijk snel verwerkt, al zal het langer duren dan met een OCSP.

Het bestaansrecht van OCSP is de situatie dat een private key uitlekt die een server gebruikt voor zijn SSL-implementatie. Als de private key uitlekt kan iedereen zich voordoen als de server en kan de veiligheid dus niet meer gegarandeerd worden. Daarom kun je het certificaat intrekken (waarna de status van het certificaat op ingetrokken wordt gezet), zodat browsers het certificaat niet zullen vertrouwen ondanks dat het nog niet verlopen is.

Een browser die dus niets doet met revoked certificates is wel een veiligheidsrisico. OCSP browser-side is een privacy-issue. Daarmee is OCSP Stapling of een aanpak zoals Google gebruikt voor Chrome de juiste manier om het probleem aan te pakken. OCSP Stapling uitschakelen zoals hier als workaround wordt aangeraden is dus zeker geen goed idee.

[Reactie gewijzigd door MadEgg op 22 juli 2024 21:46]

[vanbroup]

Een van de problemen is de mannier waarop OCSP stapling is geimplementeeerd aan de client kant. Veel clients, waaronder webservers zoals IIS, Apache en Nginx valideren bijvoorbeeld niet of het OCSP response wat ze aan de client meesturen wel geldig is.

Daarnaast schieten veel implementaties nog andere dingen te kort, dit is een mooi lijstje van Ryan Sleevi met wat een OCSP stapling client bijvoorbeeld zou moeten ondersteunen.

De alternatieve revocation implementatie van Google is ook absluut niet goed! Het is namelijk niet mogelijk om alle revocaties van alle CA's naar de client te sturen (dit zou om heel veel data gaan). Daarom bepaald Google wat wel en wat niet op deze zwarte lijst komt te staan. Het kan dus zomaar zijn dat jij net een website bezoek waarvan de security gecomprimiteerd is maar Chrome je vrolijk door laat gaan ondanks het certificaat gerevoked is.

[MadEgg]

Een van de problemen is de mannier waarop OCSP stapling is geimplementeeerd aan de client kant. Veel clients, waaronder webservers zoals IIS, Apache en Nginx valideren bijvoorbeeld niet of het OCSP response wat ze aan de client meesturen wel geldig is.

Daarnaast schieten veel implementaties nog andere dingen te kort, dit is een mooi lijstje van Ryan Sleevi met wat een OCSP stapling client bijvoorbeeld zou moeten ondersteunen.

Ja, dat is jammer, en dat soort problemen zijn ook de reden dat goede ontwikkelingen vaak te lang op zich laten wachten: laksheid van softwarebouwers. Volledig vertrouwen op OCSP stapling is daarmee niet haalbaar, helaas.

De alternatieve revocation implementatie van Google is ook absluut niet goed! Het is namelijk niet mogelijk om alle revocaties van alle CA's naar de client te sturen (dit zou om heel veel data gaan). Daarom bepaald Google wat wel en wat niet op deze zwarte lijst komt te staan. Het kan dus zomaar zijn dat jij net een website bezoek waarvan de security gecomprimiteerd is maar Chrome je vrolijk door laat gaan ondanks het certificaat gerevoked is.

Ik heb eerlijk gezegd geen idee om wat voor volume het gaat - hoeveel certificaten worden er ingetrokken? Revoked certificates hoeven maar voor een bepaalde duur bewaard te blijven, totdat het certificaat in kwestie verlopen is. Aangezien een ingetrokken certificaat op de browser niet meer dan de fingerprint hoeft te bevatten kun je honderdduizenden ingetrokken certificaten op een client zetten voordat het echt een last op zijn opslagruimte gaat vormen. Als je dan vervolgens alleen de diffs doorstuurt naar de client lijkt het datagebruik me ook nog wel mee vallen.

Maar goed, ik begrijp uit jouw verhaal dat Google dus eigen rechter speelt wat ingetrokken certificaten betreft? Dat is dan wel weer een zeer kwalijke oplossing. Jammer dat ze met Chrome een dermate grote grip op de markt hebben dat ze er ook nog mee weg kunnen komen.

[vanbroup]

Google pushed hier inderdaad zijn eigen regels, specifiek: https://dev.chromium.org/Home/chromium-security/crlsets

Hierin staat bijvoorbeeld "The limit of the CRLSet size is 250KB", wat betekend dat er niet heel veel certificaten kunnen worden opgenomen. Ook is er geen rekening gehouden met bijvoorbeeld Let's Encrypt welke enkel een OCSP server heeft en geen CRL publiceerd.

Een van de belangrijkste nadelen van een CRL is dat dat ze enorm groot kunnen worden. Er zijn zelfs enkele voorbeelden van ver over de 100MB, maar in het algemeen zijn ze een paar kilobyte (voor een interne of zeer kleine CA), maar voor een beetje issuer spreek je al snel over honderd kilobytes tot niet groter dan 5MB. Vlak naar hardbleed zag je bijvoorbeeld een flinke groei in het aantal terugtrokken certificaten wat zorgde dat bijna alle CRLs van enkele CA veel groter werden. Natuurlijk vervallen veel van deze certificaten weer en worden CRL's voor het standard TLS weer kleiner (bij andere toepassingen als document of codesigning mogen de serial numbers vaak niet van de CRL verwijderd worden).

Om dan weer terug te komen op OCSP, dit heeft als voordeel dat het per certificaat kan worden opgevraagd (en gestapled) maar ook dat je enkel een goede status kan krijgen voor certificaten welke daadwerkelijk zijn uitgegeven (geforceerd via de baseline requirements van het CA/Browser forum). Bij een foutief verkregen of gecreerd certificaat zou dit niet worden opgemerkt bij gebruik van een CRL waarbij het certificaat onbruikbaar zou zijn als deze gecontroleerd wordt via OCSP.

[hamsteg]

Tijdelijk uitzetten in firefox:

about:config
security.ssl.enable_ocsp_stapling --> false

Niet vergeten weer aan te zetten als MS de problemen het hoofd heeft geboden!

[Reactie gewijzigd door hamsteg op 22 juli 2024 21:46]

[SmiGueL]

Ik heb het gek genoeg werkend gekregen door de cache te clearen (Ctrl+F5) en de URL handmatig te overrulen met:
https://outlook.live.com

(dus als die error pagina in beeld komt gewoon het gedeelte achter https://outlook.live.com weggooien )

[Reactie gewijzigd door SmiGueL op 22 juli 2024 21:46]

[Calamor]

Werk soms wel en soms weer niet. Had dit ook op mijn telefoon dat het tijdelijk werkt.

[SuBBaSS]

Hier hetzelfde. Vervolgens prima in kunnen loggen op outlook.com maar bij het versturen van een mail dan ineens weer de melding dat ik niet met internet verbonden zou zijn (terwijl dat wel het geval is, getuige deze post bijv.).

Ah well, dan maar even op een alternatieve manier. Kan me voorstellen dat er op dit moment bij Microsoft wat mensen aan het zweten zijn om dit probleem op te lossen..

[steppert]

ik kwam er pas in door via microsoft in mijn account te loggen en dan van daar naar mijn mail in tegaan.

[Verwijderd]

Onveilige workaround. Is een global setting in FF, en dus niet aan te bevelen. MS moet dit gewoon zo snel mogelijk fixen, en anders zitten hun klanten op de blaren.

[kozue]

Niet onveiliger dan een andere browser gebruiken. Andere browsers ondersteunen het sowieso niet, dus ocsp uitzetten brengt de security van de browser terug naar chrome- of edge-niveau.

[MadEgg]

Chrome checkt wel op CRL's, maar doet het anders.

Zie:
MadEgg in 'nieuws: Firefox-gebruikers hebben problemen met verbinding naar Mi...
http://www.zdnet.com/arti...ficate-revocation-better/

[Dysmael]

CRL en OSCP zijn twee verschillende technieken.
CRL hoort al lang een stille dood te zijn gestorven.

[MadEgg]

Als je puur naar de definitie van de term kijkt heb je gelijk. OCSP is een alternatief voor het downloaden van CRL's door de browser.

OCSP is een manier om aan de CA te vragen of een certificaat ingetrokken is. Maar hoe weet de CA of dat certificaat ingetrokken is? Door op een lijst met ingetrokken certificaten te kijken. En wat is een CRL? Een lijst met ingetrokken certificaten. OCSP is dus een manier om een CRL te bevragen zonder zelf de hele lijst te hebben.

[Dysmael]

Correct, daarom moet je ook geen CRL willen gebruiken. Dat is een URI naar een bestand, wat gewoon 100MB of meer zou kunnen zijn. Dat is nagenoeg niet te onderhouden. Zit ook genoeg mogelijkheden voor misbruik in. Net als OCSP helaas. Niet om het minste omdat dit (standaard) steeds informatie opvraagt bij een ingesloten URI van het certificaat.

[Verwijderd]

Waarschijnlijk ben ik de enige die geen problemen heeft met de combo Firefox en Microsoft. Ik kom overal in?

[PuckStar]

het lijkt rond 10:15 te zijn opgelost.

[Paganstars]

Hier nog steeds issues.

[Laloeka]

Ctrl+F5 / cache legen geprobeerd?

[Paganstars]

Automagisch opgelost (gok dat MS een nieuw cert heeft uitgegeven)

[uip]

ik heb inderdaad ook problemen. Raar, want volgens SSL Server Test zijn er geen problemen

[ArmEagle]

Helemaal niet raar aangezien het certificaat een aantal uren geleden is verlopen. En de test aangeeft:
"Assessed on: Mon, 29 May 2017 06:54:34 UTC"

[tijmenvn]

Tijdelijk op te lossen door naar about:config -> security.ssl.enable_ocsp_stapling -> false

[dvdende]

Ter info, OneDrive is ook niet bereikbaar vanuit FF.

[Rataplan_]

Hmm. Eerst maar eens afwachten wat nou echt de oorzaak is, maar als dit wederom een certificaat probleem is geeft dit weer aan waarom ik nog steeds huiverig ben voor cloud-diensten op deze schaal. Ze hebben in het verleden al vaker probemen gehad op Azure (met AD, RDS en nog wel wat andere zaken) door verlopen certificaten op gedeelten van Azure. Natuurlijk is fouten maken en outages hebben menselijk, geen probleem. Echter we hebben toch al verschillende klanten terug gekregen van Office 365 terug naar ons eigen on-premises platform omdat wanneer er dan een outage is, je bij MS niemand kan bereiken die ook echt wat zinnigs erover te zeggen heeft. Als je hele toko plat ligt is dat geen fijn gevoel.

[sprankel]

Jij verwacht dat Microsoft al hun klanten persoonlijk te woord gaan staan bij een probleem?
Een doorsnee medewerker in een bedrijf krijgt enkel te horen dat het niet werkt, hoe of wat krijgt die niet bepaald te horen. Als je belangrijk genoeg bent kun je al eens naar de directeur van IT bellen en dan krijg je meer info. Voor de cloud ben je als bedrijf maar een kleine speler tenzij je een gigantisch bedrijf bent dat dan ook gigantisch veel betaald voor hun support contracten. (lees als kleine vis kun je die support contracten simpelweg niet betalen)

Overigens houd Microsoft zijn klanten prima op de hoogte als je hun communicatie volgt. En na ieder incident publiceren ze een post incident rapport met volledige analyse, tijdlijn en scope. Vervolgens vermelden ze de stappen die ze al genomen hebben, wanneer en welke stappen ze nog zullen nemen.
Deze communicatie is echter enkel beschikbaar voor beheerders van O365.

Als je echter verwacht dat je wel even kan bellen en dat ze je daar piekfijn het issue uit te doeken dan mis je heel het punt van de cloud (alles centraliseren) en kan je inderdaad beter on premise blijven. Dat soort service kun je simpelweg niet rond krijgen als je op dergelijke schaal begint te werken.

De communicatie over dit issue is momenteel als volgt:
2017-05-29 11:52 (UTC)

User Impact: Users may be intermittently unable to connect to Exchange Online Protection (EOP) features via the Firefox browser.

More info: This issue is affecting access to safelinks via Firefox, however, users are able to connect to the affected sites via other browsers, such as Internet Explorer, Edge, Chrome, or Safari.

Current status: We've determined that some Online Certification Status Protocol (OCSP) stale certificate data was preventing access to the EOP services or features. We're restarting services in an attempt to clear the stale data from the affected environment. .

Scope of impact: Customer reports indicate that many users will likely experience impact related to this event. Our analysis indicates that this affects any users connecting to EOP sites via the Firefox browser.

Next update by: Monday, May 29, 2017, at 6:30 PM UTC

-----------------------------------------------------------------------------------------------------------------

2017-05-29 10:24 (UTC)


Current status: We're investigating an issue in which some users may be unable to access or use Exchange Online Protection (EOP) services or features via the Firefox browser. We've identified that a certificate may be causing the issue and we're analyzing systems logs to confirm certificate status and identify the source of the issue.

(buiten de current status is de rest identiek van 11:52)