El título es así de largo proque realmente trato varios temas que están relacionados yq ue a muchos programadores Web les pueden a resultar útiles.
Primeramente, pregunta típica: ¿puedo utilizar varios certificados SSL (Secure Sockets Layer) en un mismo servidor Internet Information Server (IIS)?
Respuesta: Sí y No.
Un servidor IIS 6.0 permite por defecto asignar varios certificados a servidores virtuales diferentes siempre y cuando éstos funcionen cada uno en un puerto distinto. Así, si usamos en alguno un puerto no estándar (distinto al 443), pues entonces sí nos deja, pero vamos, esto dista bastante de ser una buena solución. También nospermite tener dos certificados en dos servidores virtuales diferentes si cada uno de ellos utiliza una IP distinta. Tampoco es muy útil.
Si vamos al diálogo "Avanzadas" de la pestaña general de propiedades de un sitio Web de IIS, veremos que aunque en peticiones sin encriptar nos permite definir tantos encabezados de host como queramos en la misma IP y mismo puerto para así distinguir unas peticiones de otras, en el caso de SSL sólo nos deja indicar una IP y un puerto, sin posibilidad de distinguir encabezados de host:
Por este motivo, si en dos sitios Web utilizan la misma IP y el puerto estándar 443 y les asociamos un certificado de servidor para que cifren las ocmunicaciones con SSL, en cuanto lo hagamos con el segundo éste se nos parará. No nos dejará arrancarlo de nuevo porque nos dice que no puede haber dos servidores escuchando en el mismo puerto.
Si tuviésemos la posibilidad de distinguir las peticiones SSL por encabezado de host, como pasa en peticiones normales sin encriptar, entonces ya estaría el tema solucionado. El problema es que, por definición, la información viaja encriptada (incluyendo la petición y el encabezado de host) por lo que IIS no tiene manera de determinar ese encabezado de host hasta que lo desencripta en el servidor con el certificado adecuado. Es decir, que si antes no sabe qué certificado utilizar entonces no puede determinar el encabezado de host que tiene la petición, y viceversa. Es un típico problema recursivo que crea esta limitación. Antes de que algún anti-MS salte a la yugular diré, por si no está suficientemente claro aún con la explicación, que se trata de una limitación de SSL no de IIS. Le pasa a todos los servidores web.
Entonces ¿cómo solucionamos el asunto?
Bueno, la conclusión es que sólo podremos distinguir entre unas peticiones y otras si usamos para todas ellas el mismo certificado. Pero por definición cada sitio web (con un dominio distinto) tiene que tener un certificado diferente, o entonces podríamos desencriptar pero fallaría la autenticaicón del servidor pues no se correspondería con el dominio (¿me explico?). Por lo tanto la única solución es que todos esos dominios que queremos proteger deben tener el mismo dominio o subdominio principal, y debemos asignar al servidor un certificado comodín, es decir, uno que sirva para proteger un dominio y todos sus subdominios.
Así, podremos proteger con un mismo certificado comodín por ejemplo a los dominios: shop.campusmvp.com, www.campusmvp.com y aulas.campusmvp.com, o cualesquiera otros que compartan un mismo sufijo en el dominio. El certificado que usemos debe certificar al dominio comodín: *.campusmvp.com.
Estos certificados comodín los tenemos que pedir expresamente a nuestro proveedor de certificados (Thawte, verisign, Camaras.org o quien sea). Generalmente son bastante más caros que los normales puesto que, realmente, les estás fastidiando el negocio porque con un solo certificado proteges varios dominios, así que se aseguran unas ganacias penalizándote el precio.
Si tienes que proteger varios dominios distintos no te quedará más remedio que asignarle una IP diferente a cada uno. Efectos secundarios de la seguridad ;-)
Asignación de encabezados de host a cada subdominio
Vale. supongamos entonces que quieresproteger varios subdominios con un certificado comodín. Según he dicho antes no vamos a poder de todos modos establecer el encabezado de host porque la herramienta de administración de IIS no nos lo permite. Entonces ¿cómo lo hacemos?
El proceso es el siguiente. Instalas el certificado en el primero de los dominios y le asignas el puerto 443 a la IP que le corresponda. Ahora debes usar una herramienta de script administrativo de IIS para establecer el encabezado. Abres una línea de comandos, vas hasta la carpeta de scipts administrativos (por defecto C:\InetPub\AdminScripts) y escribes lo siguiente:
cscript.exe adsutil.vbs set /w3svc/<ID del servidor virtual>/SecureBindings ":443:subdominio.dominio.com"
Por ejemplo:
cscript.exe adsutil.vbs set /w3svc/1669802537/SecureBindings ":443:mcs.krasis.es"
Vale. Primera dificultad: hay que averiguar cuál es el identificador de nuestro servidor virtual :-?
Para ello tienes que irte a la metabase de IIS y buscarlo entre todo ese infernal XML :-( Así que mucho mejor vamos a usar una herramienta que lo haga por nosotros. Si te descargas el Resource Kit de IIS 6.0, dentro del mismo hay una herramienta llamada IIS Metabase Explorer que te permite hacer lo que su nombre indica: bucear en la metabase sin tener que lidiar directamente con ella. Instálala y podrás averiguar fácilmente el identificador de tu servidor virtual viéndolo en el nodo correspondiente de la rama LM\W3SVC, como en esta figura:
Pulsa para aumentar
Con esto es coser y cantar pues sólo tienes que copiar el "numerito" y ya podrás asignarle el certificado al subdominio (o subdominios) que necesites.
Ahora sólo resta repetir la misma operación en el resto de subdominios/servidores virtuales y listo.
Espero que esto le resulte útil a mucha gente.
En el próximo post voy a comentar algo muy interesante relacionado con este tema: cómo crear y asignar automáticamente certificados SSL a nuestros dominios creados y firmados por nosotros mismos para pruebas o para uso privado. Y lo mejor: sin tener que instalar ningún tipo de infraestructura PKI (Infraestructura de clave pública) y con un simple programita de línea de comandos :-)