Cuando un navegador se conecta a un servidor web usando el protocolo comúnmente conocido como SSL (Secure Sockets Layer, de manera más formal SSL/TLS: Transport Layer Security), las comunicaciones se cifran entre ambos con el triple objeto de:

  • Evitar que se puedan inspeccionar (cifrado)
  • Evitar que se puedan modificar (no repudio)
  • Autenticar al servidor, y opcionalmente al cliente, aunque no es lo habitual (autenticación).

El handsahe de TLS se produce antes de que se intercambien cabeceras algunas entre cliente y servidor. Es decir, que en la comunicación que se inicia todo el tráfico va encriptado, incluso las propias peticiones, lo cual incluye el propio nombre de dominio al que nos conectamos. Esto presenta una dificultad para el servidor ya que hasta que recibe la petición y la descifra no sabe a qué dominio nos queremos conectar, pero si no lo sabe ¿cómo sabe qué certificado debe utilizar?

SSL-Secure

La respuesta tradicional a este problema ha sido que cada certificado SSL estuviese asignado a una única dirección IP. De este modo, según la dirección IP a la que se estuviese realizando la llamada, el servidor podría saber perfectamente qué certificado le correspondía, usar su clave privada para descifrar la petición inicial e iniciar el proceso de comunicación.

Esta solución, aunque válida, tenía varias pegas importantes, pero sobre todo estas dos:

  1. Si hay más de un dominio albergado en la misma IP, cualquier conexión a dicha IP a través e otros dominios no asociados al mismo certificado SSL generarían un aviso de seguridad por parte del navegador. El motivo es que se recibe la petición, se atiende con el certificado asociado a la IP, pero el nombre de dominio solicitado y el del certificado no coinciden.
  2. Si queríamos usar más de un certificado SSL en un servidor teníamos que disponer como mínimo de tantas direcciones IPs como certificados, lo cual encarece y complica la gestión del servidor. Además es un impedimento enorme para las empresas de hosting.

Para tratar de solucionar estas pegas se definieron unas extensiones al protocolo SSL/TSL llamadas Server Name Indication o SNI. Lo que hacen es que incluyen el nombre del dominio como parte de la negociación inicial (o handshake) de SSL/TSL. Esto permite al servidor saber cuál es el dominio al que nos queremos conectar y utilizar así el certificado apropiado. Gracias a estas extensiones los problemas mencionados anteriormente se pueden solventar de un plumazo.

Además permite la utilización de certificados SSL de tipo "wildcard", es decir, que sirven para cualquier subdominio de un dominio dado. Podemos comprar un certificado de tipo *.dominio.com y que sirva para cualquier subdominio de éste: subdom.dominio.com, otro.dominio.com, etc... lo cual puede ser muy útil (por cierto, estos certificados wildcard son mucho más caros que los normales).

Es más, en teoría con SNI podríamos tener un certificado SSL asociado a múltiples dominios diferentes a la vez, aunque en la práctica no se utilizan por la dificultad de gestión (por ejemplo, habría que anular el certificado y crear uno nuevo ante cualquier cambio en la lista de dominios).

Soporte de SNI

Lo bueno es que SNI es ya bastante antiguo y podemos afirmar que la práctica totalidad de los navegadores ofrecen la posibilidad de utilizarlo. En el caso de Internet Explorer, la versión 7.0 o posterior sobre Windows Vista o posterior es capaz de utilizar SNI (en XP no funciona, pero nadie debería usar XP a estas alturas, y menos con IE). El resto de los navegadores no tienen problema.

En el caso de los servidores web también prácticamente todos lo soportan en sus últimas versiones. En el caso concreto de Internet Information Server, el soporte se ofrece a partir de su versión 8.0, es decir, con Windows Server 2012 o posterior.

Uso en Internet Information Server 8.0

En el caso de IIS 8.0 su uso es muy sencillo. Una vez que tenemos instalado el certificado digital para un dominio, si vamos al servidor virtual correspondiente en el IIS Manager y pulsamos sobre la opción "bindings", podemos añadir un nuevo enlace para HTTPS con este diálogo:

SNI-IIS-8-Configuracion

Pulsa para aumentar

Como vemos tenemos una zona de configuración para el nombre de dominio en el que podremos introducir el dominio exacto con el que está relacionado el certificado SSL. Obviamente éste debe coincidir con el dominio para el que hemos solicitado el certificado, o no funcionará correctamente.

Además debemos marcar la opción de requerir el uso de SNI, justo debajo.

Con esto el servidor comenzará a aceptar peticiones SSL/TSL desde los navegadores, sabiendo de antemano el nombre del dominio y por tanto pudiendo albergar varios dominios SSL asociados a la misma IP sin problemas.

En su día, hace ya muchos años, expliqué cómo conseguir algo similar a esto con Internet Information 6.x.

En el próximo post voy a explicar cómo "hackear" IIS 7.x para que nos permita hacer lo mismo, aunque en teoría no soporte SNI ;-)

¡Espero que te sea útil!

¿Este post te ha ayudado?, ¿has aprendido algo nuevo? Entonces, me niego a creer que no puedas donar ni 1€ a los que necesitan algo tan básico como comer. Por cada euro que pongas tú, yo pondré otro.
¡No pases de ellos! También es tu responsabilidad.
Vamos a ayudarlos juntos