2 votos

Servidor de 2016 No se puede abrir cualquier sitios SSL

Frustrante problema aquí...esperemos que alguien más ha visto esto antes, así que aquí va:

Problema: No puedo abrir cualquier https:// (SSL) de los sitios de cualquiera de los productos ejecuta en el Servidor de 2016. No todos los sitios SSL abrir bien.

Probado: De reiniciar.

Varios navegadores: Chrome exhibe la idénticos síntomas, así que NO es IE-exclusiva problema.

El Software que utiliza SSL para comunicarse (ex. Configuración de Windows -> Actualizaciones) no funciona. Sólo se ejecuta durante un tiempo y luego se agota con "...no podía conectar con el servicio de actualización de...".

DNS resuelve están bien (de nuevo, no-SSL sitios abiertos fina). Ping en el mismo SSL-sitios resuelve/respuestas bien.

sfc /scannow devuelto sin problemas

Firewall de Windows está desactivado para todos los perfiles.

Compensación Estado de SSL en IE (IE -> Opciones -> Contenido -> [Borrar Estado SSL])

Restablecimiento de IE (IE -> Opciones -> Avanzado -> [Reset...])

Intentado de varias cuentas de usuario, Admin y no de administrador por igual. Todos los perfiles de usuario de exhibición de la idénticos síntomas.

(Añadido 01/16/18): TODOS los otros sistemas físicos y VM en este hardware/subred de acceso a todos los sitios, como se esperaba. SÓLO de esta máquina virtual tiene problemas con SSL. Así que esto no es un firewall/router problema (firewall de hardware dispositivo está configurado para permitir TODAS las conexiones salientes).

Escenario: Este es un Servidor de producción 2016 VM utilizan para el alojamiento de RemoteApps servicios para mis otros usuarios pueden ejecutar programas, tales como QuickBooks desde fuera del establecimiento. Esto también alberga nuestra empresa Wiki ejecución de Atlassian Confluence. Ambos RemoteApps de hosting y la Wiki de alojamiento funcionan bien; ambos se ejecutan a través de SSL, que parece estar funcionando bien para el alojamiento de los servicios.

Sin proxies están configurados.

SQL Server 2016 está instalado (y parece estar funcionando bien)

Alguna idea? He estado haciendo esto por más de 30 años...pero de vez en cuando me tropiezo en un tema donde empiezo a dudar de mi vida direcciones y este es uno de esos casos ;)

-Dan

1voto

Dan Neuwirth Puntos21

RESUELTO!!!

Aarón comentario acerca de que "el Aparato de la Red de cortafuegos" en la pregunta me puso a pensar-yo de inmediato descartó, como todo lo demás funcionaba muy bien detrás de ese mismo firewall. Todo en mí me gritaba que esta era una de certificados root, o SSL o algunos relacionados con SSL problema. En realidad, se trataba de nada de eso.

Estamos usando un cortafuegos Sonicwall, que--no hay problemas, son geniales, en mi opinión. Sin EMBARGO, cada vez que un "servidor público" (definido como un nodo con algunos puertos abiertos tales que se puede acceder desde fuera, ex. Puerto SMTP 25 o HTTPS 443) crea tres reglas de NAT que rigen situaciones tales como bucles de retorno (cuando una máquina de la LAN está tratando de acceder a una WAN-servicio accesible tales como aplicaciones.mycompany.com--el bucle se traduce la dirección IP pública a la interna de la IP de la LAN).

El problema: yo estaba corriendo RemoteApps servicios de alojamiento en el Puerto 443, y también Atlassian Confluence en su defecto el puerto de 8433. Pero ya me estoy corriendo directamente en un fqdn (wiki.companyname.com) yo no quiero tener que agregar un :8433 a cada petición del navegador. Así que el puerto traducido a través de la tabla de NAT entrante solicitudes de 443 en la Wiki de la IP pública (tenemos un bloque de 5) para 8433. Por lo tanto 443 externo = 433 interna en el RemoteApps IP, pero 443=8433 en la Wiki IP pública.

La causa: El dispositivo Sonicwall fue la traducción de solicitudes DE SALIDA del servidor LAN (Privada) dirección IP de 443 a 8433. Así que, básicamente, cada https:// petición iba a salir 8433.

UN POCO DE CASILLA!

Todo está bien. Apoyos a Aarón (comentario de arriba) no necesariamente por ser irregular, pero que todo el "aparato de la red de cortafuegos" cosa que no salen desde el fondo de mi mente, y empecé a pensar en que la tabla de NAT...

Yo era capaz de averiguar la solución cambiando la dirección IP de la LAN del servidor. De repente funcionó (salida de todos modos, obviamente es completamente rompió todas las conexiones entrantes, pero yo sólo había pensado como un breve test). Cuando el comportamiento ha cambiado con la nueva IP de la LAN, es inmediatamente eliminado Certs/RootCerts/SSL a partir de la ecuación y me enfoque en lo que es especial acerca del "roto" IP---que me llevan a el chorro de NAT lista.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

;