Configuración de clientes que no son SNI en un servidor Windows – Certificados SSL –

Hoy en día es una práctica común tener varios sitios web alojados en un servidor con la misma dirección IP. En tales casos, tanto el cliente como el servidor deben admitir la tecnología para solicitar y recibir el certificado coincidente emitido para el dominio. SNI depende de que el cliente envíe el encabezado ServerName durante el protocolo de enlace SSL, lo que significa que es esencial que el cliente admita SNI. Si bien la mayoría de las aplicaciones modernas están configuradas para funcionar con SNI, admitir clientes antiguos/heredados requerirá una configuración adicional.

Este artículo cubrirá el soporte para clientes no compatibles con SNI en Windows Server.

Nota: Puede encontrar la lista de navegadores compatibles con SNI.

Se agregó compatibilidad con SNI a Microsoft IIS a partir de IIS 8.0. Requerir indicación de nombre de servidor es la opción en Enlace de sitio web que permite vincular múltiples certificados a diferentes sitios web con la misma dirección IP:

Para tales enlaces SNI, el servidor esperará el encabezado ServerName. Si un cliente sin capacidad SNI intenta conectarse HTTPS, el servidor no recibirá el encabezado ServerName y no enviará el certificado. Esto dará como resultado un error de protocolo de enlace SSL y, por lo tanto, no se establecerá la conexión HTTPS.

Conexión con el SNI

A continuación puede ver un ejemplo de una conexión SSL con el encabezado ServerName. El servidor comprueba el encabezado y envía el certificado correcto:

Conexión sin SNI

A continuación se muestra un ejemplo de una conexión SSL al mismo servidor sin el encabezado ServerName. Tenga en cuenta que el servidor no envía un certificado:

Solución: Se puede crear un enlace de certificado manual para 0.0.0.0:443, que se utilizará como certificado alternativo para conexiones HTTPS cuando el cliente no haya enviado ningún encabezado ServerName. Es posible configurar solo un certificado alternativo por puerto.

El siguiente comando de PowerShell se utiliza para crear este enlace:

netsh http agregar sslcert ipport=0.0.0.0:443 certhash=thumbprint appid='{5d89a20c-beab-4389-9447-324788eb944a}'

Nota: Deberá iniciar sesión como administrador para ejecutar el comando.

Determinar la huella digital del certificado

Hay varias formas de comprobar la huella digital del certificado:

1. Verifique los certificados instalados en el servidor en PowerShell

   Puede verificar los certificados instalados en el servidor con el siguiente comando: dir Cert:\LocalMachine\My

   Ejemplo:

2. Verifique los enlaces existentes en PowerShell

Los enlaces existentes se pueden revisar con el siguiente comando de PowerShell: netsh http show sslcert

Ejemplo:

3. Verifique las propiedades del certificado en MMC

Puede verificar las propiedades del certificado utilizando el complemento Certificados en MMC. La huella digital se puede encontrar desplazándose hacia abajo en la pestaña Detalles:

4. Decodifica el certificado en decoder.link

Puede comprobar la huella digital decodificando el certificado aquí:
El resultado contendrá la huella digital SHA-1 (huella digital):

Ejecutando el comando en PowerShell

Al final, el comando será similar a este:

netsh http agregar sslcert ipport=0.0.0.0:443 certhash=c09643b93bd9b06430346f8a9ba4feb5f3ebc59b appid='{5d89a20c-beab-4389-9447-324788eb944a}'

Una vez ingresado, el servidor confirmará que se agregó el enlace:

Puede verificar que el enlace se haya agregado revisando los enlaces existentes: netsh http show sslcert

A partir de ahora, el certificado se utilizará cuando el cliente no haya especificado ningún nombre de servidor:

Algunos puntos en conclusión

1. Si solo hay un sitio web alojado en la dirección IP, no es necesario configurar un certificado alternativo. En su lugar, la opción Requerir indicación del nombre del servidor se puede desactivar al crear el enlace.
2. Para las versiones de IIS anteriores a la 8.0, los enlaces solo se pueden crear para direcciones IP (un enlace por dirección IP).
3. Si es necesario configurar varios sitios web para admitir clientes que no son compatibles con SNI, considere utilizar un respaldo.