Partage via

Modification des certificats Azure TLS

  • Article

Important

Cet article a été publié simultanément avec la modification du certificat TLS et n’est pas mis à jour. Pour plus d’informations sur les autorités de certification, consultez les détails de l’autorité de certification Azure.

Microsoft utilise des certificats TLS à partir de l’ensemble d’autorités de certification racines qui adhèrent aux réglementations de référence du CA/Browser Forum. Tous les points de terminaison Azure TLS/SSL contiennent des certificats liés aux autorités de certification racines fournies dans cet article. Les modifications apportées aux points de terminaison Azure ont commencé leur transition en août 2020 et certains services terminent leur mise à jour en 2022. Tous les points de terminaison Azure TLS/SSL nouvellement créés contiennent des certificats mis à jour, liés aux nouvelles autorités de certification racines.

Tous les services Azure sont affectés par cette modification. Les détails de certains services sont listés ci-dessous :

Qu’est ce qui a changé ?

Avant le changement, la plupart des certificats TLS utilisés par les services Azure étaient liés à l’autorité de certification racine suivante :

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

Après le changement, les certificats TLS utilisés par les services Azure seront liés à l’une des autorités de certification racines suivantes :

Nom commun de l’autorité de certification Empreinte (SHA1)
DigiCert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4
DigiCert Global Root CA a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436
Baltimore CyberTrust Root d4de20d05e66fc53fe1a50882c78db2852cae474
D-TRUST Root Class 3 CA 2 2009 58e8abb0361533fb80f79b1b6d29d3ff8d5f00f0
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Microsoft ECC Root Certificate Authority 2017 999a64c37ff47d9fab95f14769891460eec4c3c5

Mon application a-t-elle été affectée ?

Si votre application spécifie explicitement une liste d’autorités de certification acceptables, votre application a probablement été affectée. Cette pratique est appelée « épinglage de certificat ». Passez en revue l’article Microsoft Tech Community sur les modifications TLS du Stockage Azure pour plus d’informations sur la façon de déterminer si vos services ont été affectés et les étapes suivantes.

Voici quelques méthodes permettant de déterminer si votre application est impactée :

  • Recherchez dans votre code source l’empreinte, le nom commun ou d’autres propriétés de certificat de toutes les autorités de certification Microsoft IT TLS figurant dans le référentiel PKI Microsoft. En cas de correspondance, votre application sera impactée. Pour résoudre ce problème, mettez à jour le code source en incluant les nouvelles autorités de certification. Une bonne pratique consiste à vous assurer que les autorités de certification peuvent être ajoutées ou modifiées dans un court délai. Les réglementations du secteur exigent que les certificats d’autorité de certification soient remplacés dans les sept jours suivant la modification. Les clients qui s’appuient sur l’épinglage de certificats doivent donc réagir rapidement.

  • Si vous disposez d’une application qui s’intègre à des API Azure ou à d’autres services Azure et que vous ne savez pas si elle utilise l’épinglage de certificat, contactez le fournisseur de l’application.

  • Les différents systèmes d’exploitation et runtimes de langage qui communiquent avec les services Azure peuvent nécessiter des étapes supplémentaires pour générer correctement la chaîne de certificats avec ces nouvelles racines :

    • Linux : de nombreuses distributions vous obligent à ajouter des autorités de certification à /etc/ssl/certs. Pour obtenir des instructions spécifiques, reportez-vous à la documentation de la distribution.
    • Java : assurez-vous que le magasin de clés Java contient les autorités de certification listées ci-dessus.
    • Windows exécuté dans des environnements déconnectés : pour les systèmes qui s’exécutent dans des environnements déconnectés, de nouvelles racines doivent être ajoutées au magasin d’autorités de certification racines de confiance et les intermédiaires au magasin d’autorités de certification intermédiaires.
    • Android : consultez la documentation de votre appareil et de votre version d’Android.
    • Autres appareils, en particulier IoT : contactez le fabricant de l’appareil.

  • Si vous disposez d’un environnement dans lequel les règles de pare-feu sont configurées pour autoriser les appels sortants uniquement vers des emplacements de téléchargement de liste de révocation de certificats et/ou de vérification de protocole OCSP (Online Certificate Status Protocol) spécifiques, vous devez autoriser les URL correspondantes suivantes. Pour obtenir la liste complète des URL CRL et OCSP utilisées dans Azure, consultez l’article sur les détails de l’autorité de certification Azure.

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

Étapes suivantes

Si vous avez des questions, contactez-nous par le biais du support.