Descrição do mecanismo de detecção de proxy da API de Criptografia ao baixar uma CRL (Lista de Revogação de Certificado) de um ponto de distribuição crl

  • Artigo

Aviso

O aplicativo da área de trabalho desativado e sem suporte do Internet Explorer 11 está programado para ser desativado permanentemente por meio de uma atualização do Microsoft Edge em certas versões do Windows 10. Para obter mais informações, consulte Perguntas frequentes sobre a desativação do aplicativo de área de trabalho do Internet Explorer 11.

A finalidade deste artigo é explicar como a API de Criptografia tenta encontrar uma rota pela qual ela pode baixar com êxito uma URL de ponto de distribuição de CRL baseada em HTTP e destinada a ajudar na solução de problemas de cenários relacionados à recuperação de rede de CRLs.

Versão original do produto: 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 de KB original: 2623724

Resumo

Considere o seguinte cenário. Seu aplicativo usa a API WinINet, a API WinHTTP ou a classe System.Net.HttpWebRequest da estrutura .NET para enviar uma solicitação HTTP pelo SSL/TLS. Durante a negociação do canal seguro SSL/TLS, o servidor envia uma mensagem do Server Hello para o cliente com seu Certificado de Servidor para provar sua identidade para o cliente. Ao fazer isso, as informações do certificado do servidor também podem conter uma lista de pontos de distribuição CRL (Lista de Revogação de Certificado). Esta lista de pontos de distribuição crl contém uma URL de onde o cliente pode baixar o CRL e pode verificar se o certificado do servidor foi revogado pelo editor do certificado.

A API de Criptografia usa internamente a API WinHTTP para baixar a URL baseada em HTTP para o ponto de distribuição crl. Antes de baixar a URL, o WinHTTP precisa saber uma rota para chegar à URL de CRL. Em situações em que o ambiente tem um servidor proxy, o WinHTTP pode detectar automaticamente o servidor Proxy ou pode ser solicitado pelo aplicativo que consome a API WinHTTP para usar um proxy específico para baixar o CRL.

A API de Criptografia tenta internamente encontrar um servidor Proxy primeiro usando a lógica abaixo e, se encontrar qualquer endereço de servidor proxy, ele pedirá ao WinHTTP que use essa instância de proxy específica.

Se a instância de proxy não for acessível ou estiver incorreta, o WinHTTP não poderá baixar o CRL, o marcar de revogação de certificado falhará e seu aplicativo receberá um erro da API de Criptografia indicando a falha de revogação. Ele pode relatar o mesmo erro ao usuário e, dependendo da implementação, o estabelecimento de canal seguro pode falhar.

Ao tentar descobrir o proxy, a API do Crypto usa a seguinte lógica:

  1. Ele verifica se há configurações de proxy estáticas configuradas no computador de onde o marcar crl está sendo feito. Normalmente, essa configuração é feita usando o utilitário netsh para definir o proxy manualmente no Windows Vista, Windows 2008, Windows 7 ou Windows 2008 R2. Se um proxy estático for encontrado, a API do Crypto usará o proxy descoberto estaticamente para baixar o CRL por meio do WinHttp. Para obter mais informações sobre netsh, confira Comandos netsh para WINHTTP (Protocolo de Transferência de Hipertexto do Windows) na seção Mais informações abaixo.

    Observação

    Esse marcar só é executado no Windows Vista, Windows 2008, Windows 7 e Windows 2008 R2. No Windows 2003, a API de Criptografia não marcar configurações de proxy estático.

  2. Se um proxy configurado estaticamente não for encontrado, a API de Criptografia tentará recuperar as configurações de proxy de Explorer da Internet para o contexto do usuário no qual a API do Crypto está sendo executada.

    Dependendo de qual processo está em execução, isso pode ser a identidade do usuário atualmente conectado, ou pode ser por qualquer usuário específico ou pode ser qualquer uma das contas fornecidas pelos sistemas – SISTEMA LOCAL, SERVIÇO DE REDE, SERVIÇO LOCAL. Os seguintes locais de registro são consultados com base na identidade de execução:

    • Usuário conectado no momento: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
    • SERVIÇO DE REDE: 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
    • SERVIÇO LOCAL: HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet Settings
    • Qualquer outro usuário: HKEY_USERS\<<SID of that user>>\Software\Microsoft\Windows\CurrentVersion\Internet Settings

    Dependendo das informações do registro, as configurações de proxy para esse usuário serão retornadas. Se as configurações de proxy estiverem ausentes, nenhuma informação será retornada. Se as configurações de proxy forem retornadas, ela poderá conter uma combinação das opções abaixo:

    • Detecte automaticamente as configurações.
    • Use o script de configuração automática.
    • Servidor proxy.

    Observação

    Em situações em que o processo está sendo executado como uma identidade diferente do usuário atualmente conectado, pode haver uma inconsistência nas configurações de proxy, dependendo de como as configurações de proxy foram configuradas para esse usuário. Nesses casos, você pode observar que navegar até o local do CRL usando a Internet Explorer como o usuário atual baixa com êxito o CRL, mas o mesmo processo falha quando usado da API de Criptografia que está sendo executada como outro usuário. Nessas situações, é altamente recomendável que você marcar as Configurações da Internet de todos os usuários e verifique se eles são consistentes.

    O ideal é que as Configurações da Internet não estejam presentes para usuários não interativos, como SERVIÇO DE REDE, SISTEMA LOCAL ou SERVIÇO LOCAL, pois nunca haverá necessidade de abrir a Internet Explorer com essas identidades. Nesses casos, você precisa garantir que esses usuários não interativos não tenham nenhuma configuração de proxy configurada para a Internet Explorer ou garantir que eles sejam consistentes com as configurações de proxy para o usuário com o qual o download do CRL é bem-sucedido usando a Internet Explorer.

  3. Se as configurações de proxy do Explorer da Internet não estiverem presentes para o usuário em execução ou se as configurações de Explorer da Internet para a identidade do processo indicarem. Detecte automaticamente configurações ou Use script de configuração automática, a API de Criptografia tentará descobrir automaticamente um proxy para o CRL em questão. Isso retornará informações específicas de proxy ou retornará "nenhum proxy" se a descoberta automática de proxy falhar ou se a URL não exigir um proxy.

    A API de Criptografia tentará usar a API WinHTTP para baixar a URL de CRL usando o proxy descoberto (ou nenhum proxy se o proxy não pôde ser descoberto ou se a URL não exigir um proxy).

    Se o proxy estiver inacessível ou se as informações de proxy estiverem erradas, a busca da URL de CRL falhará. Em seguida, a API de Criptografia relatará esse erro à API de chamada e, dependendo da implementação, o chamador da API de Criptografia pode decidir se anula a solicitação ou a deixa passar.

    Observação

    Nos casos em que o aplicativo em si está consumindo a API WinHTTP e definiu as informações de proxy na chamada WinHttpOpen ou na chamada WinHttpSetOption, a API de Criptografia não tem acesso às informações de Proxy definidas pelo aplicativo e ainda tentará descobrir as informações de proxy como acima. O uso da API WinHttp da API de Criptografia e de seu próprio aplicativo são independentes e não compartilham nenhuma informação entre si.

Em Windows 10, o CRYPTOAPI 2 (CAPI2) é atualizado para que ele não tenha suas próprias configurações de proxy. A alteração é implementada em uma chamada de função WinHttpOpen em que, a partir de Windows 10, o CAPI2 usa o sinalizador WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY.

Nome do sinalizador Descrição
WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY Usa configurações de proxy de sistema e por usuário (incluindo a configuração de proxy do Explorer da Internet) para determinar quais proxy/proxies usar. Tenta lidar automaticamente com o failover entre vários proxies, diferentes configurações de proxy por interface e autenticação. Com suporte em Windows 8.1 e mais recentes.

Observação

Versões anteriores do Windows usaram o sinalizador WINHTTP_ACCESS_TYPE_DEFAULT_PROXY .

O sinalizador WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY significa que o WinHttp lidará com a lógica de detecção de proxy e o chamador não deve escrever nenhum código para lidar com a configuração de proxy. Se o sinalizador de WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY estiver definido, o WinHttp marcar a configuração de proxy padrão usando o utilitário netsh e, em seguida, as configurações de proxy de Explorer da Internet.

Observação

As configurações de proxy de Explorer da Internet são por usuário, o que significa que o chamador deve representar o usuário conectado.

Se você não quiser definir um proxy para cada usuário conectado, poderá configurar um proxy em todo o computador definindo a chave ProxySettingsPerUser como 0.

Chave do Registro HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\InternetSettings\ProxySettingsPerUser
Tipo REG DWORD
Valor
0: proxy por computador
1 ou nenhum valor: por usuário

Depois de definir a chave do registro, você pode configurar o proxy com propriedades da Internet (Inetcpl.cpl). As configurações de proxy em todo o computador podem ser alteradas pelos administradores ou usando o Política de Grupo.

Mais informações

Para saber mais, veja: