Um certificado SSL curinga deve proteger o domínio raiz e os subdomínios?

Eu faço essa pergunta, porque a Comodo está me dizendo que um certificado curinga para * .example.com também protegerá o domínio raiz example.com. Portanto, com um único certificado, my.example.com e example.com são protegidos sem aviso prévio de um navegador.

No entanto, este não é o caso do certificado que me foi fornecido. Meus subdomínios estão bem protegidos e não dão erro, mas o domínio raiz gera um erro no navegador, dizendo que a identificação não pode ser verificada.

Quando comparo este certificado a outros cenários semelhantes, vejo que, nos cenários que funcionam sem erros, a SAN (Nome alternativo do assunto) lista * .example.com e example.com, enquanto o certificado recente da Comodo lista apenas *. exemplo.com como o nome comum e NÃO exemplo.com como o nome alternativo do assunto.

Alguém pode confirmar / esclarecer que o domínio raiz deve ser listado nos detalhes da SAN para que também seja protegido corretamente?

Quando li isso: http://www.digicert.com/subject-alternative-name.htm Parece que a SAN deve listar as duas para funcionar como eu preciso. Qual a sua experiência?

Muito obrigado.

Há alguma inconsistência entre as implementações SSL em como elas correspondem aos curingas, no entanto, você precisará da raiz como um nome alternativo para que isso funcione com a maioria dos clientes.

Para um *.example.comcertificado,

• a.example.com deveria passar
• www.example.com deveria passar
• example.com não deveria passar
• a.b.example.com pode passar dependendo da implementação (mas provavelmente não).

Essencialmente, os padrões dizem que *deve corresponder a 1 ou mais caracteres que não são pontos, mas algumas implementações permitem um ponto.

A resposta canônica deve estar na RFC 2818 (HTTP sobre TLS) :

A correspondência é realizada usando as regras de correspondência especificadas por [RFC2459]. Se mais de uma identidade de um determinado tipo estiver presente no certificado (por exemplo, mais de um nome dNSName, uma correspondência em qualquer um dos conjuntos é considerada aceitável.) Os nomes podem conter o caractere curinga * que é considerado como qualquer componente de nome de domínio ou fragmento de componente. Por exemplo, *.a.comcorresponde ao foo.a.com, mas não ao bar.foo.a.com. f*.comcorresponde a foo.com, mas não bar.com.

A RFC 2459 diz:

• Um caractere curinga "*" PODE ser usado como o componente de nome mais à esquerda no certificado. Por exemplo, *.example.comcorresponderia a.example.com, foo.example.com, etc., mas não corresponderia a example.com.

Se você precisar de um certificado para trabalhar em example.com, www.example.com e foo.example.com, precisará de um certificado com subjectAltNames para ter "example.com" e "* .example.com" (ou exemplo .com e todos os outros nomes com os quais você pode precisar).

Você está correto, o domínio raiz precisa ser um nome alternativo para validar.

Cada provedor SSL que eu já usei adicionará automaticamente o domínio raiz como um Nome alternativo do assunto a um certificado SSL curinga, para que o DOMAIN.COM funcione automaticamente para um certificado curinga * .DOMAIN.COM.

Idealmente, os certificados curinga são gerados para * .example.com Para proteger seus subdomínios e domínios com esse certificado, tudo que você precisa fazer é instalar o mesmo certificado nos servidores que apontam para esses domínios.

Por exemplo - você tem certificado curinga para * .example.com one.example.com - servidor 1 exemplo.com - servidor 2

você precisa instalar este certificado no servidor 1 e no servidor 2.