||This article may be too technical for most readers to understand. (July 2014)|
Depending on the number of subdomains an advantage could be that it saves money and also could be more convenient.
A workaround could be to add every virtual host name in the Subject Alternative Name (SAN) extension. The major problem being that the certificate needs to be reissued whenever a new virtual server is added.
Wildcards can be added as domains in multi-domain certificates or Unified Communications Certificates (UCC). In addition, wildcards themselves can have subjectAltName extensions, including other wildcards. For example: The wildcard certificate *.wikipedia.org has *.m.wikimedia.org as an Subject Alternative Name. Thus it secures https://www.wikipedia.org as well as the completely different website name https://meta.m.wikimedia.org.
In the case of a wildcard certificate for *.company.com, these domains would be valid:
Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops), these domains would not be valid for the certificate:
The "naked" domain is also not valid (it must be added separately as a SubjectAltName):
- Wildcard SSL certificate on Verisign.com
- Wildcard SSL certificate limitation on QuovadisGlobal.com
- No wildcard for an Extended Validation Certificate on Entrust.net
- x509v3_config-Subject Alternative Name
- The subjectAltName field
- The SAN option is available for EV SSL Certificates on Symantec.com
- Need to be reissued whenever a new virtual server is added
- Wildcard domains can be used within UCC on SSL.com
- SSLTools Certificate Lookup of Wikipedia.org's wildcard ssl certificate