¿Qué certificados son necesarios para los subdominios de varios niveles?

Teóricamente:

• un * coincide exactamente con un nivel (por lo tanto, *.foo.com no no coincide con foo.com )
• pero puede tener varios * en un nombre

Por lo tanto, si todas las implementaciones de SSL siguen fielmente RFC 2818 , solo necesita tres certificados, con nombres:

• foo.com
• *.foo.com
• *.*.foo.com

y, si las implementaciones son realmente buenas para cumplir con RFC 2818 y las complejidades de X.509, incluso podría usar un certificado único que enumera las tres cadenas anteriores en su extensión de Asunto Alt Nombre .

Ahora, la teoría y la práctica coinciden perfectamente ... en teoría. Es posible que tenga sorpresas con lo que realmente hacen los navegadores. Te sugiero que lo pruebes; algunos ejemplos de certificados se pueden crear con la herramienta de línea de comandos OpenSSL (vea por ejemplo esta página para algunas pautas).

RFC 6125 es bastante reciente y no está implementado por todos, pero intenta aclarar algunos de estos problemas. Reúne la especificación de identidad en RFC 2818 y RFC de otros protocolos. Le sugeriría que se adhiera a RFC 6125 si puede. Las secciones relevantes para los certificados comodín son 6.4.3 y 7.2 (lo que desalienta el uso de certificados comodín, de hecho).

De su pregunta no queda claro si desea ejecutar un solo servidor web (o al menos poder ejecutarlo todo con una sola dirección IP), o si puede tener un certificado por sitio (y por lo tanto una dirección IP por sitio, ya que SNI no está muy bien soportado en general).

Podría tener un solo certificado con varios nombres alternativos de sujeto (SAN). El problema proviene del caso con dos etiquetas comodín, que pueden no estar claramente especificadas ( *.*.foo.com ).

Si el comodín doble funciona, debería funcionar un certificado con estas 3 entradas de SAN DNS:

• foo.com
• *.foo.com
• *.*.foo.com

Sin embargo, dado que es posible que no funcione (dependiendo de las implementaciones del cliente, que probablemente no estén bajo su control), y como puede enumerar los 50 estados, podría tener 52 entradas de DNS de SAN:

• foo.com
• *.foo.com
• *.ny.foo.com
• ... (uno para cada estado)

  

¿Cómo puedo asegurarme de que los usuarios vean todos estos subdominios como   legítimamente propiedad de nosotros? Por ejemplo, si un usuario visita foo.com, entonces   mountain-view.ca.foo.com, y esos son certificados diferentes, lo harán   ellos reciben una advertencia? ¿Hay alguna manera de asegurar su navegador que   estos certificados comparten el mismo propietario?

Esta es una pregunta difícil, ya que depende de qué tan familiarizados estén los usuarios con el proceso de verificación de certificados. Podría obtener un certificado de Validación ampliada (aunque creo que el certificado de comodín EV probablemente no esté permitido), lo que daría una barra verde. Esto daría alguna etiqueta de "propiedad" en la mayoría de los navegadores. Después de eso, las propias interfaces del navegador pueden ser confusas (por ejemplo, Firefox "que se ejecuta mediante (desconocido)" en la barra azul, lo que realmente no ayuda de ninguna manera). En última instancia, los usuarios podrían ir y verificar dentro de su certificado para ver a qué SAN se emitió el certificado. Sin embargo, dudo que muchos hagan esto y entiendan lo que significa.

enlace dice

  

Más aún, los certificados ssl DigiCert WildCard son únicos en permitir   Puede proteger CUALQUIER subdominio de su dominio, incluidos múltiples niveles   de subdominios con un certificado. Por ejemplo, su comodín para   * .digicert.com com podría incluir server1.sub.mail.digicert.com como nombre alternativo del sujeto.

Puede usar un certificado de comodín o también puede utilizar un certificado con nombres de dominio alternativos. Personalmente, uso un certificado de StartSSL que me permite tener todos mis dominios listados en un solo certificado. Tengo algo como 10 dominios comodín y 15 otros ADNs, todos en el mismo certificado, de modo que puedo usar SSL en los sitios que tengo alojados en mi servidor.