Modifiche al certificato TLS di Office

  • Articolo

Microsoft 365 sta aggiornando i servizi che alimentano messaggistica, riunioni, telefonia, voce e video per l'uso di certificati TLS da un set diverso di autorità di certificazione radice (CA). Questa modifica viene apportata perché la CA radice corrente scadrà a maggio 2025.

I prodotti interessati includono:

  • Microsoft Teams
  • Skype
  • Skype for Business Online
  • Microsoft Dynamics 365
  • GroupMe
  • Kaizala
  • Servizi di comunicazione di Azure

Gli endpoint interessati includono (ma non sono limitati a):

  • *.teams.microsoft.com
  • *.skype.com
  • *.skypeforbusiness.com
  • *.groupme.com
  • *.communication.azure.com
  • *.operatorconnect.microsoft.com

Inoltre, gli endpoint di Teams e Skype for Business Online nelle istanze cloud nazionali del governo degli Stati Uniti di Microsoft 365 apportano la stessa modifica, con effetti sugli endpoint come:

  • *.gcc.teams.microsoft.com
  • *.dod.teams.microsoft.us
  • *.gov.teams.microsoft.us
  • *.online.dod.skypeforbusiness.us
  • *.online.gov.skypeforbusiness.us
  • *.um-dod.office365.us
  • *.um.office365.us

Questa modifica non influirà su certificati, domini o servizi usati nelle istanze cloud nazionali di Microsoft 365 in Cina o Germania.

Tutte le informazioni sui certificati in questo articolo sono state fornite in precedenza nelle catene di crittografia di Microsoft 365 entro ottobre 2020.

Consiglio

Se non si è un cliente E5, usare la versione di valutazione delle soluzioni Microsoft Purview di 90 giorni per esplorare in che modo funzionalità aggiuntive di Purview possono aiutare l'organizzazione a gestire le esigenze di sicurezza e conformità dei dati. Iniziare ora dall'hub delle versioni di valutazione Portale di conformità di Microsoft Purview. Informazioni dettagliate sull'iscrizione e le condizioni di valutazione.

Quando si verificherà questa modifica?

I servizi hanno iniziato la transizione alle nuove CA radice nel gennaio 2022 e continueranno fino a ottobre 2022.

Che cosa sta cambiando?

Oggi, la maggior parte dei certificati TLS usati dai servizi di Microsoft 365 si concatenare fino alla CA radice seguente:

Nome comune dell'autorità di certificazione Identificazione personale (SHA1)
Baltimore CyberTrust Root d4de20d05e66fc53fe1a50882c78db2852cae474

con una delle CA intermedie seguenti:

Nome comune dell'autorità di certificazione Identificazione personale (SHA1)
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c0440be4a429c75

I nuovi certificati TLS usati dai servizi di Microsoft 365 verranno ora concatenati a una delle ca radice seguenti:

Nome comune dell'autorità di certificazione Identificazione personale (SHA1)
Radice globale di DigiCert G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4
Autorità di certificazione radice RSA Microsoft 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Microsoft ECC Root Certificate Authority 2017 999a64c37ff47d9fab95f14769891460eec4c3c5

con una delle CA intermedie seguenti:

Nome comune dell'autorità di certificazione Identificazione personale (SHA1)
Autorità di certificazione TLS di Microsoft Azure 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Ca 02 emittente TLS di Microsoft Azure e7eea674ca718e3befd90858e09f8372ad0ae2aa
Autorità di certificazione TLS di Microsoft Azure 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Autorità di certificazione TLS di Microsoft Azure 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Ad esempio, si tratta di un certificato valido con una delle nuove catene di certificati:

Catena di certificati TLS di Teams

Questa modifica influirà su di me?

La CA radice "DigiCert Global Root G2" è ampiamente attendibile dai sistemi operativi tra cui Windows, macOS, Android e iOS e da browser come Microsoft Edge, Chrome, Safari e Firefox. Ci aspettiamo che la maggior parte dei clienti di Microsoft 365 non verrà interessata.

Tuttavia, l'applicazione potrebbe essere interessata se specifica in modo esplicito un elenco di CA accettabili. Questa procedura è nota come "aggiunta di certificati". I clienti che non dispongono delle nuove CA radice nell'elenco di CA accettabili riceveranno errori di convalida del certificato, che potrebbero influire sulla disponibilità o sulla funzione dell'applicazione.

Ecco alcuni modi per rilevare se l'applicazione potrebbe essere interessata:

  • Cercare nel codice sorgente l'identificazione personale, il nome comune o altre proprietà di una delle CA intermedie disponibili qui. Se è presente una corrispondenza, l'applicazione verrà interessata. Per risolvere questo problema, aggiornare il codice sorgente per aggiungere le proprietà delle nuove CA. Come procedura consigliata, assicurarsi che le CA possano essere aggiunte o modificate con breve preavviso. Le normative del settore richiedono la sostituzione dei certificati ca entro sette giorni in alcune circostanze, quindi le applicazioni che implementano l'aggiunta di certificati devono reagire rapidamente a queste modifiche.

  • .NET espone le System.Net.ServicePointManager.ServerCertificateValidationCallback funzioni di callback e System.Net.HttpWebRequest.ServerCertificateValidationCallback , che consentono agli sviluppatori di usare la logica personalizzata per determinare se i certificati sono validi anziché basarsi sull'archivio certificati Windows standard. Uno sviluppatore può aggiungere una logica che controlla la presenza di un nome comune o un'identificazione personale specifica o consente solo una CA radice specifica, ad esempio "Baltimore CyberTrust Root". Se l'applicazione usa queste funzioni di callback, è necessario assicurarsi che accetti sia le ca radice che quelle intermedie precedenti e nuove.

  • Le applicazioni native possono usare WINHTTP_CALLBACK_STATUS_SENDING_REQUEST, che consente alle applicazioni native di implementare la logica di convalida del certificato personalizzata. L'utilizzo di questa notifica è raro e richiede una quantità significativa di codice personalizzato da implementare. Analogamente a quanto indicato in precedenza, assicurarsi che l'applicazione accetti sia le ca radice che quelle nuove e intermedie.

  • Se si usa un'applicazione che si integra con Microsoft Teams, Skype, Skype for Business Online o le API di Microsoft Dynamics e non si è certi che usi l'aggiunta di certificati, rivolgersi al fornitore dell'applicazione.

  • Diversi sistemi operativi e runtime del linguaggio che comunicano con i servizi di Azure possono richiedere altri passaggi per compilare e convalidare correttamente le nuove catene di certificati:

    • Linux: molte distribuzioni richiedono l'aggiunta di CA a /etc/ssl/certs. Per istruzioni specifiche, vedere la 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 avere le nuove CA radice aggiunte al loro Trusted Root Certification Authorities archivio e le nuove CA intermedie aggiunte al loro Intermediate Certification Authorities archivio.
    • Android: controllare la documentazione per il dispositivo e la versione di Android.
    • Dispositivi IoT o incorporati: i dispositivi incorporati, ad esempio i set di tv, vengono spesso forniti con un set limitato di certificati dell'autorità radice e non hanno un modo semplice per aggiornare l'archivio certificati. Se si scrive codice per o si gestiscono distribuzioni di dispositivi personalizzati incorporati o IoT, assicurarsi che i dispositivi consideri attendibili le nuove CA radice. Potrebbe essere necessario contattare il produttore del dispositivo.

  • Se si dispone di un ambiente in cui le regole del firewall consentono chiamate in uscita solo a endpoint specifici, consentire gli URL CRL (Certificate Revocation List) o OCSP (Certificate Status Protocol) seguenti:

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

  • Se si è interessati da questa modifica, è possibile che vengano visualizzati messaggi di errore dipendenti dal tipo di ambiente in esecuzione e dallo scenario in cui si è interessati. Controllare i log eventi dell'applicazione Windows, i log eventi CAPI2 e i log applicazioni personalizzati per i messaggi simili ai seguenti:

    An operation failed because the following certificate has validation errors:

Subject Name: CN=teams.microsoft.com
Issuer Name: CN=Microsoft Azure TLS Issuing CA 01, O=Microsoft Corporation, C=US

Errors:

The root of the certificate chain is not a trusted root authority.

  • Se si usa un controller di bordo sessione, Microsoft ha preparato un endpoint di test che può essere usato per verificare che le appliance SBC consideri attendibili i certificati rilasciati dalla nuova CA radice. Questo endpoint deve essere usato solo per i messaggi ping SIP OPTIONS e non per il traffico vocale.

    Global FQDN: sip.mspki.pstnhub.microsoft.com 
Port: 5061

    Se il funzionamento non funziona normalmente, contattare il produttore del dispositivo per determinare se sono disponibili aggiornamenti per supportare la nuova CA radice.

Quando è possibile ritirare le informazioni precedenti sulla CA?

I certificati RADICE, CA intermedia e foglia correnti non verranno revocati. I nomi comuni della CA e/o le identificazioni personali esistenti saranno necessari almeno fino a ottobre 2023 in base alla durata dei certificati esistenti.

Problemi noti

In circostanze molto rare, gli utenti aziendali possono visualizzare errori di convalida del certificato in cui la CA radice "DigiCert Global Root G2" viene visualizzata come revocata. Ciò è dovuto a un bug di Windows noto in entrambe le condizioni seguenti:

Tutti i certificati foglia emessi da questa CA radice dopo la visualizzazione dell'oggetto NotBeforeFileTime verranno revocati.

Gli amministratori possono identificare e risolvere il problema esaminando il log CAPI2 per individuare questo errore:

Log Name:      Microsoft-Windows-CAPI2/Operational
Source:        Microsoft-Windows-CAPI2
Date:          6/23/2022 8:36:39 AM
Event ID:      11
Task Category: Build Chain
Level:         Error
[...]
        <ChainElement>
          <Certificate fileRef="DF3C24F9BFD666761B268073FE06D1CC8D4F82A4.cer" subjectName="DigiCert Global Root G2" />
          [...]
          <TrustStatus>
            <ErrorStatus value="4000024" CERT_TRUST_IS_REVOKED="true" CERT_TRUST_IS_UNTRUSTED_ROOT="true" CERT_TRUST_IS_EXPLICIT_DISTRUST="true" />
            <InfoStatus value="10C" CERT_TRUST_HAS_NAME_MATCH_ISSUER="true" CERT_TRUST_IS_SELF_SIGNED="true" CERT_TRUST_HAS_PREFERRED_ISSUER="true" />
          </TrustStatus>
          [...]
          <RevocationInfo freshnessTime="PT0S">
            <RevocationResult value="80092010">The certificate is revoked.</RevocationResult>
          </RevocationInfo>
        </ChainElement>
      </CertificateChain>
      <EventAuxInfo ProcessName="Teams.exe" />
      <Result value="80092010">The certificate is revoked.</Result>

Si noti la presenza dell'elemento CERT_TRUST_IS_EXPLICIT_DISTRUST="true" .

È possibile verificare che siano presenti due copie della CA radice con proprietà diverse NotBeforeFileTime eseguendo i comandi seguenti certutil e confrontando l'output:

certutil -store -v authroot DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
certutil -user -store -v root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4

Un utente può risolvere il problema eliminando la copia della CA radice nell'archivio CurrentUser\Root certificati eseguendo le operazioni seguenti:

certutil -user -delstore root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4

oppure

reg delete HKCU\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates\DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 /f

Il primo approccio crea una finestra di dialogo di Windows su cui un utente deve fare clic mentre il secondo non lo fa.