Azure TLS-tanúsítványváltozások
Fontos
Ez a cikk a TLS-tanúsítvány módosításával egyidejűleg lett közzétéve, és nem frissül. A hitelesítésszolgáltatókkal kapcsolatos naprakész információkért tekintse meg az Azure Hitelesítésszolgáltató adatait.
A Microsoft a hitelesítésszolgáltatói/böngészőfórum alapkonfigurációs követelményeinek megfelelő legfelső szintű hitelesítésszolgáltatóktól származó TLS-tanúsítványokat használ. Minden Azure TLS/SSL-végpont tartalmaz olyan tanúsítványokat, amelyek a cikkben megadott legfelső szintű hitelesítésszolgáltatókhoz láncolnak. Az Azure-végpontok módosítása 2020 augusztusában kezdődött, egyes szolgáltatások 2022-ben fejezték be a frissítéseiket. Minden újonnan létrehozott Azure TLS/SSL-végpont frissített tanúsítványokat tartalmaz, amelyek az új legfelső szintű hitelesítésszolgáltatókhoz kapcsolódnak.
Ez a változás minden Azure-szolgáltatást érint. Néhány szolgáltatás részletei az alábbiakban találhatók:
- A Microsoft Entra ID (Microsoft Entra ID) szolgáltatások 2020. július 7-én kezdték meg ezt az átállást.
- Az Azure IoT-szolgáltatások TLS-tanúsítványváltozásával kapcsolatos legfrissebb információkért tekintse meg ezt az Azure IoT-blogbejegyzést.
- Az Azure IoT Hub 2023 februárjában kezdte meg ezt az átállást, 2023 októberében várható befejezéssel.
- Az Azure IoT Central 2023 júliusában kezdi meg az átállást.
- Az Azure IoT Hub Device Provisioning Service 2024 januárjában kezdi meg ezt az átállást.
- Az Azure Cosmos DB 2022 júliusában kezdte meg ezt az átállást, és 2022 októberében várható befejezést várt.
- Az Azure Storage TLS-tanúsítványmódosításairól ebben az Azure Storage-blogbejegyzésben olvashat.
- Az Azure Cache for Redis 2022 májusától távolodik a Baltimore CyberTrust Root által kibocsátott TLS-tanúsítványoktól, amint az az Azure Cache for Redis jelen cikkében olvasható
- Az Azure Instance Metadata Service várhatóan 2022 májusában fejeződik be az Azure Governance and Management blogbejegyzésben leírtak szerint.
Mi változott?
A módosítás előtt az Azure-szolgáltatások által használt TLS-tanúsítványok többsége a következő legfelső szintű hitelesítésszolgáltatóhoz van láncolva:
| A hitelesítésszolgáltató köznapi neve | Ujjlenyomat (SHA1) |
|---|---|
| Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
A módosítás után az Azure-szolgáltatások által használt TLS-tanúsítványok az alábbi legfelső szintű hitelesítésszolgáltatók egyikéhez láncolnak:
| A hitelesítésszolgáltató köznapi neve | Ujjlenyomat (SHA1) |
|---|---|
| DigiCert Global Root G2 | df3c24f9bfd666761b268073fe06d1cc8d4f82a4 |
| DigiCert globális legfelső szintű hitelesítésszolgáltató | a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436 |
| Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
| D-TRUST root class 3 CA 2 2009 | 58e8Abb0361533fb80f79b1b6d29d3ff8d5f00f0 |
| Microsoft RSA főtanúsítvány-szolgáltató 2017 | 73a5e64a3bff8316ff0edccc618a906e4eae4d74 |
| Microsoft ECC főtanúsítvány-szolgáltató 2017 | 999a64c37ff47d9fab95f14769891460eec4c3c5 |
Érintette az alkalmazásom?
Ha az alkalmazás kifejezetten megadja az elfogadható hitelesítésszolgáltatók listáját, az alkalmazás valószínűleg érintett volt. Ezt a gyakorlatot tanúsítvány-rögzítésnek nevezzük. Tekintse át a Microsoft Tech Community Azure Storage TLS-módosításairól szóló cikkét, amelyből megtudhatja, hogyan állapíthatja meg, hogy a szolgáltatások érintettek-e, valamint a következő lépéseket.
Az alábbiakban bemutatunk néhány módszert annak észlelésére, hogy az alkalmazás érintett volt-e:
Keressen rá a forráskódban a Microsoft PKI-adattár bármely Microsoft IT TLS-hitelesítésszolgáltatójának ujjlenyomatára, köznapi nevére és egyéb tanúsítványtulajdonságára. Ha van egyezés, az alkalmazásra hatással lesz. A probléma megoldásához frissítse a forráskódot az új hitelesítésszolgáltatókra is. Ajánlott eljárásként győződjön meg arról, hogy a hitelesítésszolgáltatók rövid időn belül hozzáadhatók vagy szerkeszthetők. Az iparági előírások megkövetelik, hogy a ca-tanúsítványokat a változástól számított hét napon belül lecserélik, ezért a rögzítésre támaszkodó ügyfeleknek gyorsan kell reagálniuk.
Ha olyan alkalmazással rendelkezik, amely integrálható az Azure API-kkal vagy más Azure-szolgáltatásokkal, és nem biztos abban, hogy tanúsítvány-rögzítést használ-e, forduljon az alkalmazás gyártójához.
Az Azure-szolgáltatásokkal kommunikáló különböző operációs rendszerek és nyelvi futtatókörnyezetek további lépéseket igényelhetnek a tanúsítványlánc megfelelő összeállításához az alábbi új gyökerekkel:
- Linux: Számos disztribúció esetén a hitelesítésszolgáltatókat hozzá kell adni a /etc/ssl/certs rendszerekhez. A konkrét utasításokért tekintse meg a terjesztési dokumentációt.
- Java: Győződjön meg arról, hogy a Java-kulcstároló tartalmazza a fent felsorolt hitelesítésszolgáltatókat.
- Leválasztott környezetekben futó Windows: A leválasztott környezetekben futó rendszereknek hozzá kell adni az új gyökereket a Megbízható legfelső szintű hitelesítésszolgáltatók tárolóhoz, a közteseket pedig hozzá kell adni a köztes hitelesítésszolgáltatók tárolóhoz.
- Android: Ellenőrizze az eszköz és az Android verziójának dokumentációját.
- Egyéb hardvereszközök, különösen az IoT: Lépjen kapcsolatba az eszköz gyártójától.
Ha olyan környezettel rendelkezik, ahol a tűzfalszabályok úgy vannak beállítva, hogy csak adott tanúsítvány-visszavonási lista (CRL) letöltési és/vagy online tanúsítványállapot-protokoll (OCSP) ellenőrzési helyekre irányuló kimenő hívásokat engedélyezzenek, engedélyeznie kell a következő CRL- és OCSP-URL-címeket. Az Azure-ban használt CRL- és OCSP-URL-címek teljes listáját az Azure CA részletes cikkében találja.
- http://crl3.digicert.com
- http://crl4.digicert.com
- http://ocsp.digicert.com
- http://crl.microsoft.com
- http://oneocsp.microsoft.com
- http://ocsp.msocsp.com
Következő lépések
Ha kérdése van, forduljon hozzánk az ügyfélszolgálaton keresztül.