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?
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:
- 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.
- 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).
- Saber qué soporte hay para SNI
- Aprender a configurarlo en IIS 8.0