O protocolo https não funciona no IIS 10 após a atualização do Windows 7

O protocolo https não funciona no IIS 10 após a atualização do Windows 7

Eu tenho um aplicativo ASP em execução no IIS 7.5. Devido ao EoL do Windows 7, tive que atualizar para o Windows 10 e para o IIS 10. Tudo parecia estar no lugar, exceto que agora o site ASP ou qualquer outro site funciona, exceto se https for usado. Até agora, o Firefox me fornece PR_CONNECT_RESET_ERROR, o Chrome retorna um ERR_SSL_PROTOCOL_ERROR e o Edge retorna um Hmmm, não consigo acessar esta página.

Algumas respostas apontam para o módulo ARR Rewrite, que desinstalei e após reiniciar reinstalei a versão atualizada com os mesmos resultados. Acabei desinstalando (não preciso mais) e reiniciando. Eu reinstalo o IIS eliminando os recursos do Windows, reiniciando e reinstalando o IIS novamente e reiniciando. Elimino todos os certificados e crio um autoassinado e o mesmo problema. Finalmente, excluí todos os meus sites desse servidor web e criei um novo no diretório padrão (wwwroot que contém um arquivo html e duas imagens) que é mostrado desde que o protocolo http seja usado, mas não https (mesmos erros). eu seguieste guiapara IIS 7, mas sem amor. Também revogo e concedo novamente permissões para as pastas ao IUSR após as reinstalações. Por fim, desativei a filtragem SSL do antivírus, mas não houve diferença.

O certificado usado originalmente foi feito internamente usando o openssl para gerar um certificado raiz para toda a empresa, um certificado intermediário e o certificado da máquina que funcionou bem até a atualização. Atualmente, como falei, mesmo com o autoassinado não funciona utilizando nenhum dos navegadores utilizados para veicular o conteúdo mais simples. Fiquei sem ideias sobre o que verificar.

Este é o rastreamento que recebi do IIS

 #Software: Microsoft Internet Information Services 10.0
 #Version: 1.0
 #Date: 2020-01-20 20:12:22
 #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
 2020-01-20 20:12:22 192.168.1.100 GET / - 80 - 192.168.1.100 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:73.0)+Gecko/20100101+Firefox/73.0 - 200 0 0 2687
 2020-01-20 20:12:22 192.168.1.100 GET /iisstart.png - 80 - 192.168.1.100 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:73.0)+Gecko/20100101+Firefox/73.0 http://devmachine.company.local/ 200 0 0 12
 2020-01-20 20:12:22 192.168.1.100 GET /favicon.ico - 80 - 192.168.1.100 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:73.0)+Gecko/20100101+Firefox/73.0 - 404 0 2 5
 #Software: Microsoft Internet Information Services 10.0
 #Version: 1.0
 #Date: 2020-01-20 12:26:37
 #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
 2020-01-20 20:12:22 ::1 GET / - 443 - ::1 Microsoft+Windows+Network+Diagnostics - 200 0 0 996
 2020-01-20 20:12:22 192.168.1.100 HEAD / - 80 - 192.168.1.100 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/79.0.3945.130+Safari/537.36 - 200 0 0 19
 2020-01-20 20:27:38 192.168.1.100 GET / - 80 - 192.168.1.100 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/79.0.3945.130+Safari/537.36 - 200 0 0 8
 2020-01-20 20:27:38 192.168.1.100 GET /iisstart.png - 80 - 192.168.1.100 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/79.0.3945.130+Safari/537.36 http://devmachine.company.local/ 200 0 0 50
 2020-01-20 20:27:38 192.168.1.100 GET /favicon.ico - 80 - 192.168.1.100 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/79.0.3945.130+Safari/537.36 http://devmachine.company.local/ 404 0 2 19

Como você pode ver, apenas http funcionou (mudei a hora em outra tentativa para ver se havia algum problema com o relógio, mas não foi. O Chrome reclamou com http, então o relógio estava bom), mas não há nenhum rastro para https.

Responder1

Eu obtive a resposta sozinho. O problema é que ao longo dos anos as cifras mudaram, mas apenas para os servidores Windows 2012 e 2016 houve atualizações adequadas, mas não para versões mais antigas e o Windows 10 já tinha essas entradas e foi atualizado de acordo. Conseqüentemente, existem algumas entradas de registro que não existem e que afetam a maneira como o SSL é tratado no IIS após a atualização. Para testar se este é o caso, abra uma nova aba no Firefox e digite about:config e pesquise security.tls.version.max e defina como 3 e salve. Se você tentar acessar o site ele funciona ou pelo menos mostra o aviso habitual de que o certificado não está correto. Nesse caso, desfaça a alteração no Firefox e execute a solução descritaaqui; que de qualquer forma irei descrever caso essas páginas sejam esquecidas ou excluídas.

Todo o problema é corrigido atualizando o registro nas seguintes entradas que devem ser criadas ou alteradas dependendo se você já fez parte das alterações para fortalecer a segurança em seu servidor web antes.

Atualizar WinHTTP

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\
  DefaultSecureProtocols = (DWORD): 0xAA0
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\
  DefaultSecureProtocols = (DWORD): 0xAA0

Habilite o TLS 1.2 se ainda não tiver feito isso

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
  "SystemDefaultTlsVersions" = dword:00000001
  "SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
  "SystemDefaultTlsVersions" = dword:00000001
  "SchUseStrongCrypto" = dword:00000001

Se o seu aplicativo for um sistema operacional de 32 bits em 64 bits, modifique também

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
  "SystemDefaultTlsVersions" = dword:00000001
  "SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
  "SystemDefaultTlsVersions" = dword:00000001
  "SchUseStrongCrypto" = dword:00000001

Configure os protocolos SCHANNEL se ainda não tiver feito isso para habilitar o TLS 1.2

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
  "DisabledByDefault" = dword:00000000
  "Enabled" = dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
  "DisabledByDefault" = dword:00000000
  "Enabled" = dword:0xffffffff

Certifique-se de que o TLS 1.1 seja igual ao TLS 1.2 se desejar suportá-lo para aplicativos/navegadores legados. É aconselhável desabilitar cifras fracas, como SSL e, se possível, TLS 1.0 (DisableByDefault = dword:00000001 Enabled=00000001 para cliente e servidor. Essas entradas estão localizadas em TLS 1.0, que está no mesmo nível de TLS 1.1 e TLS 1.2) e reinicie o computador.

Se tudo correr bem, seu aplicativo funcionará novamente ou pelo menos a mensagem usual de risco de segurança devido ao certificado autoassinado. Espero que funcione para você e vote se isso ajuda você a resolver o problema e agradecemos antecipadamente.

Nota: Você pode definir/limpar os valores apropriados do regedit usando os scripts fornecidos aqui:https://www.hass.de/content/setup-microsoft-windows-or-iis-ssl-perfect-forward-secrecy-and-tls-12

Responder2

Senti necessidade de postar depois de muito pesquisar sobre esse artigo. Está essencialmente correto.

eu tive alguns problemas - então sugestões.

  1. use o script na parte inferior da sugestão do site da MS. Ele precisa ser executado como administrador.
  2. Se o script não funcionar, exclua todas as chaves criadas e tente o script novamente.

Por fim, se você causou o problema de atualização para o Server 2019 e seu servidor IIS está se conectando a um servidor SQL 2012, certifique-se de que ele esteja corrigido para SP4. :)

informação relacionada