¿Debería un certificado SSL comodín proteger tanto el dominio raíz como los subdominios?

Hago esta pregunta, porque Comodo me dice que un certificado comodín para * .example.com también asegurará el dominio raíz example.com. Entonces, con un solo certificado, my.example.com y example.com están protegidos sin aviso desde un navegador.

Sin embargo, este no es el caso con el certificado que me han proporcionado. Mis subdominios están bien protegidos y no dan un error, pero el dominio raíz arroja un error en el navegador, diciendo que la identidad no puede ser verificada.

Cuando comparo este certificado con otros escenarios similares, veo que en los escenarios que funcionan sin error, el Nombre alternativo del sujeto (SAN) enumera tanto * .example.com como example.com, mientras que el certificado reciente de Comodo solo enumera *. example.com como el nombre común y NO example.com como el nombre alternativo del sujeto.

¿Alguien puede confirmar / aclarar que el dominio raíz debe aparecer en los detalles de SAN si también se debe proteger correctamente?

Cuando leo esto: http://www.digicert.com/subject-alternative-name.htm Parece que la SAN debe enumerar ambos para que funcione como lo necesito. Cual es tu experiencia

Muchas gracias.

Hay algunas inconsistencias entre las implementaciones de SSL en cómo coinciden con los comodines, sin embargo, necesitará la raíz como un nombre alternativo para que funcione con la mayoría de los clientes.

Para un *.example.comcertificado,

• a.example.com debería pasar
• www.example.com debería pasar
• example.com no debe pasar
• a.b.example.com puede pasar dependiendo de la implementación (pero probablemente no).

Esencialmente, los estándares dicen que *deben coincidir con 1 o más caracteres que no sean puntos, pero algunas implementaciones permiten un punto.

La respuesta canónica debe estar en RFC 2818 (HTTP sobre TLS) :

La coincidencia se realiza utilizando las reglas de coincidencia especificadas por [RFC2459]. Si hay más de una identidad de un tipo determinado en el certificado (por ejemplo, más de un nombre dNSName, se considera aceptable una coincidencia en cualquiera de los conjuntos). Los nombres pueden contener el carácter comodín * que se considera que coincide con cualquier componente de nombre de dominio o fragmento de componente. Por ejemplo, *.a.comcoincide con foo.a.com pero no con bar.foo.a.com. f*.comcoincide con foo.com pero no con bar.com.

RFC 2459 dice:

• Un carácter comodín "*" PUEDE ser utilizado como el componente del nombre más a la izquierda en el certificado. Por ejemplo, *.example.comcoincidiría con a.example.com, foo.example.com, etc. pero no coincidiría con example.com.

Si necesita un certificado para trabajar con example.com, www.example.com y foo.example.com, necesita un certificado con subjectAltNames para que tenga "example.com" y "* .example.com" (o ejemplo .com y todos los demás nombres que pueda necesitar para coincidir).

Estás en lo correcto, el dominio raíz debe ser un nombre alternativo para que se valide.

Todos los proveedores de SSL que he usado agregarán automáticamente el dominio raíz como Nombre alternativo del sujeto a un certificado SSL comodín, por lo que DOMAIN.COM funcionará automáticamente para un certificado comodín * .DOMAIN.COM.

Los certificados comodín se generan idealmente para * .example.com. Para proteger sus subdominios y dominios con este certificado, todo lo que necesita hacer es instalar el mismo certificado en los servidores que apuntan a estos dominios.

Por ejemplo, tiene un certificado comodín para * .example.com one.example.com - servidor 1 ejemplo.com - servidor 2

necesita instalar este certificado en el servidor 1 y el servidor 2.