Modifications du certificat TLS Office

Article
08/12/2023

Microsoft 365 met à jour les services qui alimentent la messagerie, les réunions, la téléphonie, la voix et la vidéo pour utiliser des certificats TLS provenant d’un autre ensemble d’autorités de certification racines. Cette modification est apportée, car l’autorité de certification racine actuelle expirera en mai 2025.

Les produits concernés sont les suivants :

Microsoft Teams
Skype
Skype Entreprise Online
Microsoft Dynamics 365
GroupMe
Kaizala
Azure Communication Services

Les points de terminaison affectés incluent (sans s’y limiter) :

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

En outre, Teams et Skype Entreprise points de terminaison en ligne dans les instances de cloud national du gouvernement des États-Unis de Microsoft 365 apporteront la même modification, affectant les points de terminaison tels que :

*.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

Cette modification n’affecte pas les certificats, domaines ou services utilisés dans les instances cloud nationales de Microsoft 365 en Chine ou en Allemagne.

Toutes les informations de certificat contenues dans cet article ont été précédemment fournies dans les chaînes de chiffrement Microsoft 365 au plus tard en octobre 2020.

Conseil

Si vous n’êtes pas un client E5, utilisez la version d’évaluation de 90 jours des solutions Microsoft Purview pour découvrir comment des fonctionnalités Supplémentaires purview peuvent aider vos organization à gérer les besoins en matière de sécurité et de conformité des données. Commencez dès maintenant au hub d’essais portail de conformité Microsoft Purview. En savoir plus sur les conditions d’inscription et d’essai.

Quand ce changement se produira-t-il ?

Les services ont commencé à passer aux nouvelles autorités de certification racine en janvier 2022 et se poursuivront jusqu’en octobre 2022.

Qu’est-ce qui change ?

Aujourd’hui, la plupart des certificats TLS utilisés par les services Microsoft 365 sont liés à l’autorité de certification racine suivante :

Nom commun de l’autorité de certification	Empreinte numérique (SHA1)
Baltimore CyberTrust Root	d4de20d05e66fc53fe1a50882c78db2852cae474

avec l’une des autorités de certification intermédiaires suivantes :

Nom commun de l’autorité de certification	Empreinte numérique (SHA1)
Microsoft RSA TLS CA 01	703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02	b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Les nouveaux certificats TLS utilisés par les services Microsoft 365 sont désormais liés à l’une des autorités de certification racines suivantes :

Nom commun de l’autorité de certification	Empreinte numérique (SHA1)
DigiCert Global Root G2	df3c24f9bfd666761b268073fe06d1cc8d4f82a4
Microsoft RSA Root Certificate Authority 2017	73a5e64a3bff8316ff0edccc618a906e4eae4d74
Autorité de certification racine Microsoft ECC 2017	999a64c37ff47d9fab95f14769891460eec4c3c5

avec l’une des autorités de certification intermédiaires suivantes :

Nom commun de l’autorité de certification	Empreinte numérique (SHA1)
Microsoft Azure TLS émetteur ca 01	2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS émetteur CA 02	e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS émetteur CA 05	6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS Émetteur CA 06	30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Par exemple, il s’agit d’un certificat valide avec l’une des nouvelles chaînes de certificats :

Chaîne de certificats TLS Teams

Ce changement m’affectera-t-il ?

L’autorité de certification racine « DigiCert Global Root G2 » est largement approuvée par les systèmes d’exploitation, notamment Windows, macOS, Android et iOS, et par les navigateurs tels que Microsoft Edge, Chrome, Safari et Firefox. Nous nous attendons à ce que la plupart des clients Microsoft 365 ne soient pas affectés.

Toutefois, votre application peut être affectée si elle spécifie explicitement une liste d’autorités de certification acceptables. Cette pratique est appelée « épinglage de certificat ». Les clients qui n’ont pas les nouvelles autorités de certification racine dans leur liste d’autorités de certification acceptables recevront des erreurs de validation de certificat, ce qui peut avoir un impact sur la disponibilité ou la fonction de votre application.

Voici quelques façons de détecter si votre application est susceptible d’être impactée :

Recherchez dans votre code source l’empreinte numérique, le nom commun ou d’autres propriétés des autorités de certification intermédiaires disponibles ici. S’il existe une correspondance, votre application sera impactée. Pour résoudre ce problème, mettez à jour le code source pour ajouter les propriétés des nouvelles autorités de certification. En guise de meilleure pratique, assurez-vous que les autorités de certification peuvent être ajoutées ou modifiées dans un bref délai. Les réglementations du secteur exigent que les certificats d’autorité de certification soient remplacés dans les sept jours dans certaines circonstances, de sorte que les applications qui implémentent l’épinglage des certificats doivent réagir rapidement à ces modifications.
.NET expose les System.Net.ServicePointManager.ServerCertificateValidationCallback fonctions de rappel et System.Net.HttpWebRequest.ServerCertificateValidationCallback , qui permettent aux développeurs d’utiliser une logique personnalisée pour déterminer si les certificats sont valides au lieu de s’appuyer sur le magasin de certificats Windows standard. Un développeur peut ajouter une logique qui vérifie un nom commun ou une empreinte spécifique, ou autorise uniquement une autorité de certification racine spécifique telle que « Baltimore CyberTrust Root ». Si votre application utilise ces fonctions de rappel, vous devez vous assurer qu’elle accepte les autorités de certification racines et intermédiaires anciennes et nouvelles.
Les applications natives peuvent utiliser WINHTTP_CALLBACK_STATUS_SENDING_REQUEST, ce qui permet aux applications natives d’implémenter une logique de validation de certificat personnalisée. L’utilisation de cette notification est rare et nécessite une quantité importante de code personnalisé à implémenter. Comme pour ce qui précède, assurez-vous que votre application accepte les autorités de certification racines et intermédiaires anciennes et nouvelles.
Si vous utilisez une application qui s’intègre à Microsoft Teams, Skype, Skype Entreprise Online ou les API Microsoft Dynamics et que vous ne savez pas si elle utilise l’épinglage de certificat, case activée avec le fournisseur de l’application.
Différents systèmes d’exploitation et runtimes de langage qui communiquent avec les services Azure peuvent nécessiter d’autres étapes pour générer et valider correctement les nouvelles chaînes de certificats :
- Linux : de nombreuses distributions nécessitent l’ajout d’autorités de certification à /etc/ssl/certs. Pour obtenir des instructions spécifiques, reportez-vous à la documentation de la distribution.
- Java : vérifiez que le magasin de clés Java contient les autorités de certification répertoriées ci-dessus.
- Windows s’exécutant dans des environnements déconnectés : les systèmes s’exécutant dans des environnements déconnectés doivent avoir les nouvelles autorités de certification racine ajoutées à leur Trusted Root Certification Authorities magasin et les nouvelles autorités de certification intermédiaires ajoutées à leur Intermediate Certification Authorities magasin.
- Android : consultez la documentation de votre appareil et de votre version d’Android.
- Appareils IoT ou incorporés : les appareils incorporés tels que les décodeurs TV sont souvent fournis avec un ensemble limité de certificats d’autorité racine et n’ont aucun moyen simple de mettre à jour le magasin de certificats. Si vous écrivez du code ou gérez des déploiements d’appareils intégrés ou IoT personnalisés, assurez-vous que les appareils approuvent les nouvelles autorités de certification racine. Vous devrez peut-être contacter le fabricant de l’appareil.
Si vous avez un environnement où les règles de pare-feu autorisent les appels sortants uniquement vers des points de terminaison spécifiques, autorisez les URL suivantes de liste de révocation de certificats (CRL) ou de protocole OCSP (Online Certificate Status Protocol) :
- 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
Si vous êtes affecté par cette modification, vous pouvez voir des messages d’erreur dépendant du type d’environnement dans lequel vous vous exécutez et du scénario par lequel vous êtes affecté. Vérifiez les journaux des événements des applications Windows, les journaux des événements CAPI2 et les journaux des applications personnalisées pour les messages qui ressemblent à :
```
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.
```
Si vous utilisez un contrôleur de bordure de session, Microsoft a préparé un point de terminaison de test qui peut être utilisé pour vérifier que les appliances SBC approuvent les certificats émis à partir de la nouvelle autorité de certification racine. Ce point de terminaison doit être utilisé uniquement pour les messages ping SIP OPTIONS et non pour le trafic vocal.
```
Global FQDN: sip.mspki.pstnhub.microsoft.com 
Port: 5061
```
Si cela ne fonctionne pas normalement, contactez le fabricant de votre appareil pour déterminer si des mises à jour sont disponibles pour prendre en charge la nouvelle autorité de certification racine.

Quand puis-je mettre hors service les anciennes informations d’autorité de certification ?

L’autorité de certification racine, l’autorité de certification intermédiaire et les certificats feuille actuels ne seront pas révoqués. Les noms communs d’autorité de certification et/ou les empreintes numériques existants seront requis jusqu’en octobre 2023 au moins en fonction de la durée de vie des certificats existants.

Problèmes connus

Dans de très rares circonstances, les utilisateurs d’entreprise peuvent voir des erreurs de validation de certificat lorsque l’autorité de certification racine « DigiCert Global Root G2 » apparaît comme révoquée. Cela est dû à un bogue Windows connu dans les deux conditions suivantes :

L’autorité de certification racine se trouve dans le magasin de certificats CurrentUser\Root et les propriétés et sont NotBeforeEKU manquantesNotBeforeFileTime.
L’autorité de certification racine se trouve dans le magasin de certificats LocalMachine\AuthRoot, mais a les NotBeforeFileTime propriétés et NotBeforeEKU
L’autorité de certification racine n’est PAS dans le magasin de certificats LocalMachine\Root

Tous les certificats feuille émis à partir de cette autorité de certification racine une fois que le NotBeforeFileTime apparaît révoqué.

Les administrateurs peuvent identifier et résoudre le problème en inspectant le journal CAPI2 pour détecter cette erreur :

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>

Notez la présence de l’élément CERT_TRUST_IS_EXPLICIT_DISTRUST="true" .

Vous pouvez vérifier que deux copies de l’autorité de certification racine avec des propriétés différentes NotBeforeFileTime sont présentes en exécutant les commandes suivantes certutil et en comparant la sortie :

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

Un utilisateur peut résoudre le problème en supprimant la copie de l’autorité de certification racine dans le CurrentUser\Root magasin de certificats en procédant comme suit :

certutil -user -delstore root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4

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

La première approche crée une boîte de dialogue Windows dans laquelle un utilisateur doit cliquer, contrairement à la deuxième approche.