rm spamrefs |
GreenC bot (talk | contribs) Rescued 1 archive link; reformat 2 links. Wayback Medic 2.5 per WP:URLREQ#symantec.com |
||
(45 intermediate revisions by 30 users not shown) | |||
Line 1: | 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}} |
{{technical|date=July 2014}} |
||
[[File: |
[[File:Let’s Encrypt example certificate on Firefox 94 screenshot.png|thumb|300px|right|An example of a wildcard certificate on comifuro.net (note the [[asterisk]]: {{code|*}})]] |
||
[[File: |
[[File:Subject Alt Names on Firefox 90 screenshot.png|thumb|300px|right|An example of a [[Subject Alternative Name]] (SAN) field]] |
||
In computer networking, a '''wildcard certificate''' is a [[public key certificate]] which can be used with multiple [[subdomain|sub-domain]]s of a domain. The principal use is for securing web sites with [[HTTPS]], but there are also applications in many other fields. Compared with conventional certificates, a wildcard certificate can be cheaper and more convenient than a certificate for each sub-domain. Multi-domain wildcard certificates further simplify the complexity and reduce costs by securing multiple domain and their sub-domains. <ref>{{Cite web|url=https://sslretail.com/wildcard-ssl/|title=Wildcard SSL Certificate Explained|last=Hendric|first=William|date=17 January 2008|publisher=SSL Certificate Provider|accessdate=17 February 2015}}</ref> As of RFC 6125<ref>{{Cite web|url=https://tools.ietf.org/html/rfc6125#section-7.2|title=RFC 6125|date=1 March 2011|website=ietf.org|publisher=Internet Engineering Task Force|accessdate=9 May 2019}}</ref> wildcard certificates are deprecated. |
|||
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== |
==Example== |
||
Line 12: | Line 17: | ||
* {{code|www.example.com}} |
* {{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 |
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 2016}}</ref> |
||
Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops),<ref> |
Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops),<ref> |
||
{{cite web |
{{cite web |
||
| url= //tools.ietf.org/html/rfc2818#page-5 |
| url= http://tools.ietf.org/html/rfc2818#page-5 |
||
| title= <nowiki>RFC 2818</nowiki> - HTTP Over TLS |
| title= <nowiki>RFC 2818</nowiki> - HTTP Over TLS |
||
| publisher= [[Internet Engineering Task Force]] |
| publisher= [[Internet Engineering Task Force]] |
||
Line 28: | Line 33: | ||
The "naked" domain is valid when added separately as a [[Subject Alternative Name]] ({{code|SubjectAltName}}):<ref> |
The "naked" domain is valid when added separately as a [[Subject Alternative Name]] ({{code|SubjectAltName}}):<ref> |
||
{{cite |
{{cite IETF |
||
| url= https://tools.ietf.org/html/rfc2595#page-3 |
| url= https://tools.ietf.org/html/rfc2595#page-3 |
||
| title= <nowiki>RFC 2595</nowiki> - Using TLS with IMAP, POP3 and ACAP |
| title= <nowiki>RFC 2595</nowiki> - Using TLS with IMAP, POP3 and ACAP |
||
Line 35: | Line 40: | ||
| quote= For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com. |
| quote= For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com. |
||
| page= 3 |
| page= 3 |
||
| |
| doi= 10.17487/RFC2595 |
||
| rfc=2595 |
|||
⚫ | |||
| accessdate= 2014-12-15 |
|||
| last1= Newman |
|||
| first1= C. |
|||
| doi-access= free |
|||
⚫ | |||
</ref> |
</ref> |
||
* {{code|example.com}} |
* {{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}}. |
Note possible exceptions by CAs, for example wildcard-plus cert by DigiCert contains an automatic "Plus" property for the naked domain {{code|example.com}}. |
||
== Type of wildcard certificates == |
|||
Wildcard certificates are categorized on the basis of validation level, number of domain and number of servers it can be used with. Likewise they are named as domain validation wildcard certificate, organisation validation wildcard certificate and extended validation wildcard certificate when we categorize them according to validation level. The name Multi-domain wildcard certificates and Multi-server wildcard certificates are given according to number of domain and number of server. All types of wildcard certificates signed by popular CAs are categorized and listed internet<ref>{{Cite news|url=https://www.clickssl.net/cheapest-wildcard-ssl-certificate-for-sub-domains|title=Wildcard SSL Certificates (Full List) for sub-Domains|access-date=2019-10-01|language=en}}</ref>. Therefore there are types of wildcard which can secure multiple domains, multiple servers and provide different levels of validation. |
|||
==Limitations== |
==Limitations== |
||
Only a single level of [[subdomain]] matching is supported in accordance with {{IETF RFC|2818}}.<ref>[https://support.quovadisglobal.com/KB/a60/will-ssl-work-with-multilevel-wildcards.aspx?KBSearchID=10223 Wildcard SSL certificate limitation on QuovadisGlobal.com]</ref> |
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> |
It is not possible to get a wildcard for an [[Extended Validation Certificate]].<ref> |
||
Line 57: | Line 64: | ||
| accessdate= 2014-12-15 |
| 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://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.) |
</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). |
Wildcards can be added as domains in multi-domain certificates or [[Unified Communications Certificate]]s (UCC). In addition, wildcards themselves can have {{code|subjectAltName}} extensions, including other wildcards. For example, the wildcard certificate {{code|*.wikipedia.org}} has {{code|*.m.wikimedia.org}} as a Subject Alternative Name. Thus it secures {{code|www.wikipedia.org}} as well as the completely different website name {{code|meta.m.wikimedia.org}}.<ref>[http://www.ssltools.com/certificate_lookup/www.wikipedia.org SSLTools Certificate Lookup of Wikipedia.org's wildcard ssl certificate]</ref> |
||
{{IETF RFC|6125}} argues against wildcard certificates on security grounds, in particular "partial wildcards".<ref> |
|||
{{cite |
{{cite IETF |
||
| url= https://tools.ietf.org/html/rfc6125#section-7.2 |
| url= https://tools.ietf.org/html/rfc6125#section-7.2 |
||
| date= March 2011 |
| date= March 2011 |
||
Line 69: | Line 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: [...] |
| 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 |
| page= 31 |
||
| |
| doi= 10.17487/RFC6125 |
||
| rfc=6125 |
|||
⚫ | |||
| accessdate= 2014-12-10 |
|||
| last1= Saint-Andre |
|||
| first1= P. |
|||
| last2= Hodges |
|||
| first2= J. |
|||
| doi-access= free}} |
|||
</ref> |
</ref> |
||
==Examples== |
==Examples== |
||
{{ |
{{More citations needed section|date=January 2020}} |
||
The wildcard applies only to one level of the domain name. |
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}} |
||
:''{{code|label.label.label.TLD}}'' |
|||
:{{code|*.domain.com}} is OK. It will match {{code|www.domain.com}} but not {{code|domain.com}} and not {{code|zzz.www.domain.com}} |
|||
The wildcard may appear anywhere inside a label |
The wildcard may appear anywhere inside a label as a "partial wildcard" according to early specifications<ref>{{Cite IETF |url=https://tools.ietf.org/html/rfc2818.html |title=RFC 2818 - HTTP Over TLS |last1=Rescorla |first1=E. |date=May 2000 |website=tools.ietf.org |doi=10.17487/RFC2818 |rfc=2818 |language=en |accessdate=2019-04-20}}</ref> |
||
:{{code|f*.domain.com}} is OK. It will match {{code|frog.domain.com}} but not {{code|frog.super.domain.com}} |
:{{code|f*.domain.com}} is OK. It will match {{code|frog.domain.com}} but not {{code|frog.super.domain.com}} |
||
Line 88: | Line 98: | ||
:{{code|b*z.example.net}} is OK and matches {{code|buzz.example.net}} |
:{{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, |
|||
(However, note that all major browsers deliberately do '''not''' support "partial-wildcard" certificates; 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 and Golang. Thus, use of "partial-wildcard" certs is not recommended.) |
|||
Do not allow a label that consists entirely of just a wildcard unless it is the left-most label |
Do not allow a label that consists entirely of just a wildcard unless it is the left-most label |
||
Line 113: | Line 123: | ||
==Relevant RFCs== |
==Relevant RFCs== |
||
* {{cite |
* {{cite IETF |
||
| url= https://tools.ietf.org/html/rfc2595#page-3 |
| url= https://tools.ietf.org/html/rfc2595#page-3 |
||
| title= <nowiki>RFC 2595</nowiki> - Using TLS with IMAP, POP3 and ACAP |
| title= <nowiki>RFC 2595</nowiki> - Using TLS with IMAP, POP3 and ACAP |
||
Line 119: | Line 129: | ||
| date= June 1999 |
| date= June 1999 |
||
| page= 3 |
| page= 3 |
||
| doi= 10.17487/RFC2595 |
|||
}} |
|||
| rfc=2595 |
|||
⚫ | |||
| last1= Newman |
|||
⚫ | |||
| first1= C. |
|||
| doi-access= free}} |
|||
⚫ | |||
⚫ | |||
| title= <nowiki>RFC 2818</nowiki> - HTTP Over TLS |
| title= <nowiki>RFC 2818</nowiki> - HTTP Over TLS |
||
| publisher= [[Internet Engineering Task Force]] |
| publisher= [[Internet Engineering Task Force]] |
||
| rfc=2818 |
|||
| date= May 2000 |
| date= May 2000 |
||
| page= 5 |
| page= 5 |
||
}} |
}} |
||
* {{cite |
* {{cite IETF |
||
| url= https://tools.ietf.org/html/rfc6125 |
| url= https://tools.ietf.org/html/rfc6125 |
||
| date= March 2011 |
| date= March 2011 |
||
| publisher= [[Internet Engineering Task Force]] |
| 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) |
| 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.