Modifications du certificat TLS Office
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 :
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 etSystem.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 à leurIntermediate 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.
- Linux : de nombreuses distributions nécessitent l’ajout d’autorités de certification à
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 etNotBeforeEKU
- 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
ou
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.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour