Wildcard certificate
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.
Example
A single wildcard certificate for https://*.example.com will secure all these subdomains on the https://*.example.com domain:
payment.example.comcontact.example.comlogin-secure.example.comwww.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.
Limitations
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]
Examples
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.comis OK. It will matchfrog.domain.combut notfrog.super.domain.com
baz*.example.netis OK and matchesbaz1.example.net*baz.example.netis OK and matchesfoobaz.example.netb*z.example.netis OK and matchesbuzz.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.comis 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.comiscafé.comxn--caf-dma*.comis not allowedLw*.xn--caf-dma.comis allowed
References
- ↑ "Wildcard Certificate Explained in Simpler Terms". 23 May 2016. http://searchsecurity.techtarget.com/definition/wildcard-certificate.
- ↑ "RFC 2818 - HTTP Over TLS". Internet Engineering Task Force. May 2000. p. 5. //tools.ietf.org/html/rfc2818#page-5. Retrieved 2014-12-15. "[...] *.a.com matches foo.a.com but not bar.foo.a.com."
- ↑ Newman, C. (June 1999). RFC 2595 - Using TLS with IMAP, POP3 and ACAP. Internet Engineering Task Force. p. 3. doi:10.17487/RFC2595. https://tools.ietf.org/html/rfc2595#page-3. Retrieved 2014-12-15. "For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.".
- ↑ Wildcard SSL certificate limitation on QuovadisGlobal.com
- ↑ "Guidelines For The Issuance And Management Of Extended Validation Certificates, Version 1.5.2". CA/Browser Forum. 2014-10-16. p. 10. https://cabforum.org/wp-content/uploads/EV-V1_5_2Libre.pdf#page=16. Retrieved 2014-12-15. "Wildcard certificates are not allowed for EV Certificates."
- ↑ x509v3_config Subject Alternative Name
- ↑ The SAN option is available for EV SSL Certificates on Symantec.com
- ↑ SSLTools Certificate Lookup of Wikipedia.org's wildcard ssl certificate
- ↑ Saint-Andre, P.; Hodges, J. (March 2011). RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). Internet Engineering Task Force. p. 31. doi:10.17487/RFC6125. https://tools.ietf.org/html/rfc6125#section-7.2. Retrieved 2014-12-10. "This document states that the wildcard character '*' SHOULD NOT be included in presented identifiers but MAY be checked by application clients (mainly for the sake of backward compatibility with deployed infrastructure). [...] Several security considerations justify tightening the rules: [...]".
- ↑ Rescorla, E. (May 2000) (in en). RFC 2818 - HTTP Over TLS. doi:10.17487/RFC2818. https://tools.ietf.org/html/rfc2818.html. Retrieved 2019-04-20.
- ↑ Saint-Andre, P.; Hodges, J. (March 2011) (in en). RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). doi:10.17487/RFC6125. https://tools.ietf.org/html/rfc6125.html. Retrieved 2019-04-20.
- ↑ "Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling". The Chromium Projects, Google Inc.. 3 December 2014. https://codereview.chromium.org/762013002. Retrieved 21 October 2020.
- ↑ "Limit wildcard DNS ID support to names of the form *.example.com (not foo*.example.com)". The Mozilla Foundation. 10 December 2014. https://bugzilla.mozilla.org/show_bug.cgi?id=1107791. Retrieved 21 October 2020.
- ↑ "Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling". The Python Software Foundation. 26 November 2017. https://bugs.python.org/issue23033. Retrieved 21 October 2020.
Relevant RFCs
- Newman, C. (June 1999). RFC 2595 - Using TLS with IMAP, POP3 and ACAP. Internet Engineering Task Force. p. 3. doi:10.17487/RFC2595. https://tools.ietf.org/html/rfc2595#page-3.
- "RFC 2818 - HTTP Over TLS". Internet Engineering Task Force. May 2000. p. 5. //tools.ietf.org/html/rfc2818#page-5.
- Saint-Andre, P.; Hodges, J. (March 2011). RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). Internet Engineering Task Force. doi:10.17487/RFC6125. https://tools.ietf.org/html/rfc6125.
 |  |
