A Public key certificate which uses an asterisk *
(the wildcard) in its domain name fragment is called a Wildcard certificate.
Through the use of *
, a single certificate may be used for multiple sub-domains.
It is commonly used for transport layer security in computer networking.
A single wildcard certificate for https://*.example.com
will secure all these subdomains on the https://*.example.com
domain:
payment.example.com
contact.example.com
login-secure.example.com
www.example.com
Instead of getting separate certificates for subdomains, you can use a single certificate for all main domains and subdomains and reduce cost.[1]
Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops),[2] these domains would not be valid for the certificate:
test.login.example.com
The "naked" domain is valid when added separately as a Subject Alternative Name (SubjectAltName
):[3]
example.com
Note possible exceptions by CAs, for example wildcard-plus cert by DigiCert contains an automatic "Plus" property for the naked domain example.com
.
Only a single level of subdomain matching is supported in accordance with RFC 2818.[4]
It is not possible to get a wildcard for an Extended Validation Certificate.[5] A workaround could be to add every virtual host name in the Subject Alternative Name (SAN) extension,[6][7] the major problem being that the certificate needs to be reissued whenever a new virtual server is added. (See Transport Layer Security § Support for name-based virtual servers for more information.)
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 a Subject Alternative Name. Thus it secures www.wikipedia.org
as well as the completely different website name meta.m.wikimedia.org
.[8]
RFC 6125 argues against wildcard certificates on security grounds, in particular "partial wildcards".[9]
The wildcard applies only to one level of the domain name. *.example.com
matches sub1.example.com
but not example.com
and not sub2.sub1.domain.com
The wildcard may appear anywhere inside a label as a "partial wildcard" according to early specifications[10]
f*.domain.com
is OK. It will match frog.domain.com
but not frog.super.domain.com
baz*.example.net
is OK and matches baz1.example.net
*baz.example.net
is OK and matches foobaz.example.net
b*z.example.net
is OK and matches buzz.example.net
However, use of "partial-wildcard" certs is not recommended. As of 2011, partial wildcard support is optional, and is explicitly disallowed in SubjectAltName headers that are required for multi-name certificates.[11] All major browsers have deliberately removed support for partial-wildcard certificates;[12][13] they will result in a "SSL_ERROR_BAD_CERT_DOMAIN" error. Similarly, it is typical for standard libraries in programming languages to not support "partial-wildcard" certificates. For example, any "partial-wildcard" certificate will not work with the latest versions of both Python[14] and Go. Thus,
Do not allow a label that consists entirely of just a wildcard unless it is the left-most label
sub1.*.domain.com
is not allowed.A cert with multiple wildcards in a name is not allowed.
*.*.domain.com
A cert with *
plus a top-level domain is not allowed.
*.com
Too general and should not be allowed.
*
International domain names encoded in ASCII (A-label) are labels that are ASCII-encoded and begin with xn--
.
Do not allow wildcards in an international label.
xn--caf-dma.com
is café.com
xn--caf-dma*.com
is not allowedLw*.xn--caf-dma.com
is allowed