Condividi tramite

Modifiche ai certificati TLS di Azure

  • Articolo

Importante

Questo articolo è stato pubblicato contemporaneamente alla modifica del certificato TLS e non viene aggiornato. Per informazioni aggiornate sulle ca, vedere Dettagli dell'autorità di certificazione di Azure.

Microsoft usa i certificati TLS del set di autorità di certificazione radice (CA) che rispettano i requisiti di base del forum ca/browser. Tutti gli endpoint TLS/SSL di Azure contengono certificati concatenati fino alle ca radice fornite in questo articolo. Nel mese di agosto 2020 sono state apportate modifiche agli endpoint di Azure, con alcuni servizi che completano gli aggiornamenti nel 2022. Tutti gli endpoint TLS/SSL di Azure appena creati contengono certificati aggiornati concatenati alle nuove CA radice.

Tutti i servizi di Azure sono interessati da questa modifica. Di seguito sono elencati i dettagli per alcuni servizi:

  • I servizi Microsoft Entra ID (Microsoft Entra ID) hanno iniziato questa transizione il 7 luglio 2020.
  • Per informazioni aggiornate sulle modifiche al certificato TLS per i servizi Azure IoT, vedere questo post di blog di Azure IoT.
    • hub IoT di Azure iniziato questa transizione nel febbraio 2023 con un completamento previsto nell'ottobre 2023.
    • Azure IoT Central inizierà questa transizione a luglio 2023.
    • hub IoT di Azure servizio Device Provisioning inizierà questa transizione a gennaio 2024.
  • Azure Cosmos DB ha iniziato questa transizione a luglio 2022 con un completamento previsto nell'ottobre 2022.
  • Per informazioni dettagliate sulle modifiche Archiviazione di Azure certificato TLS, vedere questo post di blog di Archiviazione di Azure.
  • cache di Azure per Redis si sta allontanando dai certificati TLS rilasciati da Baltimore CyberTrust Root a partire da maggio 2022, come descritto in questo articolo cache di Azure per Redis
  • Il servizio metadati dell'istanza di Azure ha un completamento previsto nel maggio 2022, come descritto in questo post di blog sulla governance e sulla gestione di Azure.

Cosa è cambiato?

Prima della modifica, la maggior parte dei certificati TLS usati dai servizi di Azure concatenati alla CA radice seguente:

Nome comune della CA Thumbprint (SHA1)
Baltimore CyberTrust Root d4de20d05e66fc53fe1a50882c78db2852cae474

Dopo la modifica, i certificati TLS usati dai servizi di Azure concatenano fino a una delle ca radice seguenti:

Nome comune della CA Thumbprint (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

L'applicazione è stata interessata?

Se l'applicazione specifica in modo esplicito un elenco di ca accettabili, è probabile che l'applicazione sia interessata. Questa procedura è nota come aggiunta di certificati. Per altre informazioni su come determinare se i servizi sono stati interessati e i passaggi successivi, vedere l'articolo Microsoft Tech Community su Archiviazione di Azure modifiche a TLS.

Ecco alcuni modi per rilevare se l'applicazione è stata interessata:

  • Cercare nel codice sorgente l'identificazione personale, il nome comune e altre proprietà del certificato di qualsiasi autorità di certificazione TLS IT Microsoft nel repository PKI Microsoft. Se è presente una corrispondenza, l'applicazione verrà interessata. Per risolvere il problema, aggiornare il codice sorgente per includere le nuove CA. Come procedura consigliata, assicurarsi che le CA possano essere aggiunte o modificate con un breve preavviso. Le normative del settore richiedono che i certificati CA vengano sostituiti entro sette giorni dalla modifica e quindi i clienti che si affidano all'aggiunta devono reagire rapidamente.

  • Se si dispone di un'applicazione che si integra con API di Azure o altri servizi di Azure e non si è certi se usa l'associazione del certificato, contattare il fornitore dell'applicazione.

  • Diversi sistemi operativi e runtime del linguaggio che comunicano con i servizi di Azure possono richiedere più passaggi per compilare correttamente la catena di certificati con queste nuove radici:

    • Linux: molte distribuzioni richiedono l'aggiunta di ca a /etc/ssl/certs. Per istruzioni specifiche, fare riferimento alla documentazione della distribuzione.
    • Java: assicurarsi che l'archivio chiavi Java contenga le ca elencate in precedenza.
    • Windows in esecuzione in ambienti disconnessi: i sistemi in esecuzione in ambienti disconnessi dovranno aggiungere le nuove radici all'archivio Autorità di certificazione radice attendibili e gli intermedi aggiunti all'archivio Autorità di certificazione intermedie.
    • Android: controllare la documentazione relativa al dispositivo e alla versione di Android.
    • Altri dispositivi hardware, in particolare IoT: contattare il produttore del dispositivo.

  • Se si dispone di un ambiente in cui le regole del firewall sono impostate per consentire le chiamate in uscita solo a specifici percorsi di download E/O OCSP (Online Certificate Status Protocol), sarà necessario consentire i seguenti URL CRL e OCSP. Per un elenco completo degli URL CRL e OCSP usati in Azure, vedere l'articolo Dettagli ca di 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

Passaggi successivi

In caso di domande, contattare Microsoft tramite il supporto tecnico.