Exchange 2016/2019 Mitigation Service Error 1008 wegen abgelaufenem Zertifikat

Exchange Logo[English]Heute noch eine Information für Administratoren von Microsoft Exchange-Servern, die diese Woche plötzlich einen Error 1008 unter Exchange 2016 oder 2019 in den Ereignis-Logs erhalten, der vom Mitigation Service ausgelöst wird. Ein Blog-Leser hat mich die Tage auf diesen Sachverhalt aufmerksam gemacht, weil das Problem bei ihm plötzlich unter Microsoft Exchange Server 2019 auftrat. Hintergrund ist ein am 9. Juni 2022 abgelaufenes Microsoft "Microsoft Exchange XML Signing" Zertifikat. Das Problem sollte aber inzwischen Service-seitig durch Microsoft behoben worden sein.


Anzeige

Mitigation Service Error 1008 in Log-Files

Blog-Leser Phil Randal hat mich zum 14. Juni 2022 per E-Mail kontaktiert und wies mich darauf hin, dass unter Microsoft Exchange (bei ihm war es Exchange 2019) plötzlich der Mitigation Service Error 1008 in den Application-Logs der Ereignisanzeige auftreten könne.

Hi Gunter,

Noticing Application log error 1008 on our exchange servers:

"Exception encountered while fetching mitigations : System.Exception: This XML is not deemed safe to consume since  Response xml's signing cert is invalid or not from Microsoft"

Exchange Server stellt einen Ausnahmefehler bei der Anwendung von Mitigation-Maßnahmen fest und meldet, dass eine XML-Datei nicht sicher verwendet werden kann, da das Signierzertifikat von Response xml ungültig ist oder nicht von Microsoft stammt. Phil verwies mich dann auf einen reddit.com-Thread Mitigation Service XML errors since CU23 upgrade, wo das ebenfalls thematisiert wird.

Mitigation Service XML errors since CU23 upgrade

Good morning!

Since the upgrade to 2016 CU23, I've noticed several machines are throwing a new XML error regarding the Mitigation Service (EEM). We've been running 2016 CU22 on various clients with no issues and this error was never present. Since the upgrade to CU23, we're seeing this all over the place.

Microsoft Forums seem to suggest this is the result of a network connection being blocked to the IPs used by EEM. But the only thing that has changed is installing CU23, there's nothing new blocking these connections.

Testing the Mitigation Service passes fine. I'm able to access the URL for the mitigations just fine from these machines in a web browser. Clearly, nothing is being blocked.

Here's the full error:

An unexpected exception occurred. Diagnostic information: 
Exception encountered while fetching mitigations:
System.Exception: This XML is not deemed safe to consume since Response
xml's signing cert is invalid or notfrom microsoft at

Microsoft.Exchange.Mitigation.Service.Common.SignatureVerifierUtils.ThrowIfIntegrityChecksFail(SafeXmlDocument xmlDoc) at Microsoft.Exchange.Mitigation.Service.Common.SignatureVerifierUtils.GetValidatedDocumentWithoutSignature(SafeXmlDocument xmlDoc) at Microsoft.Exchange.Mitigation.Service.Common.Utils.FetchDataFromXmlStream[T](Stream stream) at Microsoft.Exchange.Mitigation.Service.Common.Utils.FetchMitigationsFromUrl[T](String url, RemoteCertificateValidationCallback certValidationCallback, X509Certificate clientAuthCert, Boolean isResponseJson) at Microsoft.Exchange.Mitigation.Service.MitigationCloudServiceV2.FetchMitigations() at Microsoft.Exchange.Mitigation.Service.Mitigations.MitigationEngine.FetchAndApplyMitigation()

Auch bei Microsoft Q&A gibt es den Eintrag Exchange 2019 Mitigation service error 1008, in dem ein Betroffener das Problem anspricht.

Exchange 2019 Mitigation service error 1008

Hi,
I regularly receive error 1008
Exception encountered while fetching mitigations : System.Exception: This XML is not deemed safe to consume since Response xml's signing cert is invalid or not from microsoft

The issue started June 9.

Any suggestions?

King regards,
Dmitry

Zertifikat bei Microsoft abgelaufen

Ein Microsoft-Mitarbeiter hat sich dann auf reddit.com gemeldet und schrieb, dass der Fehler nichts mit dem CU23 zu tun habe, sondern mit einem abgelaufenen Zertifikat auf der Seite des Dienstes – das Zertifikat ist am 9. Juni 20222 abgelaufen. Microsoft arbeite daran, das service-seitig zu beheben (Admins müssen nichts tun). Das Problem sei im Moment nur kosmetisch, und Microsoft habe keine Notfallmaßnahmen veröffentlicht.

Beim Q&A-Eintrag Exchange 2019 Mitigation service error 1008 verweist jemand auf diesen Beitrag bei The Register.  Dort wurde am 10. Juni 2022 berichtet, dass Microsoft vergessen habe, das Zertifikat für die Windows Insider-Webseite zu erneuern. Besucher erhielten dann die Meldung "Ihre Verbindung ist nicht privat".


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Software, Störung abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

6 Antworten zu Exchange 2016/2019 Mitigation Service Error 1008 wegen abgelaufenem Zertifikat

  1. Olli sagt:

    Liebe IT-Produkte-Hersteller,

    wenn ihr schon nicht in der Lage seit sicher zu stellen, dass Zertifikate rechtzeitig erneuert werden, dann setzt deren gültig bitte wieder auf fünf besser zehn Jahre, dann passiert es nicht wenigstens so oft. Andererseits könnten ihr auch gefälligst alles unter einer einzige Domain abwickeln was jeweils eine Firma betrifft, dann langt ein einziges Wildcard-Zertifikat für alles! Und wenn das dann abläuft – Kopfschuss…

    Danke

    • JohnRipper sagt:

      Ja diesen Domain Wildwuchs verstehe ich auch nicht. Das verstehe ich schon bei Office Online 365 nicht, wo jeder Dienst gefühlt unter einer anderen Domain läuft, sodass ein nicht geübter Anwender irgendwelche Phising Seiten nicht erkennen würde, selbst wenn es groß draufsteht.

      Für Administratoren wird es nicht schwieriger, wenn man die AutoUpdate Funktionen verwenden möchte, die dann einfach Random Domains verwenden. Vgl. OneDrive mit "oneclient.sfx.ms" (uA).

    • Michael sagt:

      Bloß nicht alles unter einer Domain. Was machst wenn du nur gewisse Services whitelisten willst oder wenn dein Wildcard certificate kompromittiert wurde? Dann ist alles im argen…ne Danke das ist die Low Budget Spar Notlösung, wenn security nicht so eine große Rolle spielt.

      • Olli sagt:

        Falsch. Gerade wegen Security ist das wichtig.

        Wenn alles was mit MS zu tu hat unterhalb von microsoft.com liegt ist das sicher zu handhaben.

        Wenn ich aber erst überlegen muss ob onedrive.com jetzt Microsoft gehört oder ne Phising Domain ist, ist dass das Gegenteil von Sicherheit. Bei onedrive.microsoft.com ist das sofort klar.

        Services trennen geht dann eben Subdomains. Alles andere ist Mist. Und wem sein Zertifikat abhanden kommt…

        • Anonymous sagt:

          wenn dann wäre
          onedrive.microsoft.com
          office.microsoft.com
          skype.microsoft.com
          windowsupdate.microsoft.com
          usw usw sinnvoll
          meinetwegen mit jeweils eigenen certs pro subdomain
          aber so wüsste man auf einen blick wo es hingehort.
          bei den ganzen einzeldomains haben sich doch nur wieder die marketingleute durchgesetzt

  2. Sektorsync sagt:

    Guten Morgen!

    Wir hatten dieses problem auch, um den 14.06. herum.

    Ist bei uns am 15.06. nicht mehr aufgetreten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.