Certificados SSL comodín y SAAS

No hay nada de malo en "certificados comodín". Un certificado comodín es equivalente a un certificado que contiene mucho de posibles nombres de servidor. Si esto se adapta bien a su problema (por ejemplo, tiene un servidor con una gran cantidad de interfaces que anuncian nombres distintos, pero todos estos nombres están en el mismo dominio y usted controla ese dominio), entonces los certificados comodín son Ciertamente una posibilidad. Los principales problemas con los certificados comodín son:

• Se puede usar un certificado comodín con varios nombres del servidor, y normalmente necesita usar varios nombres porque tiene varias máquinas . Dado que el certificado comodín corresponde a una clave privada una , esa clave privada deberá instalarse en todas estas máquinas. Las claves privadas que están duplicadas y que viajan alrededor son algo menos privadas, porque están más expuestas.

• Las CA comerciales usan un modelo de negocio que se basa en la venta de muchos certificados. Un certificado comodín permite que un cliente compre un certificado uno en lugar de muchos . Por lo tanto, las CA comerciales tienden a hacer que los certificados de comodines sean mucho más caros, para compensar la pérdida de negocios correspondiente.

En su situación, según tengo entendido, usted tiene un servidor de alojamiento que ejecuta un servidor SSL para varios sitios; los sitios tienen nombres que siguen el patrón name.example.com donde name es un nombre específico del cliente, y example.com es un dominio bajo su control. Dado que, en HTTPS , el diálogo SSL aparece primero (antes de que se produzca HTTP), el servidor no (generalmente) conoce el nombre del servidor deseado (el nombre de la URL que usa el cliente), el servidor debe enviar de alguna manera un certificado que "funcione bien" con todos los nombres posibles del cliente. Esto lleva a tres soluciones posibles:

1. Use un certificado comodín con *.example.com . Esto funcionará bien.
2. Use un certificado con muchos nombres en la extensión Subject Alt Name . Puedes poner cientos de nombres ahí. Esto también funciona, pero debe obtener un nuevo certificado cada vez que quiera agregar un nuevo nombre (un certificado está firmado por la CA, no puede cambiar nada sin invalidar la firma).
3. Haga que el servidor "adivine" el nombre del servidor deseado, para que pueda enviar el certificado "correcto" (el servidor tendría muchos certificados, uno para cada nombre de sitio). Esto usa la extensión Server Name Indation : una ranura en los primeros mensajes de protocolo de enlace SSL para que el cliente pueda informarle al servidor, antes el servidor realmente envía su certificado, qué nombre de sitio espera el cliente. SNI funciona bien, excepto que algunos navegadores antiguos o sistemas operativos no lo envían, por lo que usar esta extensión significa que no admitirá dichos clientes. El principal cliente no compatible es Internet Explorer en Windows XP (IE en sistemas Windows más nuevos está bien). Si cree que puede darse el lujo de rechazar clientes que aún utilizan Windows XP e IE, SNI es una solución viable para usted.

El certificado de comodín sigue siendo el método más simple y robusto.

El uso del certificado comodín no es realmente un problema si entiendes las implicaciones.

Sin embargo, si no quiere (o no puede) usar un certificado de comodín, en su caso no tiene más remedio que emitir un certificado nuevo e independiente para cada subdominio.

En teoría, también puede usar el certificado SAN , pero a menos que sepa de antemano la lista completa de dominios en los que está Para garantizar la seguridad, será una solución que crece aún peor que tener un nuevo certificado para cada subdominio.

Ahora, si no está dispuesto a usar un certificado comodín, ¿por qué no está dispuesto a que se emita un nuevo certificado para cada nuevo cliente?

Editar : le preocupa perder todo el sistema en caso de que su clave se vea comprometida. sin embargo, hay pocas razones prácticas por las que dividir el cifrado con varias claves mejorará la seguridad: la única parte que se requerirá para tener acceso a la clave privada son los puntos finales SSL del servidor, asumiendo que tiene poco control sobre lo que sucede en el servidor. Servidor final (y teme que la acción del cliente haga que su propio servidor se vea comprometido, tal vez porque los deja ejecutar su propio código, entonces la solución es implementar un proxy inverso frente a sus servidores que manejará el cifrado público y mantendrá su clave está segura (incluso puede configurar una conexión SSL interna entre el proxy y los servidores si desea cifrar la comunicación dentro de su red).

Tal sistema será más fácil de administrar y seguro que cada servidor use su propio certificado (además, será más barato y se puede implementar con soluciones disponibles).