Alterações de Certificado TLS do Office

  • Artigo

O Microsoft 365 está atualizando serviços que alimentam mensagens, reuniões, telefonia, voz e vídeo para usar certificados TLS de um conjunto diferente de CAs (Autoridades de Certificado Raiz). Essa alteração está sendo feita porque a AC Raiz atual expirará em maio de 2025.

Os produtos afetados incluem:

  • Microsoft Teams
  • Skype
  • Skype for Business Online
  • Microsoft Dynamics 365
  • GroupMe
  • Kaizala
  • Serviços de Comunicação do Azure

Os pontos de extremidade afetados incluem (mas não se limitam a):

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

Além disso, os pontos de extremidade teams e Skype for Business online em instâncias de nuvem nacionais do Governo dos EUA do Microsoft 365 farão a mesma alteração, afetando pontos de extremidade como:

  • *.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

Essa alteração não afetará certificados, domínios ou serviços usados nas instâncias de nuvem nacionais da China ou alemanha do Microsoft 365.

Todas as informações de certificado neste artigo foram fornecidas anteriormente nas cadeias de criptografia do Microsoft 365 até outubro de 2020.

Dica

Se você não for um cliente E5, use a avaliação de soluções do Microsoft Purview de 90 dias para explorar como recursos adicionais do Purview podem ajudar sua organização a gerenciar as necessidades de segurança e conformidade de dados. Comece agora no hub de avaliações portal de conformidade do Microsoft Purview. Saiba mais sobre os termos de inscrição e avaliação.

Quando essa alteração acontecerá?

Os serviços começaram a fazer a transição para os novos CAs raiz em janeiro de 2022 e continuarão até outubro de 2022.

O que está mudando?

Hoje, a maioria dos certificados TLS usados pela cadeia de serviços do Microsoft 365 até a seguinte AC raiz:

Nome comum da AC Impressão digital (SHA1)
Baltimore CyberTrust Root d4de20d05e66fc53fe1a50882c78db2852cae474

com um dos seguintes CAs intermediários:

Nome comum da AC Impressão digital (SHA1)
Microsoft RSA TLS CA 01 703d7a8f0ebf55aa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Novos certificados TLS usados pelos serviços do Microsoft 365 agora serão encadeados para um dos seguintes CAs raiz:

Nome comum da AC Impressão digital (SHA1)
DigiCert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4
Autoridade de Certificado Raiz do Microsoft RSA 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Autoridade de Certificado Raiz do Microsoft ECC 2017 999a64c37ff47d9fab95f14769891460eec4c3c5

com um dos seguintes CAs intermediários:

Nome comum da AC Impressão digital (SHA1)
Microsoft Azure TLS Emitindo CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS Emitindo CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aaa
Microsoft Azure TLS Emitindo CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS Emitindo CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Como exemplo, este é um certificado válido com uma das novas cadeias de certificados:

Cadeia de certificados TLS do Teams

Essa mudança vai me afetar?

A AC raiz "DigiCert Global Root G2" é amplamente confiável por sistemas operacionais, incluindo Windows, macOS, Android e iOS e por navegadores como Microsoft Edge, Chrome, Safari e Firefox. Esperamos que a maioria dos clientes do Microsoft 365 não seja afetada.

No entanto, seu aplicativo poderá ser afetado se especificar explicitamente uma lista de CAs aceitáveis. Essa prática é conhecida como "fixação de certificado". Os clientes que não tiverem os novos CAs raiz em sua lista de CAs aceitáveis receberão erros de validação de certificado, o que pode afetar a disponibilidade ou a função do seu aplicativo.

Aqui estão algumas maneiras de detectar se seu aplicativo pode ser afetado:

  • Pesquise seu código-fonte para obter a impressão digital, o Nome Comum ou outras propriedades de qualquer um dos CAs intermediários encontrados aqui. Se houver uma correspondência, seu aplicativo será afetado. Para resolve esse problema, atualize o código-fonte para adicionar as propriedades dos novos CAs. Como prática recomendada, verifique se os CAs podem ser adicionados ou editados em cima da hora. As regulamentações do setor exigem que os certificados de AC sejam substituídos dentro de sete dias em algumas circunstâncias, portanto, os aplicativos que implementam a fixação de certificado devem reagir rapidamente a essas alterações.

  • O .NET expõe as System.Net.ServicePointManager.ServerCertificateValidationCallback funções de retorno de chamada e System.Net.HttpWebRequest.ServerCertificateValidationCallback , que permitem que os desenvolvedores usem a lógica personalizada para determinar se os certificados são válidos em vez de depender do repositório de certificados padrão do Windows. Um desenvolvedor pode adicionar uma lógica que verifica um Nome Comum específico ou uma impressão digital ou só permite uma AC Raiz específica, como "Baltimore CyberTrust Root". Se o aplicativo usar essas funções de retorno de chamada, você deverá garantir que ele aceite os CAs antigos e novos da Raiz e do Intermediário.

  • Aplicativos nativos podem estar usando WINHTTP_CALLBACK_STATUS_SENDING_REQUEST, o que permite que aplicativos nativos implementem a lógica de validação de certificado personalizada. O uso dessa notificação é raro e requer uma quantidade significativa de código personalizado para implementar. Semelhante ao acima, verifique se seu aplicativo aceita os CAs raiz e intermediários antigos e novos.

  • Se você usar um aplicativo que se integra ao Microsoft Teams, Skype, Skype for Business Online ou APIs do Microsoft Dynamics e não tiver certeza se ele usa a fixação de certificado, marcar com o fornecedor do aplicativo.

  • Diferentes sistemas operacionais e runtimes de idioma que se comunicam com os serviços do Azure podem exigir outras etapas para compilar e validar corretamente as novas cadeias de certificados:

    • Linux: muitas distribuições exigem que você adicione CAs a /etc/ssl/certs. Para obter instruções específicas, consulte a documentação da distribuição.
    • Java: verifique se o repositório de chaves Java contém os CAs listados acima.
    • Windows em execução em ambientes desconectados: sistemas em execução em ambientes desconectados precisarão ter os novos CAs raiz adicionados ao seu Trusted Root Certification Authorities repositório e os novos CAs intermediários adicionados ao seu repositório Intermediate Certification Authorities .
    • Android: verifique a documentação do dispositivo e da versão do Android.
    • Dispositivos IoT ou incorporados: dispositivos inseridos, como caixas superiores de conjunto de TV, geralmente são enviados com um conjunto limitado de certificados de autoridade raiz e não têm uma maneira fácil de atualizar o repositório de certificados. Se você escrever código para ou gerenciar implantações de dispositivos personalizados inseridos ou IoT, verifique se os dispositivos confiam nos novos CAs raiz. Talvez seja necessário entrar em contato com o fabricante do dispositivo.

  • Se você tiver um ambiente em que as regras de firewall permitem chamadas de saída apenas para pontos de extremidade específicos, permita as seguintes URLs de CRL (Lista de Revogação de Certificado) ou Protocolo de Status de Certificado Online (OCSP):

    • 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 você for afetado por essa alteração, poderá ver mensagens de erro dependentes do tipo de ambiente em que está em execução e do cenário pelo qual você é afetado. Verifique logs de eventos do Aplicativo Windows, logs de eventos CAPI2 e logs de aplicativos personalizados para obter mensagens semelhantes a:

    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 você usar um Controlador de Borda de Sessão, a Microsoft preparou um ponto de extremidade de teste que pode ser usado para verificar se os dispositivos SBC confiam em certificados emitidos da nova AC Raiz. Esse ponto de extremidade deve ser usado apenas para mensagens de ping SIP OPTIONS e não para tráfego de voz.

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

    Se isso não funcionar normalmente, entre em contato com o fabricante do dispositivo para determinar se as atualizações estão disponíveis para dar suporte à nova AC Raiz.

Quando posso aposentar as informações antigas da AC?

Os certificados raiz, ac intermediário e folha atuais não serão revogados. Os Nomes Comuns de AC existentes e/ou impressões digitais serão necessários até pelo menos outubro de 2023 com base no tempo de vida dos certificados existentes.

Problemas Conhecidos

Em circunstâncias muito raras, os usuários da empresa podem ver erros de validação de certificado em que a AC raiz "DigiCert Global Root G2" aparece como revogada. Isso ocorre devido a um bug conhecido do Windows em ambas as seguintes condições:

Todos os certificados de folha emitidos dessa AC Raiz após a exibição NotBeforeFileTime serão revogados.

Os administradores podem identificar e solucionar problemas inspecionando o Log CAPI2 para obter este erro:

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>

Observe a presença do CERT_TRUST_IS_EXPLICIT_DISTRUST="true" elemento.

Você pode confirmar que duas cópias da AC Raiz com propriedades diferentes NotBeforeFileTime estão presentes executando os seguintes certutil comandos e comparando a saída:

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

Um usuário pode resolve o problema excluindo a cópia da AC Raiz no CurrentUser\Root repositório de certificados fazendo:

certutil -user -delstore root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4

ou

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

A primeira abordagem cria uma caixa de diálogo do Windows que um usuário deve clicar enquanto a segunda abordagem não.