Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Quando o Microsoft Edge estabelece conexões com um servidor HTTPS, o Edge verifica se o servidor apresentou um certificado emitido por uma entidade confiável pelo navegador. Essa relação de confiança é estabelecida por meio de uma lista de certificados confiáveis e o componente responsável por executar as verificações é chamado de verificador de certificados.
Em versões anteriores do Microsoft Edge, a lista de certificados de confiança padrão e a lógica do verificador de certificado eram fornecidas pela plataforma do sistema operacional (SO) subjacente.
Para dispositivos gerenciados, a partir do Microsoft Edge 112 no Windows e macOS, a lista de certificados confiáveis padrão e o verificador de certificado são fornecidos e fornecidos com o navegador. Essa abordagem separa a lista e o verificador do armazenamento raiz do sistema operacional do host para o comportamento de verificação padrão. Consulte a linha do linha do tempo de lançamento e as orientações de teste para obter mais detalhes sobre o momento da mudança.
Mesmo após a alteração, além de confiar nas raízes internas fornecidas com o Microsoft Edge, o navegador consulta a plataforma subjacente e confia nas raízes instaladas localmente que os usuários e/ou empresas instalaram. Como resultado, os cenários em que um usuário ou empresa instalou mais raízes no armazenamento raiz do sistema operacional do host devem continuar funcionando.
Essa alteração significa que a lógica de verificação do certificado funciona consistentemente no Microsoft Edge no Windows e macOS. Em uma versão futura a ser determinada, o lançamento também se aplicará ao Linux e ao Android. Devido às políticas da Apple App Store, o verificador de certificado e armazenamento raiz fornecido pela Apple continua a ser usado no iOS e no iPadOS.
Origem da lista de certificados confiáveis padrão
O repositório raiz fornecido com o Microsoft Edge no Windows e macOS vem da Lista de Certificados Confiáveis (CTL) definida pelo Programa de Certificados Raiz Confiáveis da Microsoft. Este programa de certificado raiz define a lista que acompanha o Microsoft Windows. Como resultado, os clientes não devem esperar ver alterações visíveis para o usuário.
No macOS, se um certificado for emitido por um certificado raiz confiável para a plataforma, mas não pelo Programa de Certificados Raiz Confiáveis da Microsoft, o certificado não será mais confiável. Não se espera que essa falta de confiança seja uma situação comum, pois a maioria dos servidores já garante que os certificados TLS que eles usam sejam confiáveis pelo Microsoft Windows.
Atualizações são lançadas na cadência documentada nas notas de versão do Programa Raiz Confiável da Microsoft.
Linha do linha do tempo de lançamento e diretrizes de teste
A partir do Microsoft Edge 109, uma política corporativa (MicrosoftRootStoreEnabled) e um sinalizador no edge://flags ("Microsoft Root Store") estão disponíveis para controlar quando o repositório raiz interno e o verificador de certificados são usados.
Os dispositivos que não são gerenciados pela empresa começaram a receber o recurso por meio de uma CFR (Distribuição de Recursos Controlados) no Microsoft Edge 109 e alcançaram 100% dos dispositivos não gerenciados no Edge 111. Para obter mais informações, consulte Configurações e experimentação do Microsoft Edge, que explica como os CFRs no Microsoft Edge funcionam. Para dispositivos gerenciados pela empresa, a implementação fornecida pela plataforma existente foi usada por meio do Microsoft Edge 111.
A partir do Microsoft Edge 112, o padrão mudou para todos os dispositivos Windows e macOS, incluindo os gerenciados pela empresa, para usar a implementação do verificador e a CTL fornecida com o navegador. 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 relatar os problemas à Microsoft.
A Microsoft recomenda que as empresas que têm proxies break-and-inspect ou outros cenários envolvendo certificados de servidor TLS emitidos por raízes que não estão na CTL da Microsoft identifiquem e relatem proativamente quaisquer problemas de compatibilidade à Microsoft.
No Microsoft Edge 115, o suporte para a política MicrosoftRootStoreEnabled é removido.
Diferenças conhecidas de comportamento de certificado localmente confiável no Windows
Conformidade mais rigorosa com o RFC 5280
O novo verificador de certificado interno é mais rigoroso na imposição dos requisitos RFC 5280 do que o antigo verificador baseado em plataforma.
Exemplos de conformidade mais estrita com o RFC 5280 incluem:
- Os parâmetros de algoritmo para algoritmos ECDSA devem estar ausentes. O verificador antigo ignoraria os parâmetros enquanto o novo rejeitaria o certificado. Para obter mais informações, consulte Chromium problema 1453441 para obter mais detalhes.
- As restrições de nome que especificam um endereço IP devem conter oito octetos para endereços IPv4 e 32 octetos para endereços IPv6. Se o certificado especificar um endereço IP vazio, você deverá reemitir 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 essa lista conforme
Excluded=NoneosName Constraintsdetalhes. Para obter mais informações, consulte Chromium problema 1457348 para obter mais detalhes. Em vez de especificar uma lista vazia, omita-a inteiramente.
Diferenças conhecidas de comportamento de verificação de revogação no Windows
Além dos requisitos mais rigorosos do RFC 5280, o novo verificador não dá suporte a URIs de CRL (lista de certificados revogados) baseados em LDAP.
Se sua empresa habilitar a política RequireOnlineRevocationChecksForLocalAnchors e as CRLs não forem válidas por RFC 5280, seu ambiente poderá começar a ver ERR_CERT_NO_REVOCATION_MECHANISM e/ou ERR_CERT_UNABLE_TO_CHECK_REVOCATION erros.
Se você encontrar ERR_CERT_NO_REVOCATION_MECHANISM, deverá confirmar se a CRL no URI especificado pelo certificado retorna uma resposta codificada por DER (não codificada por PEM).