En la práctica, ¿el software criptográfico acepta un * .com o incluso un *. ¿certificado?

De 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 dado presente en      el certificado (por ejemplo, más de un nombre de dNSName, una coincidencia en cualquiera      del conjunto se considera aceptable.) Los nombres pueden contener el comodín      carácter * que se considera que coincide con cualquier nombre de dominio único      Componente o fragmento de componente. Por ejemplo, * .a.com coincide con foo.a.com pero      No es bar.foo.a.com. f * .com coincide con foo.com pero no con bar.com.

Entonces creo que sería posible hacer algo como tener un certificado que coincida con una gran variedad de URLS: *.com , www.*.com y ssl.*.com . Es posible que desee probar certificados de doble comodín (por ejemplo, coincidencia *.*.com ), pero la mayoría de los navegadores no (y no deberían) los aceptan.

Tampoco me sorprendería lo más mínimo si los navegadores modernos rechazaran los comodines en el siguiente nivel desde el dominio de nivel superior (por ejemplo, *.com ).

Es técnicamente posible hacer un certificado que contenga un nombre "* .com" pero, según RFC 2818 (sección 3.1), un comodín coincide con un componente de dominio, no con varios (es decir, sería válido para "example.com" pero no para "www.example.com"). Sin embargo, existe una diferencia entre la especificación y lo que los implementadores hacen de ella. Hay informes que los navegadores algunos aceptan para hacer coincidir un comodín con el dominio varios componentes (es decir, "* .example.com" haciendo coincidir "sub.www.example.com").

Además, la mayoría de los navegadores web modernos incluyen fallos de fallos, que rechazan certificados de comodín demasiado amplios. Consulte esta pregunta : "* .com" e incluso "* .co.uk" serán rechazados por los navegadores, incluso si RFC 2818 no hubiera visto ningún problema con eso.