[Perdón si esta pregunta es un poco larga, hay mucha información adicional en caso de que sea relevante]
Descripción general
Tengo un problema con SSL en una granja de carga equilibrada de 4 VM en Azure. Si la solicitud HTTPS llega al primer servidor de la granja, todo está bien. Si llega a cualquiera de los otros 3, entonces la llamada falla. Chrome emitirá un error de protocolo SSL, IE y Firefox simplemente dicen que no se puede mostrar la página.
La puesta en marcha
Tengo cuatro máquinas virtuales con Windows Server 2012 en Azure (instancia pequeña como solo prueba). Las máquinas virtuales están en el mismo servicio de nube y conjunto de disponibilidad. Se han agregado puntos finales con equilibrio de carga para los puertos 80 y 443 (el retorno directo al servidor esNOhabilitado en estos). Las cuatro máquinas se configuraron mediante el mismo script de PowerShell y, con dos excepciones, se configuraron completamente de esta manera.
La configuración de IIS de cada servidor está configurada para utilizar una configuración compartida, que se replica mediante DFS a cada servidor desde el primer servidor del grupo. Esto se configuró manualmente para cada servidor y funciona bien.
DFS también se utiliza para replicar la carpeta web desde el primer servidor a los demás.
También descubrí la "nueva" función de Certificados centralizados después de escribir el script de implementación, por lo que también se instaló y configuró manualmente en los cuatro servidores. Estoy usando un recurso compartido en un servidor separado para almacenar los archivos de certificado.
La solicitud de certificado se generó en el primer servidor y utilicé SSL.com para obtener un SSL gratuito de 90 días para una dirección subdomain.domain.com. Agregué un registro CNAME subdomainal DNS para domain.comapuntar a la cloudappdirección de Azure.
Importé el certificado SSL al primer servidor, luego lo exporté nuevamente como subdomain.domain.com.pfx(con una contraseña) y lo copié en el recurso compartido de archivos del certificado. Al verificar los certificados centralizados en los cuatro servidores, enumeran el certificado correctamente sin íconos de error que indiquen que la contraseña en la configuración era incorrecta, etc.
Finalmente, cambié los enlaces del servidor 1 para agregar https con el nombre de host subdomain.domain.comy con elRequerir indicación del nombre del servidoryUtilice el almacén de certificados centralizadoopciones marcadas. Al comprobar los otros servidores, se muestran los enlaces propagados como se esperaba.
El problema
Agregué una página básica que simplemente muestra el nombre del servidor que manejó la solicitud. Si descargo el acceso a varias ventanas de IE http://subdomain.domain.com, imprimirán una variedad de nombres de servidores, mostrando que la configuración de IIS y los archivos web se están implementando correctamente, y que el equilibrio de carga de Azure también está haciendo sus cosas. Lo cual me pareció realmente genial.
Sin embargo, se va por el desagüe cuando intento esto a través de HTTPS. Solo las solicitudes que llegan al primer servidor tienen éxito, el resto falla y se quema con "Esta página no se puede mostrar" o "Error de protocolo SSL", según el navegador con el que pruebo. En el servidor 1, la página se muestra bien, el certificado se puede ver y no hay errores de certificado.
Estoy seguro de que esto es un problema de configuración en los servidores en alguna parte, pero no puedo decir qué diablos es. La mayor parte de lo que estoy jugando es nuevo para mí, ya que en el pasado hemos usado servidores Windows 2003 físicos sin clústeres con IIS6.
Lo que es aún más desconcertante es que apagué las cuatro máquinas virtuales durante la noche, y cuando reinicié el servicio esta mañana, el servidor 2 ahora aparentemente responde a las solicitudes SSL además del servidor 1. Sin embargo, dicho esto, ayer también hice un apagado completo y Aún así, solo el servidor 1 funcionó después de eso.
Los archivos de registro de IIS no muestran las solicitudes SSL fallidas, solo un grupo de 200 para el puerto 80 y una combinación de 200 y 304 para el puerto 443 en los servidores 1 y 2.
He hecho algunas diligencias debidas con las búsquedas de Google, pero nada arroja luz. De hecho, exactamente lo contrario, por lo que puedo decir, lo que he hecho debería funcionar.
Cualquier consejo que ayude a resolver esto será bienvenido.
Respuesta1
Quería compartir algunos pasos que deberían resolver la mayoría de los problemas con el almacén de certificados centralizado en IIS. El almacén de certificados centralizado (CCS) crea un enlace de certificado falso que utiliza para canalizar las solicitudes de certificados SSL hacia el CCS. Si este enlace no está presente o hay varios enlaces en la misma dirección IP, recibirá errores del navegador cuando los clientes intenten conectarse a sitios web habilitados para SSL.
Considere la siguiente configuración; un servidor IIS con dirección IP 172.16.0.41y almacén de certificados centralizado habilitado contiene dos dominios; www.adomain.comy www.bdomain.com. Los paquetes de certificados PFX se instalan en el almacén de certificados centralizado de IIS para cada uno de los dominios.
Normalmente hay dos errores;
PROBLEMA 1
Cuando los navegadores se conectan al sitio web, se comparte el certificado incorrecto. Por ejemplo, visitar www.adomain.comla primera vez da como resultado que se entregue el certificado correcto; sin embargo, cuando un navegador visita www.bdomain.com, se devuelve el certificado www.adomain.com, lo que hace que el navegador marque un error de certificado no válido.
SOLUCIÓN
El motivo de este problema suele deberse a que varios sitios web están vinculados a la misma dirección IP y al menos uno de los sitios web no está habilitado.Requerir identificación del nombre del servidor. Sin esta configuración habilitada para todos los sitios web que comparten la misma IP y PUERTO, IIS no puede determinar qué certificado servir y, por lo tanto, unel primero en ganarla política parece aplicarse.
Esto significa que las solicitudes posteriores a otros sitios web alojados en el mismo servidor IIS devuelven el certificado incorrecto.
Pasos para resolver
Asegúrese de que cada sitio web esté configurado en
Require Server Name Identification. Haga esto haciendo clic en cada sitio web en el Administrador de IIS, eligiendo Enlaces...->Seleccione el enlace HTTPS->Elija Editar->VerificarRequire Server Name Identificationy asegúrese deUse Centralized Certificate Storeque también esté marcado.Verifique los enlaces en el servidor. Desde un cuadro de comando elevado ejecutar
netsh http show sslcert
La vinculación para el CCS debe estar presente:
SSL Certificate bindings:
-------------------------
Central Certificate Store : 443
Certificate Hash : (null)
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : (null)
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Tenga en cuenta que el enlace con el (null)Hash de certificado indica la presencia del enlace de paso CCS. Si hay otros enlaces escuchando en la dirección IP de su servidor y el puerto SSL ( 172.16.0.41:443en nuestro escenario), deben eliminarse.
Para eliminar los enlaces, escriba
netsh http delete sslcert <binding>. En nuestro escenario esto sería asínetsh http delete sslcert 172.16.0.41:443y el enlace debería eliminarse. El(null)enlace de paso CCS no se debe eliminar. Si este enlace no está presente, consultePROBLEMA 2abajo.Restablezca iis
iisresety conéctese a cada dominio en el servidor web. Se debe compartir el certificado correcto. También puede verificar los enlaces repitiendo el paso 2 y asegurándose de que noIP:PORTexistan enlaces específicos para su puerto SSL y la IP del servidor web.
PROBLEMA 2
Incluso después de confirmar que el almacén de certificados centralizado está habilitado, tiene visibilidad en los certificados y todos los sitios web están obligados a usarlo, cuando un navegador se conecta al sitio web arroja un error Page Cannot be displayedo invalid encryption. El sitio web deseado no se muestra.
En IE (Edge), esto normalmente se manifestará como una sugerencia para verificar que los tipos de cifrado adecuados estén habilitados en el navegador.
Un iisresetreinicio o reinicio del servidor no resuelve el problema.
SOLUCIÓN
Esto parece ser un error en la creación del enlace de transferencia CCS. No se crea en el servidor web cuando la funcionalidad CCS está habilitada para que las solicitudes entrantes de un certificado se eliminen silenciosamente.
Pasos para resolver
Primero verifique que el Almacén de certificados centralizado esté habilitado y pueda ver todos los certificados en su ruta. Para hacer esto,
IISManagerseleccione el nodo del servidor->Certificados centralizados (en la sección Administración)->Editar configuración de funciones... y asegúrese de que esté configurado y habilitado.Compruebe que todos los sitios web que utilizan certificados comunes estén vinculados al CCS. Haga esto haciendo clic en cada sitio web en el Administrador de IIS, eligiendo Enlaces...->Seleccione el enlace HTTPS->Elija Editar->Verificar
Require Server Name Identificationy asegúrese deUse Centralized Certificate Storeque también esté marcado.Compruebe que se haya creado el enlace CCS. Correr
netsh http show sslcert. Si los resultados están vacíos o el(null)certificado de transferencia no está presente (consulte el paso 2 en PROBLEMA 1 para ver cómo se ve el enlace CCS), el enlace CCS no se ha habilitado.SSL Certificate bindings: -------------------------En el Administrador de IIS, eligiendo un sitio web que utilice CCS, haga clic en Enlaces...->Seleccione el enlace HTTPS->Elija Editar->ydesmarcar
Use Centralized Certificate StoreydesmarcarRequire Server Name Identification.
En el SSL certificatemenú desplegable, seleccione el WMSVCcertificado predeterminado del servidor y haga clic en OK. Deja la Site Bindingsventana abierta.
Vuelva al símbolo del sistema elevado y ejecute
netsh http show sslcert. Esto debería producir un enlace como este:SSL Certificate bindings: ------------------------- IP:port : 172.16.0.41:443 Certificate Hash : 64498c920fecb31b8f7ccbdac2fa2baa2ec4f19a Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914} Certificate Store Name : My Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : DisabledRegrese a la
Site Bindingsventana y revierta los cambios del Paso 4. HabiliteRequire Server Name IndicationyUse Centralized Certificate Storehaga clic enOK.Vuelva al símbolo del sistema elevado y ejecútelo
netsh http show sslcertuna vez más y, si los dioses le sonríen, el enlace del Almacén de certificados centralizado debería haber surgido, reemplazando el enlace actual:SSL Certificate bindings: ------------------------- Central Certificate Store : 443 Certificate Hash : (null) Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914} Certificate Store Name : (null) Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled
Si ve el enlace del certificado anterior con el (null)valor, Certificate Hashha funcionado y el paso de CSS ahora debería estar habilitado.
- Inicie un navegador e intente conectarse a los dominios del servidor a través del socket seguro (HTTPS) y todo debería estar bien.
Notas importantes
Debe repetir este proceso en cada servidor web de su granja web. Debería ser posible a través de PowerShell para automatizar y verificar el proceso.
Una vez que se haya creado el enlace de transferencia, se conservará indefinidamente (a menos que desactive la compatibilidad con certificados centralizados en el nodo).
Como un aparte; este enlace tiene información sobre cómo funciona el CCS a nivel técnico y vale la pena leerlo:https://blogs.msdn.microsoft.com/kaushal/2012/10/11/central-certificate-store-ccs-with-iis-8-windows-server-2012/
Espero que eso ayude.