Ändringar i Azure TLS-certifikat
Viktigt!
Den här artikeln publicerades samtidigt med TLS-certifikatändringen och uppdateras inte. Uppdaterad information om certifikatutfärdare finns i Information om Azure Certificate Authority.
Microsoft använder TLS-certifikat från uppsättningen rotcertifikatutfärdare (CA) som följer kraven för CA/Browser-forumets baslinje. Alla Azure TLS/SSL-slutpunkter innehåller certifikat som är länkade till rotcertifikatutfärdare som anges i den här artikeln. Ändringar i Azure-slutpunkter började övergå i augusti 2020, och vissa tjänster slutförde sina uppdateringar 2022. Alla nyligen skapade Azure TLS/SSL-slutpunkter innehåller uppdaterade certifikat som kedjar ihop till de nya rotcertifikatutfärdarna.
Alla Azure-tjänster påverkas av den här ändringen. Information om vissa tjänster visas nedan:
- Microsoft Entra ID-tjänster (Microsoft Entra ID) påbörjade den här övergången den 7 juli 2020.
- Den senaste informationen om TLS-certifikatändringarna för Azure IoT-tjänster finns i det här Azure IoT-blogginlägget.
- Azure IoT Hub inledde övergången i februari 2023 med ett förväntat slutförande i oktober 2023.
- Azure IoT Central påbörjar den här övergången i juli 2023.
- Azure IoT Hub Device Provisioning Service påbörjar den här övergången i januari 2024.
- Azure Cosmos DB inledde övergången i juli 2022 med ett förväntat slutförande i oktober 2022.
- Information om ändringar av Azure Storage TLS-certifikat finns i det här blogginlägget om Azure Storage.
- Azure Cache for Redis flyttar från TLS-certifikat som utfärdats av Baltimore CyberTrust Root från och med maj 2022, enligt beskrivningen i den här artikeln om Azure Cache for Redis
- Azure Instance Metadata Service har ett förväntat slutförande i maj 2022, enligt beskrivningen i det här blogginlägget om Styrning och hantering av Azure.
Vad har ändrats?
Före ändringen är de flesta TLS-certifikat som används av Azure-tjänster länkade till följande rotcertifikatutfärdare:
| Certifikatmottagarens gemensamma namn | Tumavtryck (SHA1) |
|---|---|
| Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
Efter ändringen kedjar TLS-certifikat som används av Azure-tjänster upp till någon av följande rotcertifikatutfärdare:
| Certifikatmottagarens gemensamma namn | Tumavtryck (SHA1) |
|---|---|
| DigiCert Global Root G2 | df3c24f9bfd666761b268073fe06d1cc8d4f82a4 |
| DigiCert Global Root CA | a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436 |
| Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
| D-TRUST Rotklass 3 CA 2 2009 | 58e8abb0361533fb80f79b1b6d29d3ff8d5f00f0 |
| Microsoft RSA Root Certificate Authority 2017 | 73a5e64a3bff8316ff0edccc618a906e4eae4d74 |
| Microsoft ECC Root Certificate Authority 2017 | 999a64c37ff47d9fab95f14769891460eec4c3c5 |
Påverkades mitt program?
Om ditt program uttryckligen anger en lista över godtagbara certifikatutfärdare påverkades sannolikt ditt program. Den här metoden kallas för att fästa certifikat. Mer information om hur du avgör om dina tjänster påverkades och nästa steg finns i Microsoft Tech Community-artikeln om TLS-ändringar i Azure Storage.
Här följer några sätt att identifiera om programmet påverkades:
Sök i källkoden efter tumavtryck, eget namn och andra certifikategenskaper för någon av Microsoft IT-TLS-certifikatutfärdarna på Microsoft PKI-lagringsplatsen. Om det finns en matchning påverkas ditt program. För att lösa det här problemet uppdaterar du källkoden med de nya certifikatutfärdarna. Bästa praxis är att se till att certifikatutfärdare kan läggas till eller redigeras med kort varsel. Branschregler kräver att CA-certifikat ersätts inom sju dagar efter ändringen och därför måste kunder som förlitar sig på fästning reagera snabbt.
Om du har ett program som integreras med Azure-API:er eller andra Azure-tjänster och du är osäker på om det använder certifikatanslutning kontrollerar du med programleverantören.
Olika operativsystem och språkkörningar som kommunicerar med Azure-tjänster kan kräva fler steg för att skapa certifikatkedjan korrekt med dessa nya rötter:
- Linux: Många distributioner kräver att du lägger till certifikatutfärdare i /etc/ssl/certs. Specifika instruktioner finns i distributionens dokumentation.
- Java: Kontrollera att Java-nyckelarkivet innehåller de certifikatutfärdare som anges ovan.
- Windows körs i frånkopplade miljöer: System som körs i frånkopplade miljöer måste ha de nya rötterna tillagda i arkivet Betrodda rotcertifikatutfärdare och mellanliggande objekt som läggs till i mellanliggande certifikatutfärdararkiv.
- Android: Kontrollera dokumentationen för din enhet och version av Android.
- Andra maskinvaruenheter, särskilt IoT: Kontakta enhetstillverkaren.
Om du har en miljö där brandväggsregler har angetts för att tillåta utgående anrop till endast specifika crl-hämtningslistor (CRL) och/eller OCSP-verifieringsplatser (Online Certificate Status Protocol) måste du tillåta följande CRL- och OCSP-URL:er. En fullständig lista över CRL- och OCSP-URL:er som används i Azure finns i artikeln om Azure CA-information.
- http://crl3.digicert.com
- http://crl4.digicert.com
- http://ocsp.digicert.com
- http://crl.microsoft.com
- http://oneocsp.microsoft.com
- http://ocsp.msocsp.com
Nästa steg
Kontakta oss via support om du har frågor.