Server 2016 Não é possível abrir nenhum site SSL

Question

Problema frustrante aqui ... esperamos que alguém tenha visto isso antes, então aqui vai:

Problema: Não consigo abrir nenhum site https: // (SSL) de nenhum produto em execução no Server 2016. Todos os sites não SSL são abertos.

Tentei: Reiniciando.

Navegadores múltiplos: o Chrome exibe os mesmos sintomas, por isso, este NÃO é um problema exclusivo do IE.

O software que usa SSL para se comunicar (ex. Configurações do Windows - > Atualizações) não funciona. Apenas funciona por um tempo e depois expira com "... não pôde se conectar ao serviço de atualização ...".

As resoluções de DNS estão corretas (novamente, sites não-SSL abrem bem). Pingar os mesmos sites SSL resolve / responde muito bem.

sfc / scannow não retornou nenhum problema

O Firewall do Windows está desativado para todos os perfis.

Limpar o estado SSL no IE (Opções do IE - > - > Conteúdo - > [Limpar estado do SSL])

Redefinindo o IE (IE - > Opções - > Avançado - > [Redefinir ...])

Tentei de várias contas de usuário, Admin e não administradores. Todos os perfis de usuário exibem os mesmos sintomas.

(adicionado em 16/01/18): TODOS os outros sistemas físicos e VMs neste hardware / sub-rede acessam todos os sites conforme o esperado. SOMENTE esta VM tem problemas com SSL. Portanto, isso não é um problema de firewall / roteador (o appliance de firewall de hardware está configurado para permitir todas as conexões de saída).

Cenário: Essa é uma VM do servidor de produção 2016 usada para hospedar os serviços do RemoteApps para que meus outros usuários possam executar programas como o QuickBooks de fora do local. Isso também hospeda nossa empresa Wiki executando Atlassian Confluence. A hospedagem de RemoteApps e o alojamento de Wiki funcionam bem; ambos estão rodando através do SSL, o que parece estar funcionando bem para hospedar os serviços.

Nenhum proxy está configurado.

O SQL Server 2016 está instalado (e parece estar funcionando bem)

Alguma ideia? Eu venho fazendo isso há mais de 30 anos ... mas ocasionalmente eu tropeço em um assunto em que começo a questionar minhas direções de vida e esse é um desses casos;)

-Dan

    

Answer 1

RESOLVIDO !!!

O comentário de Aaron sobre o "Network Appliance Firewall" sobre a questão me levou a pensar - eu a dispensei imediatamente, já que tudo funcionou bem por trás do mesmo firewall. Tudo em mim gritava que isso era um certificado raiz, ou SSL ou algum problema relacionado a SSL. Na realidade, não era nada disso.

Estamos usando um firewall Sonicwall, que - sem problemas, eles são ótimos na minha opinião. No entanto, sempre que um "servidor público" é configurado (definido como um nó com algumas portas abertas de modo que ele possa ser acessado de fora, ex. Porta SMTP 25 ou HTTPS 443) ele cria três regras NAT separadas que governam situações como loopbacks (quando uma máquina na LAN está tentando acessar um serviço acessível por WAN, como apps.mycompany.com - o loopback traduz o IP público para o IP da LAN interna).

O problema: eu estava executando os serviços de hospedagem RemoteApps na porta 443, e também Confluence Atlassian em sua porta padrão de 8433. Mas como eu estou rodando diretamente em um fqdn (wiki.companyname.com) eu não queria ter que adicionar um: 8433 a cada solicitação do navegador. Então eu porta traduzido através das solicitações de entrada de tabela NAT para 443 no IP público do Wiki (temos um bloco de 5) para 8433. Assim, 443 externo = 433 interno no IP RemoteApps, mas 443 = 8433 no IP público do Wiki.

A causa: O Sonicwall estava traduzindo as solicitações OUTBOUND do IP LAN (Privativo) do servidor de 443 para 8433. Então, basicamente, cada solicitação https: // estava saindo 8433.

UM POUCO CHECKBOX!

Tudo está bem. Props para Aaron (comentário principal) não necessariamente por estar no local, mas toda aquela coisa de "firewall de dispositivo de rede" simplesmente não se afastaria do fundo da minha mente, e eu comecei a pensar sobre essa tabela NAT ...

Consegui descobrir a solução alterando o endereço IP da LAN do servidor. De repente, funcionou (de saída de qualquer maneira, obviamente, quebrou completamente todas as conexões de entrada, mas eu pretendia apenas como um breve teste). Quando o comportamento mudou com o novo IP da LAN, ele imediatamente eliminou Certs / RootCerts / SSL da equação e me focou no que era especial sobre o IP "quebrado" --- o que me levou à lista de explosões NAT.