→Examples: More citations needed |
GreenC bot (talk | contribs) Rescued 1 archive link; reformat 2 links. Wayback Medic 2.5 per WP:URLREQ#symantec.com |
||
(37 intermediate revisions by 26 users not shown) | |||
Line 1:
{{merge to|Public key certificate|discuss=Talk:Public key certificate#Merge proposal of Wildcard Certificate|date=November 2023}}
{{Short description|Public key certificate which can be used with multiple subdomain of a domain}}
{{technical|date=July 2014}}
[[File:
[[File:
A [[Public key certificate]] which uses an [[asterisk]] {{code|*}} (the <em>wildcard</em>) in its [[domain name]] fragment is called a Wildcard certificate.
Through the use of {{code|*}}, a single certificate may be used for multiple [[subdomain|sub-domain]]s.
It is commonly used for [[transport layer security]] in [[computer networking]].
==Example==
Line 12 ⟶ 17:
* {{code|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.<ref>{{cite web|title=Wildcard Certificate Explained in Simpler Terms|url=http://searchsecurity.techtarget.com/definition/wildcard-certificate|date = 23 May
Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops),<ref>
{{cite web
| url= http://tools.ietf.org/html/rfc2818#page-5
| title= <nowiki>RFC 2818</nowiki> - HTTP Over TLS
| publisher= [[Internet Engineering Task Force]]
Line 28 ⟶ 33:
The "naked" domain is valid when added separately as a [[Subject Alternative Name]] ({{code|SubjectAltName}}):<ref>
{{cite
| url= https://tools.ietf.org/html/rfc2595#page-3
| title= <nowiki>RFC 2595</nowiki> - Using TLS with IMAP, POP3 and ACAP
Line 35 ⟶ 40:
| quote= For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.
| page= 3
|
| rfc=2595
}}▼
| accessdate= 2014-12-15
| last1= Newman
| first1= C.
| doi-access= free
▲ }}
</ref>
* {{code|example.com}}
Note possible exceptions by CAs, for example wildcard-plus cert by DigiCert contains an automatic "Plus" property for the naked domain {{code|example.com}}.
==Limitations==
Only a single level of [[subdomain]] matching is supported in accordance with {{IETF RFC|2818}}.<ref name=":0">[https://support.quovadisglobal.com/KB/a60/will-ssl-work-with-multilevel-wildcards.aspx?KBSearchID=10223 Wildcard SSL certificate limitation on QuovadisGlobal.com]</ref>
It is not possible to get a wildcard for an [[Extended Validation Certificate]].<ref>
Line 57 ⟶ 64:
| accessdate= 2014-12-15
}}
</ref> A workaround could be to add every virtual host name in the [[Subject Alternative Name]] (SAN) extension,<ref>[https://www.openssl.org/docs/apps/x509v3_config.html#Subject_Alternative_Name_ x509v3_config Subject Alternative Name]</ref><ref>[https://web.archive.org/web/20120613211438/http://www.symantec.com/theme.jsp?themeid=san-ssl-certificates The SAN option is available for EV SSL Certificates on Symantec.com]</ref> 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|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 Certificate]]s (UCC).
{{cite
| url= https://tools.ietf.org/html/rfc6125#section-7.2
| date= March 2011
Line 69 ⟶ 76:
| quote= 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: [...]
| page= 31
|
| rfc=6125
}}▼
| accessdate= 2014-12-10
| last1= Saint-Andre
| first1= P.
| last2= Hodges
| first2= J.
| doi-access= free}}
</ref>
==Examples==
{{More citations needed section|date=January 2020}}
The wildcard applies only to one level of the domain name. {{code|*.example.com}} matches {{code|sub1.example.com}} but not {{code|example.com}} and not {{code|sub2.sub1.domain.com}}
The wildcard may appear anywhere inside a label
:{{code|f*.domain.com}} is OK. It will match {{code|frog.domain.com}} but not {{code|frog.super.domain.com}}
Line 88 ⟶ 98:
:{{code|b*z.example.net}} is OK and matches {{code|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.<ref>{{Cite IETF |url=https://tools.ietf.org/html/rfc6125.html |title=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) |last1 = Saint-Andre |first1 = P. |last2 = Hodges|first2 = J.|date=March 2011 |website=tools.ietf.org |doi=10.17487/RFC6125 |rfc=6125 |language=en |access-date=2019-04-20|doi-access=free }}</ref> All major browsers have deliberately '''removed''' support for partial-wildcard certificates;<ref>{{cite web |url=https://codereview.chromium.org/762013002 |title=Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling |publisher=The Chromium Projects, Google Inc.|date=3 December 2014 |accessdate=21 October 2020}}</ref><ref>{{cite web |url=https://bugzilla.mozilla.org/show_bug.cgi?id=1107791 |title=Limit wildcard DNS ID support to names of the form *.example.com (not foo*.example.com) |publisher=The Mozilla Foundation |date=10 December 2014 |accessdate=21 October 2020}}</ref> 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<ref>{{cite web |url=https://bugs.python.org/issue23033 |title=Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling |publisher=The Python Software Foundation |date=26 November 2017 |accessdate=21 October 2020}}</ref> and Go. Thus,
Do not allow a label that consists entirely of just a wildcard unless it is the left-most label
Line 113 ⟶ 123:
==Relevant RFCs==
* {{cite
| url= https://tools.ietf.org/html/rfc2595#page-3
| title= <nowiki>RFC 2595</nowiki> - Using TLS with IMAP, POP3 and ACAP
Line 119 ⟶ 129:
| date= June 1999
| page= 3
| doi= 10.17487/RFC2595
| rfc=2595
* {{cite web▼
| last1= Newman
| url= //tools.ietf.org/html/rfc2818#page-5▼
| first1= C.
| doi-access= free}}
▲ | url= http://tools.ietf.org/html/rfc2818#page-5
| title= <nowiki>RFC 2818</nowiki> - HTTP Over TLS
| publisher= [[Internet Engineering Task Force]]
| rfc=2818
| date= May 2000
| page= 5
}}
* {{cite
| url= https://tools.ietf.org/html/rfc6125
| date= March 2011
| publisher= [[Internet Engineering Task Force]]
| title= 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
| rfc=6125
| last1= Saint-Andre
| first1= P.
| last2= Hodges
| first2= J.
| doi-access= free
|
Revision as of 22:45, 29 April 2024
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.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
.
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.com
is OK. It will matchfrog.domain.com
but notfrog.super.domain.com
baz*.example.net
is OK and matchesbaz1.example.net
*baz.example.net
is OK and matchesfoobaz.example.net
b*z.example.net
is 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.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
iscafé.com
xn--caf-dma*.com
is not allowedLw*.xn--caf-dma.com
is allowed
References
- ^ "Wildcard Certificate Explained in Simpler Terms". 23 May 2016.
- ^
"RFC 2818 - HTTP Over TLS". Internet Engineering Task Force. May 2000. p. 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. RFC 2595. 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" (PDF). CA/Browser Forum. 2014-10-16. p. 10. 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. RFC 6125. 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). "RFC 2818 - HTTP Over TLS". tools.ietf.org. doi:10.17487/RFC2818. RFC 2818. Retrieved 2019-04-20.
- ^ 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)". tools.ietf.org. doi:10.17487/RFC6125. RFC 6125. 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. 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. 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. 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. RFC 2595.
- RFC 2818 - HTTP Over TLS. Internet Engineering Task Force. May 2000. p. 5. doi:10.17487/RFC2818. RFC 2818.
- 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. RFC 6125.