In pratica, il software crittografico accetta un * .com o o anche un *. certificato?

Da RFC-2818 - HTTP su TLS :

Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Quindi credo che sarebbe possibile fare qualcosa come avere un certificato che corrisponda a una vasta gamma di URL: *.com , www.*.com e ssl.*.com . Potresti provare certificati con caratteri jolly (ad esempio,% match*.*.com), ma la maggior parte dei browser non li accetterà (e non dovrebbe).

Inoltre, non sarei minimamente sorpreso se i browser moderni non consentissero le wild card al livello successivo dal dominio di primo livello (ad esempio *.com ).

È tecnicamente possibile creare un certificato che contenga un nome "* .com" ma, come per RFC 2818 (sezione 3.1), un carattere jolly corrisponde a un componente di dominio, non a diversi (vale a dire sarebbe valido per "esempio.com" ma non per "www.esempio.com"). Tuttavia, c'è una differenza tra le specifiche e ciò che gli implementatori fanno. Ci sono rapporti che i alcuni browser accettano per abbinare un jolly con diversi dominio componenti (es. "* .example.com" corrispondente a "sub.www.example.com").

Inoltre, la maggior parte dei browser Web moderni include fail-safe, che rifiutano i certificati jolly eccessivamente ampi. Vedi questa domanda : "* .com" e persino "* .co.uk" saranno rifiutati dai browser, anche se RFC 2818 non avrebbe riscontrato alcun problema.