Wijzigingen in Azure TLS-certificaat
Belangrijk
Dit artikel is gepubliceerd gelijktijdig met de wijziging van het TLS-certificaat en wordt niet bijgewerkt. Zie de details van de Azure-certificeringsinstantie voor actuele informatie over CA's.
Microsoft maakt gebruik van TLS-certificaten uit de set basiscertificeringsinstanties (CA's) die voldoen aan de basislijnvereisten voor ca/browserforums. Alle Azure TLS/SSL-eindpunten bevatten certificaten die zijn gekoppeld aan de basis-CA's in dit artikel. Wijzigingen in Azure-eindpunten zijn in augustus 2020 begonnen met de overgang, waarbij sommige services hun updates in 2022 voltooien. Alle nieuw gemaakte Azure TLS/SSL-eindpunten bevatten bijgewerkte certificaten die zijn gekoppeld aan de nieuwe basis-CA's.
Alle Azure-services worden beïnvloed door deze wijziging. Hieronder vindt u details voor sommige services:
- Microsoft Entra ID-services (Microsoft Entra ID) begonnen met deze overgang op 7 juli 2020.
- Raadpleeg dit Azure IoT-blogbericht voor de meest recente informatie over de wijzigingen in het TLS-certificaat voor Azure IoT-services.
- Azure IoT Hub begon deze overgang in februari 2023 met een verwachte voltooiing in oktober 2023.
- Azure IoT Central begint met deze overgang in juli 2023.
- Azure IoT Hub Device Provisioning Service begint met deze overgang in januari 2024.
- Azure Cosmos DB begon deze overgang in juli 2022 met een verwachte voltooiing in oktober 2022.
- Meer informatie over wijzigingen in Azure Storage TLS-certificaten vindt u in dit Azure Storage-blogbericht.
- Azure Cache voor Redis wordt vanaf mei 2022 verwijderd van TLS-certificaten die zijn uitgegeven door Baltimore CyberTrust Root, zoals beschreven in dit Azure Cache voor Redis artikel
- Azure Instance Metadata Service heeft een verwachte voltooiing in mei 2022, zoals beschreven in dit blogbericht over Azure Governance en Beheer.
Wat is er veranderd?
Voorafgaand aan de wijziging zijn de meeste TLS-certificaten die door Azure-services worden gebruikt, gekoppeld aan de volgende basis-CA:
| Algemene naam van de CA | Vingerafdruk (SHA1) |
|---|---|
| Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
Na de wijziging worden TLS-certificaten die door Azure-services worden gebruikt, gekoppeld aan een van de volgende basis-CA's:
| Algemene naam van de CA | Vingerafdruk (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 |
Is mijn toepassing beïnvloed?
Als uw toepassing expliciet een lijst met acceptabele CA's opgeeft, is uw toepassing waarschijnlijk beïnvloed. Dit wordt certificaatkoppeling genoemd. Raadpleeg het Microsoft Tech Community-artikel over WIJZIGINGEN in Azure Storage TLS voor meer informatie over het bepalen of uw services zijn beïnvloed en de volgende stappen.
Hier volgen enkele manieren om te detecteren of uw toepassing is beïnvloed:
Zoek in uw broncode naar de vingerafdruk, algemene naam en andere certificaateigenschappen van een van de Microsoft IT TLS-CA's in de Microsoft PKI-opslagplaats. Als er een overeenkomst is, wordt uw toepassing beïnvloed. Als u dit probleem wilt oplossen, werkt u de broncode bij met de nieuwe CA's. Als best practice kunt u ervoor zorgen dat CA's op korte termijnen worden toegevoegd of bewerkt. Voor branchevoorschriften moeten CA-certificaten worden vervangen binnen zeven dagen na de wijziging en daarom moeten klanten die afhankelijk zijn van vastmaken, snel reageren.
Als u een toepassing hebt die is geïntegreerd met Azure-API's of andere Azure-services en u niet zeker weet of deze gebruikmaakt van certificaatpinning, neem dan contact op met de leverancier van de toepassing.
Voor verschillende besturingssystemen en taalruntimes die communiceren met Azure-services, zijn mogelijk meer stappen nodig om de certificaatketen correct te bouwen met deze nieuwe roots:
- Linux: Voor veel distributies moet u CA's toevoegen aan /etc/ssl/certs. Raadpleeg de documentatie van de distributie voor specifieke instructies.
- Java: Zorg ervoor dat het Java-sleutelarchief de hierboven vermelde CA's bevat.
- Windows die wordt uitgevoerd in niet-verbonden omgevingen: systemen die worden uitgevoerd in niet-verbonden omgevingen, moeten de nieuwe roots worden toegevoegd aan het archief vertrouwde basiscertificeringsinstanties en de tussenliggende verbindingen die zijn toegevoegd aan het archief van tussenliggende certificeringsinstanties.
- Android: Raadpleeg de documentatie voor uw apparaat en versie van Android.
- Andere hardwareapparaten, met name IoT: neem contact op met de fabrikant van het apparaat.
Als u een omgeving hebt waarin firewallregels zijn ingesteld om uitgaande aanroepen toe te staan voor alleen specifieke CRL-download- en/of OCSP-verificatielocaties (Online Certificate Status Protocol), moet u de volgende CRL- en OCSP-URL's toestaan. Zie het artikel over azure-CA-details voor een volledige lijst met CRL- en OCSP-URL's die worden gebruikt in 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
Volgende stappen
Neem contact met ons op via ondersteuning als u vragen hebt.