Descripción del mecanismo de detección de proxy de la API de criptografía al descargar una lista de revocación de certificados (CRL) desde un punto de distribución crl
Importante
La aplicación de escritorio Internet Explorer 11 está retirada y sin soporte a partir del 15 de junio de 2022 para determinadas versiones de Windows 10.
Todavía puede acceder a sitios antiguos heredados que requieren Internet Explorer con el modo Internet Explorer en Microsoft Edge. Obtenga más información.
La aplicación de escritorio Internet Explorer 11 se redirigirá progresivamente al explorador Microsoft Edge, más rápido y seguro. En última instancia, se deshabilitará a través de Windows Update. Deshabilite IE hoy.
El propósito de este artículo es explicar cómo la API de criptografía intenta encontrar una ruta mediante la cual puede descargar correctamente una dirección URL de punto de distribución CRL basada en HTTP y destinada a ayudar en la solución de problemas de escenarios relacionados con la recuperación de red de CRL.
Versión del producto original: Windows Server 2003 Service Pack 2, Windows Vista Enterprise, Windows Server 2008 Enterprise, Windows 7 Enterprise, Windows Server 2008 R2 Enterprise, Windows 10, Windows Server 2016, Windows Server 2019
Número KB original: 2623724
Resumen
Imagina la siguiente situación: La aplicación usa la API de WinINet, la API de WinHTTP o la clase System.Net.HttpWebRequest de .NET Framework para enviar una solicitud HTTP a través de SSL/TLS. Durante la negociación del canal seguro SSL/TLS, el servidor devuelve un mensaje de saludo de servidor al cliente con su certificado de servidor para demostrar su identidad al cliente. Al hacerlo, la información del certificado de servidor también puede contener una lista de puntos de distribución de lista de revocación de certificados (CRL). Esta lista de puntos de distribución CRL contiene una dirección URL desde la que el cliente puede descargar la CRL y puede comprobar si el editor del certificado ha revocado el certificado de servidor.
La API de criptografía usa internamente la API winHTTP para descargar la dirección URL basada en HTTP para el punto de distribución crl. Antes de descargar la dirección URL, WinHTTP debe conocer una ruta para llegar a la dirección URL de CRL. En situaciones en las que el entorno tiene un servidor proxy, WinHTTP puede detectar automáticamente el servidor proxy o la aplicación que consume la API de WinHTTP puede solicitar que use un proxy específico para descargar la CRL.
La API de criptografía intenta encontrar un servidor proxy primero con la lógica siguiente y, si encuentra alguna dirección de servidor proxy, le pide a WinHTTP que use esa instancia de proxy específica.
Si la instancia de proxy no es accesible o es incorrecta, WinHTTP no podrá descargar la CRL, se producirá un error en la comprobación de revocación de certificados y la aplicación recibirá un error de la API de criptografía que indique el error de revocación. Puede notificar el mismo error al usuario y, según la implementación, el establecimiento del canal seguro puede producir un error.
Al intentar detectar el proxy, la API de criptografía usa la siguiente lógica:
Comprueba si hay alguna configuración de proxy estático configurada en el equipo desde donde se realiza la comprobación crl. Normalmente, esta configuración se realiza con la utilidad netsh para establecer el proxy manualmente en Windows Vista, Windows 2008, Windows 7 o Windows 2008 R2. Si se encuentra un proxy estático, la API de criptografía usa el proxy detectado estáticamente para descargar la CRL a través de WinHttp. Para obtener más información sobre netsh, vea Netsh Commands for Windows Hypertext Transfer Protocol (WINHTTP) en la sección Más información a continuación.
Nota
Esta comprobación solo se realiza en Windows Vista, Windows 2008, Windows 7 y Windows 2008 R2. En Windows 2003, la API de criptografía no comprueba la configuración de proxy estático.
Si no se encuentra un proxy configurado estáticamente, la API de criptografía intenta recuperar la configuración de proxy de Internet Explorer para el contexto de usuario en el que se ejecuta la API de criptografía.
Dependiendo de cómo se ejecute el proceso, puede ser la identidad del usuario que ha iniciado sesión actualmente, o bien puede hacerlo cualquier usuario específico o puede ser cualquiera de las cuentas proporcionadas por los sistemas: SISTEMA LOCAL, SERVICIO DE RED, SERVICIO LOCAL. Las siguientes ubicaciones del Registro se consultan en función de la identidad en ejecución:
- Usuario que ha iniciado sesión actualmente:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings - SERVICIO DE RED:
HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings - SISTEMA LOCAL:
HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings - SERVICIO LOCAL:
HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet Settings - Cualquier otro usuario:
HKEY_USERS\<<SID of that user>>\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Según la información del Registro, se devolverá la configuración de proxy para ese usuario. Si la configuración de proxy no está presente, no se devolverá información. Si se devuelve la configuración de proxy, puede contener una combinación de las siguientes opciones:
- Detectar automáticamente la configuración.
- Use script de configuración automática.
- Servidor proxy.
Nota
En situaciones en las que el proceso se ejecuta como una identidad diferente a la del usuario que ha iniciado sesión actualmente, puede haber una incoherencia en la configuración de proxy en función de cómo se configuró la configuración de proxy para ese usuario. En tales casos, puede observar que al navegar a la ubicación crl con Internet Explorer como el usuario actual se descarga correctamente la CRL, pero se produce un error en el mismo proceso cuando se usa desde la API de criptografía que se ejecuta como otro usuario. En tales situaciones, es muy recomendable que compruebe la conexión a Internet Configuración de todos los usuarios y asegúrese de que son coherentes.
Internet Configuración idealmente no debe estar presente para ningún usuario que no sea interactivo, como SERVICIO DE RED, SISTEMA LOCAL o SERVICIO LOCAL, ya que nunca será necesario abrir Internet Explorer con esas identidades. En estos casos, debe asegurarse de que estos usuarios no interactivos no tienen ninguna configuración de proxy configurada para Internet Explorer o asegurarse de que son coherentes con la configuración de proxy para el usuario con el que la descarga de CRL se realiza correctamente con Internet Explorer.
- Usuario que ha iniciado sesión actualmente:
Si la configuración de proxy de Internet Explorer no está presente para el usuario en ejecución o si la configuración de Internet Explorer para la identidad del proceso indica. Detectar automáticamente la configuración o Usar script de configuración automática, la API de criptografía intentará detectar automáticamente un proxy para la CRL en cuestión. Esto devolverá información de proxy específica o devolverá "no hay proxy" si se produce un error en la detección automática de proxy o si la dirección URL no requiere un proxy.
La API de criptografía intentará usar la API de WinHTTP para descargar la dirección URL de CRL mediante el proxy detectado (o ningún proxy si no se pudo detectar el proxy o si la dirección URL no requiere un proxy).
Si el proxy no es accesible o si la información del proxy es incorrecta, se producirá un error en la captura de la dirección URL de CRL. A continuación, la API de criptografía notificara este error a la API de llamada y, según la implementación, el autor de la llamada de la API de criptografía puede decidir si anula la solicitud o la deja pasar.
Nota
En los casos en los que la propia aplicación consume la API de WinHTTP y ha establecido la información de proxy en la llamada WinHttpOpen o winHttpSetOption, la API de criptografía no tiene acceso a la información de proxy que la aplicación ha establecido y seguirá intentando descubrir la información de proxy como se ha indicado anteriormente. El uso de la API WinHttp desde la API de criptografía y desde su propia aplicación son independientes y no comparten ninguna información entre sí.
En Windows 10, CryptoAPI 2 (CAPI2) se actualiza para que no tenga su propia configuración de proxy. El cambio se implementa en una llamada a la función WinHttpOpen donde, a partir de Windows 10, CAPI2 usa la marca WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY.
| Nombre de la marca | Descripción |
|---|---|
| WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY | Usa la configuración de proxy de sistema y por usuario (incluida la configuración de proxy de Internet Explorer) para determinar qué proxy o proxy usar. Intenta controlar automáticamente la conmutación por error entre varios servidores proxy, diferentes configuraciones de proxy por interfaz y autenticación. Compatible con Windows 8.1 y versiones posteriores. |
Nota
Las Windows anteriores han usado la WINHTTP_ACCESS_TYPE_DEFAULT_PROXY marca.
La WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY significa que WinHttp controlará la lógica de detección de proxy y el autor de la llamada no debe escribir ningún código para controlar la configuración de proxy. Si se WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY marca, WinHttp comprobará la configuración de proxy predeterminada mediante la utilidad netsh y, a continuación, la configuración de proxy de Internet Explorer.
Nota
La configuración de proxy de Internet Explorer es por usuario, lo que significa que el autor de la llamada debe suplantar al usuario que ha iniciado sesión.
Si no desea establecer un proxy para cada usuario que ha iniciado sesión, puede configurar un proxy para todo el equipo estableciendo la clave ProxySettingsPerUser en 0.
| Clave de registro | HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\InternetSettings\ProxySettingsPerUser |
|---|---|
| Tipo | REG DWORD |
| Valor | 0: proxy por equipo 1 o ningún valor: por usuario |
Después de establecer la clave del Registro, puede configurar el proxy con propiedades de Internet (Inetcpl.cpl). Los administradores pueden cambiar la configuración de proxy en todo el equipo o mediante la directiva de grupo.
Más información
Para más información, vea: