Saltar al contenido

¿Cada subdominio necesita su propio certificado SSL?

Entiende el código correctamente antes de adaptarlo a tu trabajo si tquieres aportar algo puedes dejarlo en la sección de comentarios.

Solución:

Solución 1:

Responderé esto en dos pasos…

¿Necesita un certificado SSL para cada subdominio?

Sí y No, depende. Su certificado SSL estándar será para un solo dominio, digamos www.domain.example. Hay diferentes tipos de certificados que puede hacer además del certificado de dominio único estándar: certificados comodín y multidominio.

  • A certificado comodín será emitido por algo como *.domain.example y los clientes tratarán esto como válido para cualquier dominio que termine con domain.examplecomo www.domain.example o ws.domain.example.

  • A certificado multidominio es válido para una lista predefinida de nombres de dominio. Lo hace mediante el uso del campo Nombre alternativo del sujeto del certificado. Por ejemplo, podría decirle a una CA que desea un certificado de dominio múltiple para domain.example y ws.mysite.example. Esto permitiría que se utilice para ambos nombres de dominio.

Si ninguna de estas opciones funciona para usted, entonces necesitará tener dos certificados SSL diferentes.

¿Necesito una IP dedicada para cada subdominio?

Nuevamente, esto es un sí y un no… todo depende de su servidor web/aplicación. Soy un tipo de Windows, así que responderé con ejemplos de IIS.

  • Si está ejecutando IIS7 o una versión anterior, se ve obligado a vincular los certificados SSL a una IP y no puede tener varios certificados asignados a una sola IP. Esto hace que necesite tener una IP diferente para cada subdominio si está utilizando un certificado SSL dedicado para cada subdominio. Si está utilizando un certificado de dominio múltiple o un certificado comodín, entonces puede salirse con la suya con una sola IP, ya que solo tiene un certificado SSL para empezar.

  • Si está ejecutando IIS8 o posterior, se aplica lo mismo. Sin embargo, IIS8+ incluye soporte para algo llamado Indicación de nombre de servidor (SNI). SNI le permite vincular un certificado SSL a un nombre de host, no a una IP. Por lo tanto, el nombre de host (nombre del servidor) que se usa para realizar la solicitud se usa para indicar qué certificado SSL debe usar IIS para la solicitud.

  • Si usa una sola IP, puede configurar sitios web para responder a solicitudes de nombres de host específicos.

Sé que Apache y Tomcat también son compatibles con SNI, pero no los conozco lo suficiente como para saber qué versiones lo admiten.

Línea de fondo

Según su aplicación/servidor web y el tipo de certificados SSL que pueda obtener, determinarán sus opciones.

Solución 2:

Puede obtener un certificado para cada subdominio, un certificado de múltiples subdominios o un certificado comodín (por *.yoursite.example).

Sin embargo, por lo general cuestan un poco más que los certificados regulares, y debido a que comparte un solo certificado, generalmente no son la mejor opción desde el punto de vista de la seguridad, a menos que aloje un anything.mydomain.example tipo de aplicación donde son la única opción viable.

Tampoco necesita varias direcciones IP si tiene un servidor web compatible con SNI. Dicho esto, SNI solo es compatible con navegadores modernos (IE6 y anteriores no funcionarán con él). Las versiones recientes de Nginx y Apache son compatibles con SNI de forma transparente (solo agregue hosts virtuales habilitados para SSL).

Comentarios y calificaciones

Nos puedes añadir valor a nuestra información participando con tu experiencia en las observaciones.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *