Office TLS-Zertifikatänderungen

Microsoft 365 aktualisiert Dienste, die Messaging, Besprechungen, Telefonie, Sprache und Video unterstützen, um TLS-Zertifikate aus einer anderen Gruppe von Stammzertifizierungsstellen (CAs) zu verwenden. Diese Änderung wird vorgenommen, da die aktuelle Stammzertifizierungsstelle im Mai 2025 abläuft.

Zu den betroffenen Produkten gehören:

• Microsoft Teams
• Skype
• Skype for Business Online
• Microsoft Dynamics 365
• GroupMe
• Kaizala
• Azure Communication Services

Zu den betroffenen Endpunkten gehören (aber nicht beschränkt auf):

• *.teams.microsoft.com
• *.skype.com
• *.skypeforbusiness.com
• *.groupme.com
• *.communication.azure.com
• *.operatorconnect.microsoft.com

Darüber hinaus nehmen Teams und Skype for Business Online-Endpunkte in nationalen Cloudinstanzen von Microsoft 365 der US-Regierung die gleiche Änderung vor, was sich auf Endpunkte auswirkt, z. B.:

• *.gcc.teams.microsoft.com
• *.dod.teams.microsoft.us
• *.gov.teams.microsoft.us
• *.online.dod.skypeforbusiness.us
• *.online.gov.skypeforbusiness.us
• *.um-dod.office365.us
• *.um.office365.us

Diese Änderung wirkt sich nicht auf Zertifikate, Domänen oder Dienste aus, die in den nationalen Cloudinstanzen von Microsoft 365 in China oder Deutschland verwendet werden.

Alle Zertifikatinformationen in diesem Artikel wurden zuvor spätestens im Oktober 2020 in Microsoft 365-Verschlüsselungsketten bereitgestellt.

Tipp

Wenn Sie kein E5-Kunde sind, verwenden Sie die 90-tägige Testversion von Microsoft Purview-Lösungen, um zu erfahren, wie zusätzliche Purview-Funktionen Ihre organization die Verwaltung von Datensicherheits- und Complianceanforderungen unterstützen können. Beginnen Sie jetzt im Microsoft Purview-Complianceportal Testversionshub. Erfahren Sie mehr über die Anmelde- und Testbedingungen.

Wann wird diese Änderung stattfinden?

Dienste haben im Januar 2022 mit der Umstellung auf die neuen Stammzertifizierungsstellen begonnen und werden bis Oktober 2022 fortgesetzt.

Was ändert sich?

Heute werden die meisten TLS-Zertifikate, die von Microsoft 365-Diensten verwendet werden, bis zur folgenden Stammzertifizierungsstelle verkettet:

Allgemeiner Name der Zertifizierungsstelle	Fingerabdruck (SHA1)
Baltimore CyberTrust Root	d4de20d05e66fc53fe1a50882c78db2852cae474

mit einer der folgenden Zwischenzertifizierungsstellen:

Allgemeiner Name der Zertifizierungsstelle	Fingerabdruck (SHA1)
Microsoft RSA TLS CA 01	703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02	b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Neue TLS-Zertifikate, die von Microsoft 365-Diensten verwendet werden, werden jetzt bis zu einer der folgenden Stammzertifizierungsstellen verkettet:

Allgemeiner Name der Zertifizierungsstelle	Fingerabdruck (SHA1)
DigiCert Global Root G2	df3c24f9bfd666761b268073fe06d1cc8d4f82a4
Microsoft RSA-Stammzertifizierungsstelle 2017	73a5e64a3bff8316ff0edccc618a906e4eae4d74
Microsoft ECC-Stammzertifizierungsstelle 2017	999a64c37ff47d9fab95f14769891460eec4c3c5

mit einer der folgenden Zwischenzertifizierungsstellen:

Allgemeiner Name der Zertifizierungsstelle	Fingerabdruck (SHA1)
Microsoft Azure TLS Issuing CA 01	2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS Issuing CA 02	e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS Issuing CA 05	6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS Issuing CA 06	30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Dies ist beispielsweise ein gültiges Zertifikat mit einer der neuen Zertifikatketten:

Wirkt sich diese Änderung auf mich aus?

Die Stammzertifizierungsstelle "DigiCert Global Root G2" ist von Betriebssystemen wie Windows, macOS, Android und iOS sowie von Browsern wie Microsoft Edge, Chrome, Safari und Firefox weit verbreitet vertrauenswürdig. Wir gehen davon aus, dass die meisten Microsoft 365-Kunden davon nicht betroffen sind.

Ihre Anwendung kann jedoch beeinträchtigt werden, wenn sie explizit eine Liste zulässiger Zertifizierungsstellen angibt. Diese Vorgehensweise wird als "Anheften von Zertifikaten" bezeichnet. Kunden, die nicht über die neuen Stammzertifizierungsstellen in ihrer Liste der zulässigen Zertifizierungsstellen verfügen, erhalten Zertifikatüberprüfungsfehler, die sich auf die Verfügbarkeit oder Funktion Ihrer Anwendung auswirken können.

Im Folgenden finden Sie einige Möglichkeiten, um zu erkennen, ob Ihre Anwendung möglicherweise betroffen ist:

• Durchsuchen Sie Ihren Quellcode nach dem Fingerabdruck, dem allgemeinen Namen oder anderen Eigenschaften einer der hier gefundenen Zwischenzertifizierungsstellen. Wenn eine Übereinstimmung vorhanden ist, ist Ihre Anwendung betroffen. Um dieses Problem zu beheben, aktualisieren Sie den Quellcode, um die Eigenschaften der neuen Zertifizierungsstellen hinzuzufügen. Als bewährte Methode sollten Sie sicherstellen, dass Zertifizierungsstellen kurzfristig hinzugefügt oder bearbeitet werden können. Branchenbestimmungen erfordern, dass Zertifizierungsstellenzertifikate unter bestimmten Umständen innerhalb von sieben Tagen ersetzt werden, sodass Anwendungen, die das Anheften von Zertifikaten implementieren, schnell auf diese Änderungen reagieren müssen.

• .NET macht die System.Net.ServicePointManager.ServerCertificateValidationCallback Rückruffunktionen und System.Net.HttpWebRequest.ServerCertificateValidationCallback verfügbar, mit denen Entwickler mithilfe benutzerdefinierter Logik ermitteln können, ob Zertifikate gültig sind, anstatt sich auf den Standardmäßigen Windows-Zertifikatspeicher zu verlassen. Ein Entwickler kann Logik hinzufügen, die nach einem bestimmten allgemeinen Namen oder Fingerabdruck sucht oder nur eine bestimmte Stammzertifizierungsstelle wie "Baltimore CyberTrust Root" zulässt. Wenn Ihre Anwendung diese Rückruffunktionen verwendet, sollten Sie sicherstellen, dass sie sowohl die alten als auch die neuen Stamm- und Zwischenzertifizierungsstellen akzeptiert.

• Native Anwendungen verwenden WINHTTP_CALLBACK_STATUS_SENDING_REQUESTmöglicherweise , wodurch native Anwendungen benutzerdefinierte Zertifikatüberprüfungslogik implementieren können. Die Verwendung dieser Benachrichtigung ist selten und erfordert eine erhebliche Menge an benutzerdefiniertem Code, der implementiert werden muss. Stellen Sie ähnlich wie oben sicher, dass Ihre Anwendung sowohl die alten als auch die neuen Stamm- und Zwischenzertifizierungsstellen akzeptiert.

• Wenn Sie eine Anwendung verwenden, die in Microsoft Teams, Skype, Skype for Business Online oder Microsoft Dynamics-APIs integriert ist, und Sie sich nicht sicher sind, ob das Anheften von Zertifikaten verwendet wird, wenden Sie sich an den Anwendungsanbieter.

• Für verschiedene Betriebssysteme und Sprachruntimes, die mit Azure-Diensten kommunizieren, sind möglicherweise andere Schritte erforderlich, um die neuen Zertifikatketten ordnungsgemäß zu erstellen und zu überprüfen:

  • Linux: Für viele Distributionen müssen Sie Zertifizierungsstellen zu /etc/ssl/certshinzufügen. Spezifische Anweisungen finden Sie in der Dokumentation der Distribution.
  • Java: Stellen Sie sicher, dass der Java-Schlüsselspeicher die oben aufgeführten Zertifizierungsstellen enthält.
  • Windows wird in nicht verbundenen Umgebungen ausgeführt: Auf Systemen, die in nicht verbundenen Umgebungen ausgeführt werden, müssen die neuen Stammzertifizierungsstellen ihrem Trusted Root Certification Authorities Speicher und den neuen Zwischenzertifizierungsstellen hinzugefügt Intermediate Certification Authorities werden.
  • Android: Lesen Sie die Dokumentation für Ihr Gerät und Ihre Android-Version.
  • IoT oder eingebettete Geräte: Eingebettete Geräte wie TV-Set-Top-Boxen werden häufig mit einem begrenzten Satz von Stammzertifizierungsstellenzertifikaten ausgeliefert und haben keine einfache Möglichkeit, den Zertifikatspeicher zu aktualisieren. Wenn Sie Code für benutzerdefinierte eingebettete oder IoT-Geräte schreiben oder Bereitstellungen von benutzerdefinierten Geräten verwalten, stellen Sie sicher, dass die Geräte den neuen Stammzertifizierungsstellen vertrauen. Möglicherweise müssen Sie sich an den Gerätehersteller wenden.

• Wenn Sie über eine Umgebung verfügen, in der Firewallregeln ausgehende Aufrufe nur an bestimmte Endpunkte zulassen, lassen Sie die folgenden URLs der Zertifikatsperrliste (Certificate Revocation List, CRL) oder OCSP -URLs (Online Certificate Status Protocol) zu:

  • http://crl3.digicert.com
  • http://crl4.digicert.com
  • http://ocsp.digicert.com
  • http://crl.microsoft.com
  • http://oneocsp.microsoft.com
  • http://ocsp.msocsp.com
  • http://www.microsoft.com/pkiops

• Wenn Sie von dieser Änderung betroffen sind, werden möglicherweise Fehlermeldungen angezeigt, die vom Typ der Umgebung, in der Sie ausgeführt werden, und dem Szenario, von dem Sie betroffen sind, abhängig sind. Überprüfen Sie Windows-Anwendungsereignisprotokolle, CAPI2-Ereignisprotokolle und benutzerdefinierte Anwendungsprotokolle auf Meldungen, die wie folgt aussehen:

  An operation failed because the following certificate has validation errors:
  
  Subject Name: CN=teams.microsoft.com
  Issuer Name: CN=Microsoft Azure TLS Issuing CA 01, O=Microsoft Corporation, C=US
  
  Errors:
  
  The root of the certificate chain is not a trusted root authority.
  

• Wenn Sie einen Session Border Controller verwenden, hat Microsoft einen Testendpunkt vorbereitet, mit dem überprüft werden kann, ob SBC-Appliances Zertifikaten vertrauen, die von der neuen Stammzertifizierungsstelle ausgestellt wurden. Dieser Endpunkt sollte nur für SIP OPTIONS-Pingnachrichten und nicht für Sprachdatenverkehr verwendet werden.

  Global FQDN: sip.mspki.pstnhub.microsoft.com 
  Port: 5061
  

  Wenn dies nicht normal funktioniert, wenden Sie sich an den Gerätehersteller, um zu ermitteln, ob Updates zur Unterstützung der neuen Stammzertifizierungsstelle verfügbar sind.

Wann kann ich die alten ZS-Informationen außer Betrieb nehmen?

Die aktuelle Stammzertifizierungsstelle, die Zwischenzertifizierungsstelle und die untergeordneten Zertifikate werden nicht widerrufen. Die vorhandenen allgemeinen Zertifizierungsstellennamen und/oder Fingerabdrücke sind mindestens bis Oktober 2023 erforderlich, basierend auf der Lebensdauer vorhandener Zertifikate.

Bekannte Probleme

Unter sehr seltenen Umständen werden Unternehmensbenutzern möglicherweise Fehler bei der Zertifikatüberprüfung angezeigt, bei denen die Stammzertifizierungsstelle "DigiCert Global Root G2" als widerrufen angezeigt wird. Dies ist auf einen bekannten Windows-Fehler unter den beiden folgenden Bedingungen zurückzuführen:

• Die Stammzertifizierungsstelle befindet sich im Zertifikatspeicher CurrentUser\Root, und die Eigenschaften und NotBeforeEKU fehlen.NotBeforeFileTime
• Die Stammzertifizierungsstelle befindet sich im Zertifikatspeicher LocalMachine\AuthRoot, verfügt aber über die NotBeforeFileTime Eigenschaften und NotBeforeEKU
• Die Stammzertifizierungsstelle befindet sich NICHT im LocalMachine\Root-Zertifikatspeicher.

Alle untergeordneten Zertifikate, die von dieser Stammzertifizierungsstelle nach dem ausgestellt werden, NotBeforeFileTime werden als widerrufen angezeigt.

Administratoren können das Problem identifizieren und beheben, indem sie das CAPI2-Protokoll auf diesen Fehler überprüfen:

Log Name:      Microsoft-Windows-CAPI2/Operational
Source:        Microsoft-Windows-CAPI2
Date:          6/23/2022 8:36:39 AM
Event ID:      11
Task Category: Build Chain
Level:         Error
[...]
        <ChainElement>
          <Certificate fileRef="DF3C24F9BFD666761B268073FE06D1CC8D4F82A4.cer" subjectName="DigiCert Global Root G2" />
          [...]
          <TrustStatus>
            <ErrorStatus value="4000024" CERT_TRUST_IS_REVOKED="true" CERT_TRUST_IS_UNTRUSTED_ROOT="true" CERT_TRUST_IS_EXPLICIT_DISTRUST="true" />
            <InfoStatus value="10C" CERT_TRUST_HAS_NAME_MATCH_ISSUER="true" CERT_TRUST_IS_SELF_SIGNED="true" CERT_TRUST_HAS_PREFERRED_ISSUER="true" />
          </TrustStatus>
          [...]
          <RevocationInfo freshnessTime="PT0S">
            <RevocationResult value="80092010">The certificate is revoked.</RevocationResult>
          </RevocationInfo>
        </ChainElement>
      </CertificateChain>
      <EventAuxInfo ProcessName="Teams.exe" />
      <Result value="80092010">The certificate is revoked.</Result>

Beachten Sie das Vorhandensein des CERT_TRUST_IS_EXPLICIT_DISTRUST="true" -Elements.

Sie können bestätigen, dass zwei Kopien der Stammzertifizierungsstelle mit unterschiedlichen NotBeforeFileTime Eigenschaften vorhanden sind, indem Sie die folgenden certutil Befehle ausführen und die Ausgabe vergleichen:

certutil -store -v authroot DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
certutil -user -store -v root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4

Ein Benutzer kann das Problem beheben, indem er die Kopie der Stammzertifizierungsstelle im CurrentUser\Root Zertifikatspeicher wie folgt löscht:

certutil -user -delstore root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4

oder

reg delete HKCU\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates\DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 /f

Der erste Ansatz erstellt ein Windows-Dialogfeld, durch das ein Benutzer klicken muss, während der zweite Ansatz dies nicht tut.