Fout tls-certificaat veroorzaakte storing SharePoint Online en OneDrive

Microsoft meldt dat de storing van SharePoint Online en OneDrive for Business is opgelost. Het probleem werd veroorzaakt door een fout met het tls-certificaat van de services. Dit probleem werd geïntroduceerd na een update van Microsoft.

Veel gebruikers meldden maandagavond dat ze een foutmelding te zien kregen bij het bezoeken van SharePoint Online of OneDrive for Business, detailleert BleepingComputer. Na een update lijkt het tls-beveiligingscertificaat voor .sharepoint.de te zijn toegevoegd aan het internationale domein. Hierdoor ontstond er een discrepantie tussen het certificaat van het Microsoft-platform en gebruikers die van buiten Duitsland verbinding probeerden te maken.

Microsoft zegt dat getroffenen via het Microsoft 365-admincenter meer informatie kunnen krijgen over het verholpen probleem. De storing lijkt grofweg een uur geduurd te hebben.

SharePoint Online en het onderliggende OneDrive for Business maken deel uit van het zakelijke Microsoft 365-abonnement. De eerstgenoemde service maakt het mogelijk om binnen een bedrijf of organisatie onderling informatie uit te wisselen en op te slaan. OneDrive is een cloudopslagplatform.

Bron: Chris Greenacre​​​​​

Reacties (29)

[dovo]

Handige tip voor chrome(ium) gebruikers: het kan zijn dat je browser het oude (verkeerde) certificaat cached, terwijl de server ondertussen wel het juiste heeft. Een simpele refresh volstaat meestal niet. Volgende werkt voor mij altijd:
Open developer tools, als deze open staat kan je rechts klikken op de refresh-knop en “Empty Cache and Hard Reload” selecteren.

[nightgold]

CTRL + F5 geeft je ook een hard reload

[meowmofo]

Dit heb je enkel als er een browser instance open blijft. Sluit je alle windows en start je de browser opnieuw op, dan haalt die het cert opnieuw op. CTRL + F5 zoals hierboven vermeld werkt niet altijd in mijn ervaring met Chrome en certificates.

[Reactie gewijzigd door meowmofo op 24 juli 2024 05:09]

[Zebby]

Heerlijk dat dit zelfs bij op enterprise niveau gebeurt.
Allemaal mensenwerk uiteindelijk

[Keypunchie]

Een veelvoorkomende storing, een verlopen certificaat, of een certificaat met niet de juiste SANs.

Je probeert certificatenbeheer zoveel mogelijk te automatiseren, maar soms sluipen er op plekken foutjes in, met name natuurlijk als er wijzigingen in de tussentijd zijn geweest.

[Dennisb1]

maar soms sluipen er op plekken foutjes in, met name natuurlijk als er wijzigingen in de tussentijd zijn geweest.

Als je dat goed inricht kan je die fouten ook voor zijn voor het in de productie zit.

[Cergorach]

In een simpele kantooromgeving, sure. In een complexe productie omgeving, heel erg lastig omdat je heel moeilijk je complete productie omgeving kan nabouwen voor een testomgeving. En wat ik regelmatig tegenkom is de productie omgeving niet helemaal exact is zoals beschreven in de documentatie (als er al documentatie is)... Hierdoor kunnen hele kleine verschillen leiden tot hele grote problemen. Juist certificaten 'testen' zal geen 1-op-1 situatie (kunnen zijn).

In dit geval, je testteam zit in Duitsland, niets aan de hand!

[BugBoy]

Daarom is het ook verstandig om je infrastructuur niet te documenteren, maar te coderen. Ik gebruik voor verschillende klanten Terraform en dat werkt erg goed om je infra mee te automatiseren. Het grote voordeel is dat je ook meteen fatsoenlijke change-management kan doen en afwijkingen kan detecteren.

Door gebruik te maken van variabelen kan je ook prima een dev/prod infrastructuur vanuit dezelfde code-base beheren. Het is altijd goed om de verschillen tussen dev/prod minimaal te houden, maar dat kan niet altijd (bijv. andere domeinnamen) en ook is het vaak een kosten-issue.

[Cergorach]

Andersom kan je ook gewoon documentatie automatiseren, alleen wordt dat vrij weinig gedaan. Daarnaast, wil iemand je inrichting begrijpen, dan moet die persoon heel goed thuis zijn in Terraform en alle onderliggende systemen. Dat is leuk voor de DevOps, maar hoe werkt je 1e/2e lijns personeel daarmee? Hoe zit het met de toepassingen die geen 'Infrastructure as Code' (fatsoenlijk) ondersteunen?

Ik zit over het algemeen aan de kantoorautomatiseringskant en daar komen we teveel zaken tegen waarbij 'Infrastructure as Code' niet werkbaar is, vaak vanuit een security oogpunt. Ik heb een jaar of 2+ geleden gekeken naar Microsoft365DSC (Desired State Configuration voor je M365/O365 tenant) en wat was dat een triest verhaal, super traag, incompleet, insecure by design, gebruikte ook nog eens een onveilige verbinding. Zo te zien is er vast het een en ander veranderd, maar ik heb zo mijn twijfels (gezien de staat toen) dat ze er wat fatsoenlijks van hebben weten te brouwen. Don't get me wrong, als je het goed doet werkt het perfect voor het Azure platform, maar zodra je in de buurt komt van AAD, Exchange Online, etc. Bijzonder belazerd! (tenzij je zelf PS based modules gaat schrijven en bij gaat houden indien wijzigingen in het systeem).

En zoals gezegd, wie gaat het 1e/2e lijn personeel opleiden om dat te begrijpen? Gezien de issues met kwalitatief goed IT personeel werven de laatste paar jaar, als je daar ook nog eens 'ervaring met Terraform' bij gooit krijg je echt helemaal niemand meer op je sollicitatie gesprekken.

En wat ik ook bij de Enterprise zie is dat het stukje product(ie) devs/ondersteuning allemaal aparte eilandjes zijn die ieder zo hun eigen ding doen. Hoe neem je dat fatsoenlijk mee? Het gewoon behandelen als een stukje software dat op je infrastructure draait? Juist wanneer de meest complexe implementaties een combinatie van die twee is?

Ik denk echter dat je uit zo een 'Infrastructure as Code' ook juist heel mooi documentatie automatisch kan genereren. En ik ben zeker ook een voorstander hiervan, maar het is geen magic cure-all.

Note: Staar je niet helemaal blind op de 1-op-1 situatie van je prod en test, zeker in M365/O365 kan je test er net iets anders uitzien dan prod, het zijn immers niet dezelfde tenants (wat heel nasty kan zijn wanneer MS je dat niet verteld). MS adviseerde dan ook in je prod tenant te testen... Wat ik niet geheel zie zitten btw!

[BugBoy]

Ook Terrafom is zeker niet perfect. Vooral secure opslag van je state is soms best tricky (bijv. keys, access credentials, ...). Aan de andere kant werken steeds meer systemen met service principals die met tijdelijke keys werken. Dan heb je al veel minder gevoelige gegevens in je state staan.

Ik werk voornamelijk met AWS, Azure en GCP en dat werkt eigenlijk allemaal vrij goed met Terraform. Ook Kubernetes clusters zijn er prima mee uit te rollen, maar wat meer custom software wordt inderdaad lastig. Voor ons eigen product heb ik een Terraform provider geschreven en dat zie je eigenlijk wel steeds meer gebeuren.

Terraform leest veel eenvoudiger dan allerlei complexe Powershell scripts (die vaak maar eenmalig werken) en CloudFormation (AWS) of ARM/Bison (Azure) zijn helemaal draken van talen. Beheer van infra ligt bij ons puurt bij de DevOps. Andere support-medewerkers hebben er geen toegang toe en geen inzicht in.

De truc is inderdaad om je Terraform scripts geen all-in-one script te laten zijn. Dat is niet te onderhouden en ik wil graag de TF configuratie bij de code-repo houden, zodat het consistent is met de code en je het ook via je CI/CD pipeline kan uitrollen (of je infra kan controleren voordat je uitrolt).

Maar 100% eens dat het geen magic oplossing is. Maar het is al een heel stuk beter dan een bestandje waar beschreven staat waar je op moet klikken om je infra weer opnieuw op te tuigen. Dat is nooit compleet en vaak insecure, omdat alle nitty/gritty details gemakshalve maar achterwege zijn gelaten.

[MvGroenigen]

Klok / Klepel.
De configuratie van je productie servers kun je niet testen op je test servers.
Het is niet handig als je nieuwe code test op je test servers met de productie server config, en dat door een foutje je productie databases om zeep geholpen worden.
Hetzelfde met certificaten. de test servers werken hoogstwaarschijnlijk met eigen certificaten. dus een foutje in de productie config wordt niet in de test config opgemerkt.

[supersnathan94]

Ja dat klopt, maar je kunt de configuratie wel valideren. Dat is alleen wel een lastige en wordt dus vaak overgeslagen.

Neemt niet weg dat je zo weinig mogelijk verschillen wil tussen je test en productie omgevingen. Liefst alleen wat config wijzigingen en eigenlijk alleen maar in de vorm van hoeveelheden, URLs en credentials. En het liefst met autodiscovery enzo. Maarja. Das wel richting utopie.

[batjes]

Klinkt leuk, dat zal Microsoft ook allemaal hebben.

Certificaten blijven gewoon foutgevoelig en het is volgens mij ondertussen gewoon de grootste veroorzaker voor major/prio 1 problemen in de IT wereld.

[Klauwhamer]

Het zou ook schelen als Microsoft (in geval van Dynamics NAV/BC) er voor zorgt dat certificaatwissels een beetje fatsoenlijk gedaan kunnen worden, zonder een batterij aan noodzakelijke stopstarts en/of handmatig certificate bindings uit het systeem te beuken. En zorg er ook maar voor dat je de thumbprint niet uit MMC copypastet zonder dat je het eerste unicode character verwijderd.

[fastedje]

Wat ik dan niet snap is dat ze dit niet goed testen vooraf (op een staging omgeving( en achteraf als dubbel-check. Je kan echt niet zomaar blindelings updated uitrollen op een productieomgeving, dat is vragen om downtime.

[BugBoy]

Je kan met een staging omgeving heel veel problemen voor zijn. Maar het is een illusie dat je alles af kan vangen. Domeinnamen zijn vaak anders, certificate authority kan iets verschillen, totaal andere load, ... Ik probeer altijd de staging omgeving zoveel mogelijk gelijk te houden en toch gaat het heel soms mis.

[Frame164]

Waaruit concludeer jij dat ze blindelings dingen hebben gedaan?

[supersnathan94]

Het kan ook zo zijn dat ze blindelings exact niks hebben uitgerold op productie en het certificaat gewoon verlopen is. Hoe langer die dingen geldig zijn hoe vaker dat het probleem is. Zelfde geldt voor licenties.

Diegene die de reminder in zijn agenda had staan is bijvoorbeeld al weer vertrokken, of er is een miscommunicatie over de datum en inkoop plant het te laat in. En zo zijn er nog wel meer redenen te bedenken.

[Marve79]

Toch apart je zou denken dat MS zelf een CA runt en die dingen automatisch worden vernieuwd.

[jaenster]

Al vermoed ik dat er bij hun wel lagen op lagen op lagen zijn bij de productie omgeving. En juist bij hun een CA enorm gevoelig is, stel je voor dat het certificaat van micorosoft uitlekt, voor welk domein dan ook. Daarnaast zijn er vast hordes mensen opzoek naar dergelijk certificaat.

Dus als je dit automatisch regelt, is dat juist veiliger omdat er geen mens aan te pas komt? Misschien. Aan de andere kant, hoeveel mensen kunnen bij het systeem die het automatiseerd? En staat er cruciale data in die automatisatie die benodigd is voor het maken/genereren/live zetten van een nieuw certificaat?

Links om of rechts om is het bij een MS of Google een gigantische opgave dit goed te doen, veel lastiger dan bij een of andere webshop die zijn certificaat fixt via zijn caching provider die het automatiseerd.

[GertMenkel]

De kans dat dit handmatig foutgegaan is, acht ik ongeveer gelijk aan 0. Ik denk eerder dat iemand een fout heeft gemaakt in de webserverconfiguratie die bepaalt welke hostnames er aan welk systeem gekoppeld moeten worden.

Je wilt juist niet dat je in de situatie komt dat "Emma van IT, die dit normaal regelt, op vakantie is" zoals je bij handmatige certificaatvernieuwingen ziet gebeuren. Een taak die één iemand in een team eens per twee jaar handmatig moet uitvoeren, is een taak die eens per twee jaar fout gaat.

[batjes]

Mijn ervaring is anders, in genoeg omgevingen gewerkt waar men de certificaten allemaal wel geautomatiseerd heeft, want handmatig is het in een beetje moderne omgeving met meer dan 5 werkplekken een dagtaak geworden.

Het blijft her en der gewoon fout gaan. Want er zijn zo ontzettend veel uitzonderingen, zo veel configuraties, zo veel details die je moet bijhouden en instellen.

Het blijft mensenwerk en foutgevoelig.

[Cergorach]

Toch apart je zou denken dat MS zelf een CA runt en die dingen automatisch worden vernieuwd.

Dit had niet veel te maken met vernieuwen als ik het zo lees (MS heeft het over een certificate update en een configuration issue), ze hebben een certificaat toegevoegd aan het verkeerde domein (of andersom).

[FONfanatic]

Als je browser een https-pagina niet weergeven wil is - nadat je het na de cache geleegd hebt opnieuw geprobeerd hebt - een check van de configuratie van de SSL/TLS-certificaten simpelweg uit te voeren via de servertest van het Australische bedrijf SSL Labs. Het duurt veelal wel een minuut of zes, maar dan heb je wel een heel uitgebreid rapport in handen.

[Reactie gewijzigd door FONfanatic op 24 juli 2024 05:09]

[Mel33]

Goh ik zat gisteren nog naar mijn tls settings te kijken in mijn browsers en windows internet settings. Zat ik er dichtbij iig.

[glennoo]

Verrassend. Ik had verwacht dat een partij als Microsoft dit toch wel helemaal stuk geautomatiseerd had.

[KingEd]

Haha, dat is ze dan ook gelukt.....STUK geautomatiseerd..

[Frame164]

Alles automatiseren is geen garantie dat er nooit wat fout gaat. Uiteindelijk is ook automatiseren mensenwerk. En als je denkt dat je aan alles gedacht hebt zijn er altijd situaties die niemand had voorzien. Als je ziet hoeveel er wel goed gaat bij complexe netwerken zoals die van Microsoft zullen ze het meeste wel in de vingers hebben en goed hebben geautomatiseerd.

[Nightan]

Ik ben verantwoordelijk voor de cryptografie bij een van de grootste bedrijven in Nederland. We hebben weinig publieke websites, dus het ACME-protocol i.c.m. met bijvoorbeeld Let's Encrypt is geen optie. Bij Microsoft lijkt dit wel het geval.

Certificate automation voor de private name space binnen een enterprise is een grote uitdaging. Als je corporate security policy port 80 standaard dichtzet, dan zijn ACME HTTP-01 challenges al geen optie meer.

DNS-01 is intern zo goed als onmogelijk. ACME en bijvoorbeeld Let's Encrypt, neemt aan dat de webserverbeheerder, tevens de hele DNS-zone beheert. Dat is natuurlijk niet het geval. Dit kun je niet zomaar openzetten zonder beheerders arbitraire DNS TXT-records te laten plaatsen.

Stel je voor dat ~2000 admins zomaar DMARC of SPF records kunnen aanpassen
Er zijn DNS-diensten zoals Azure die granulaire API-toegang bieden maar die zijn er niet veel, en nogsteeds een uitdaging.