Cambios en la comprobación del certificado del servidor TLS del explorador Microsoft Edge
Cuando Microsoft Edge establece conexiones a un servidor HTTPS, Edge comprueba que el servidor ha presentado un certificado emitido por una entidad de confianza del explorador. Esta relación de confianza se establece a través de una lista de confianza de certificados y el componente responsable de realizar las comprobaciones se denomina comprobador de certificados.
En versiones anteriores de Microsoft Edge, la plataforma del sistema operativo subyacente proporcionaba tanto la lista de confianza de certificados predeterminada como la lógica del comprobador de certificados.
En el caso de los dispositivos administrados, a partir de Microsoft Edge 112 en Windows y macOS, tanto la lista de confianza de certificados predeterminada como el comprobador de certificados se proporcionan y se envían con el explorador. Este enfoque desacopla la lista y el comprobador del almacén raíz del sistema operativo host para el comportamiento de comprobación predeterminado. Consulte la escala de tiempo de lanzamiento y la guía de pruebas para obtener más detalles sobre el tiempo del cambio.
Incluso después del cambio, además de confiar en las raíces integradas que se incluyen con Microsoft Edge, el explorador consulta la plataforma subyacente y confía en las raíces instaladas localmente que los usuarios o las empresas instalaron. Como resultado, los escenarios en los que un usuario o una empresa instalaron más raíces en el almacén raíz del sistema operativo host deben seguir funcionando.
Este cambio significa que la lógica de verificación de certificados funciona de forma coherente en Microsoft Edge en Windows y macOS. En una versión futura que se determinará, el lanzamiento también se aplicará a Linux y Android. Debido a las directivas de Apple App Store, el almacén raíz y el comprobador de certificados proporcionados por Apple siguen utilizándose en iOS y iPadOS.
Origen predeterminado de la lista de confianza de certificados
El almacén raíz que se incluye con Microsoft Edge en Windows y macOS procede de la lista de confianza de certificados (CTL) definida por el Programa de certificados raíz de confianza de Microsoft. Este programa de certificados raíz define la lista que se incluye con Microsoft Windows. Como resultado, los clientes deben esperar que no se vean cambios visibles por el usuario.
En macOS, si un certificado emitido por un certificado raíz que es de confianza para la plataforma, pero no por el Programa de certificados raíz de confianza de Microsoft, el certificado ya no es de confianza. No se espera que esta falta de confianza sea una situación común, ya que la mayoría de los servidores ya garantizan que Microsoft Windows confía en los certificados TLS que usan.
Las actualizaciones se publican según la cadencia documentada en las notas de la versión del Programa raíz de confianza de Microsoft.
Escala de tiempo de lanzamiento y guía de pruebas
A partir de Microsoft Edge 109, una directiva empresarial (MicrosoftRootStoreEnabled) y una marca en edge://flags ("Microsoft Root Store") están disponibles para controlar cuándo se usan el almacén raíz integrado y el comprobador de certificados.
Los dispositivos que no están administrados por la empresa comenzaron a recibir la característica a través de un lanzamiento controlado de características (CFR) en Microsoft Edge 109 y alcanzaron el 100 % de los dispositivos no administrados en Edge 111. Para obtener más información, vea Configuraciones y experimentación de Microsoft Edge, que explica cómo funcionan los CFR en Microsoft Edge. En el caso de los dispositivos administrados por la empresa, la implementación existente proporcionada por la plataforma se usó a través de Microsoft Edge 111.
A partir de Microsoft Edge 112, el valor predeterminado cambió para todos los dispositivos Windows y macOS, incluidos los administrados por la empresa, para usar la implementación del comprobador y el CTL incluidos con el explorador. La directiva MicrosoftRootStoreEnabled sigue estando disponible en esta versión para permitir a las empresas revertir al comportamiento anterior si se encuentran problemas inesperados y notificar los problemas a Microsoft.
Microsoft recomienda que las empresas que tienen servidores proxy de interrupción e inspección u otros escenarios que impliquen certificados de servidor TLS emitidos por raíces que no están en el CTL de Microsoft identifiquen e informen proactivamente de los problemas de compatibilidad a Microsoft.
En Microsoft Edge 115, se quita la compatibilidad con la directiva MicrosoftRootStoreEnabled .
Diferencias conocidas de comportamiento de certificado de confianza local en Windows
Cumplimiento de RFC 5280 más estricto
El nuevo comprobador de certificados integrado es más estricto para aplicar los requisitos de RFC 5280 que el comprobador antiguo basado en la plataforma.
Algunos ejemplos de cumplimiento de RFC 5280 más estricto son:
- Los parámetros de algoritmo para los algoritmos ECDSA deben estar ausentes. El comprobador anterior omitiría los parámetros mientras que el nuevo rechaza el certificado. Para obtener más información, consulte Chromium issue 1453441 (Problema de Chromium 1453441 ) para obtener más información.
- Las restricciones de nombre que especifican una dirección IP deben contener ocho octetos para direcciones IPv4 y 32 octetos para direcciones IPv6. Si el certificado especifica una dirección IP vacía, debe volver a emitir el certificado y omitir por completo la restricción de nombre de dirección IP.
- Las restricciones de nombre con una lista "excluida" vacía no son válidas. El visor de certificados de Windows muestra esta lista como
Excluded=Noneen losName Constraintsdetalles. Para obtener más información, vea Chromium issue 1457348 (Problema de Chromium 1457348 ) para obtener más información. En lugar de especificar una lista vacía, omita por completo.
Diferencias de comportamiento de comprobación de revocación conocidas en Windows
Además de los requisitos rfc 5280 más estrictos, el nuevo comprobador no admite los URI de lista de revocación de certificados basados en LDAP (CRL).
Si la empresa habilita la directiva RequireOnlineRevocationChecksForLocalAnchors y las CRL no son válidas por RFC 5280, es posible que el entorno empiece a ver ERR_CERT_NO_REVOCATION_MECHANISM errores o ERR_CERT_UNABLE_TO_CHECK_REVOCATION .
Si encuentra ERR_CERT_NO_REVOCATION_MECHANISM, debe confirmar que la CRL en el URI especificado por el certificado devuelve una respuesta codificada en DER (no codificada en PEM).