Alterações na verificação de certificado do servidor TLS do navegador do Microsoft Edge
Quando o Microsoft Edge estabelece ligações a um servidor HTTPS, o Edge verifica se o servidor apresentou um certificado emitido por uma entidade fidedigna pelo browser. Esta relação de fidedignidade é estabelecida através de uma lista de fidedignidade de certificados e o componente responsável pela realização das verificações chama-se verificador de certificados.
Em versões anteriores do Microsoft Edge, a lista de confiança de certificados predefinida e a lógica do verificador de certificados foram fornecidas pela plataforma do sistema operativo (SO) subjacente.
Para dispositivos geridos, a partir do Microsoft Edge 112 no Windows e macOS, tanto a lista de confiança de certificados predefinida como o verificador de certificados são fornecidos pelo e enviados com o browser. Esta abordagem desassocia a lista e o verificador do arquivo raiz do sistema operativo anfitrião para o comportamento de verificação predefinido. Veja a linha cronológica de implementação e a documentação de orientação de teste para obter mais detalhes sobre a temporização da alteração.
Mesmo após a alteração, para além de confiar nas raízes incorporadas que são enviadas com o Microsoft Edge, o browser consulta as raízes instaladas localmente na plataforma subjacente para as raízes instaladas localmente que os utilizadores e/ou empresas instalam. Como resultado, os cenários em que um utilizador ou empresa instalou mais raízes no arquivo raiz do sistema operativo anfitrião devem continuar a funcionar.
Esta alteração significa que a lógica de verificação de certificados funciona de forma consistente no Microsoft Edge no Windows e macOS. Numa versão futuramente determinada, a implementação também será aplicada ao Linux e Android. Devido às políticas da Apple App Store, o arquivo de raiz e o verificador de certificados fornecidos pela Apple continuam a ser utilizados no iOS e iPadOS.
Origem da lista de fidedignidade do certificado predefinida
O arquivo raiz fornecido com o Microsoft Edge no Windows e macOS provém da Lista de Fidedignidade de Certificados (CTL) definida pelo Programa de Certificados de Raiz Fidedigna da Microsoft. Este programa de certificados de raiz define a lista fornecida com o Microsoft Windows. Como resultado, os clientes não devem esperar ver alterações visíveis pelo utilizador.
No macOS, se um certificado emitido por um certificado de raiz considerado fidedigno pela plataforma, mas não pelo Programa de Certificados de Raiz Fidedigna da Microsoft, o certificado já não é fidedigno. Não se espera que esta falta de confiança seja uma situação comum, uma vez que a maioria dos servidores já garante que os certificados TLS que utilizam são considerados fidedignos pelo Microsoft Windows.
As atualizações são lançadas na cadência documentada nas notas de versão do Programa de Raiz Fidedigna da Microsoft.
Linha cronológica de implementação e documentação de orientação de teste
A partir do Microsoft Edge 109, uma política empresarial (MicrosoftRootStoreEnabled) e um sinalizador no edge://flags ("Microsoft Root Store") estão disponíveis para controlar quando o arquivo de raiz incorporado e o verificador de certificados são utilizados.
Os dispositivos que não são geridos pela empresa começaram a receber a funcionalidade através de uma Implementação de Funcionalidades Controladas (CFR) no Microsoft Edge 109 e atingiram 100% dos dispositivos não geridos no Edge 111. Para obter mais informações, consulte Configurações e experimentação do Microsoft Edge, o que explica como funcionam os CFRs no Microsoft Edge. Para dispositivos geridos por empresas, a implementação fornecida pela plataforma existente foi utilizada através do Microsoft Edge 111.
A partir do Microsoft Edge 112, a predefinição foi alterada para todos os dispositivos Windows e macOS, incluindo os geridos por empresas, para utilizar a implementação do verificador e a CTL enviada com o browser. A política MicrosoftRootStoreEnabled continua disponível nesta versão para permitir que as empresas revertam para o comportamento anterior se forem encontrados problemas inesperados e para comunicar os problemas à Microsoft.
A Microsoft recomenda que as empresas que tenham proxies de interrupção e inspeção ou outros cenários que envolvam certificados de servidor TLS emitidos por raízes que não estejam no Microsoft CTL identifiquem e comuniquem proativamente quaisquer problemas de compatibilidade à Microsoft.
No Microsoft Edge 115, o suporte para a política MicrosoftRootStoreEnabled é removido.
Diferenças de comportamento de certificados fidedignos localmente conhecidas no Windows
Conformidade rfc 5280 mais rigorosa
O novo verificador de certificados incorporado é mais rigoroso na aplicação de requisitos rfc 5280 do que o verificador antigo baseado na plataforma.
Exemplos de conformidade RFC 5280 mais rigorosa incluem:
- Os parâmetros do algoritmo para algoritmos ECDSA têm de estar ausentes. O verificador antigo ignoraria os parâmetros enquanto o novo rejeita o certificado. Para obter mais informações, veja Problema do Chromium 1453441 para obter mais detalhes.
- As restrições de nome que especificam um endereço IP têm de conter oito octetos para endereços IPv4 e 32 octetos para endereços IPv6. Se o certificado especificar um endereço IP vazio, deve voltar a emitir o certificado e omitir totalmente a restrição de nome do endereço IP.
- As restrições de nome com uma lista "excluída" vazia são inválidas. O visualizador de certificados do Windows mostra esta lista como
Excluded=NonenosName Constraintsdetalhes. Para obter mais informações, veja Chromium issue 1457348 (Problema do Chromium) 1457348 para obter mais detalhes. Em vez de especificar uma lista vazia, omita-a totalmente.
Diferenças de comportamento de verificação de revogação conhecidas no Windows
Além dos requisitos mais rigorosos do RFC 5280, o novo verificador não suporta URIs de lista de revogação de certificados (CRL) baseados em LDAP.
Se a sua empresa ativar a política RequireOnlineRevocationChecksForLocalAnchors e as CRLs não forem válidas por RFC 5280, o seu ambiente poderá começar a ver ERR_CERT_NO_REVOCATION_MECHANISM erros e/ou ERR_CERT_UNABLE_TO_CHECK_REVOCATION .
Se encontrar ERR_CERT_NO_REVOCATION_MECHANISM, deve confirmar que o CRL no URI especificado pelo certificado devolve uma resposta codificada com DER (não codificada por PEM).