 | It has been suggested that this article be merged into Public key certificate . (Discuss) Proposed since November 2023. |
 | This article may be too technical for most readers to understand.(July 2014) |
*)
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.comcontact.example.comlogin-secure.example.comwww.example.comInstead 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.comThe "naked" domain is valid when added separately as a Subject Alternative Name (SubjectAltName): [3]
example.comNote 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]
 | This section needs additional citations for verification .(January 2020) |
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.combaz*.example.net is OK and matches baz1.example.net*baz.example.net is OK and matches foobaz.example.netb*z.example.net is OK and matches buzz.example.netHowever, 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.comA cert with * plus a top-level domain is not allowed.
*.comToo 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é.comxn--caf-dma*.com is not allowedLw*.xn--caf-dma.com is allowedThe Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.
Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.
In computer network engineering, an Internet Standard is a normative specification of a technology or methodology applicable to the Internet. Internet Standards are created and published by the Internet Engineering Task Force (IETF). They allow interoperation of hardware and software from different sources which allows internets to function. As the Internet became global, Internet Standards became the lingua franca of worldwide communications.
The Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.
In the Internet, a domain name is a string that identifies a realm of administrative autonomy, authority or control. Domain names are often used to identify services provided through the Internet, such as websites, email services and more. As of 2017, 330.6 million domain names had been registered. Domain names are used in various networking contexts and for application-specific naming and addressing purposes. In general, a domain name identifies a network domain or an Internet Protocol (IP) resource, such as a personal computer used to access the Internet, or a server computer.
X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). ITU-T was formerly known as the Consultative Committee for International Telephony and Telegraphy (CCITT). X.500 was first approved in 1988. The directory services were developed to support requirements of X.400 electronic mail exchange and name lookup. The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) were partners in developing the standards, incorporating them into the Open Systems Interconnection suite of protocols. ISO/IEC 9594 is the corresponding ISO/IEC identification.
Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.
In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.
In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.
In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.
A wildcard DNS record is a record in a DNS zone that will match requests for non-existent domain names. A wildcard DNS record is specified by using a * as the leftmost label (part) of a domain name, e.g. *.example.com. The exact rules for when a wildcard will match are specified in RFC 1034, but the rules are neither intuitive nor clearly specified. This has resulted in incompatible implementations and unexpected results when they are used.
Virtual hosting is a method for hosting multiple domain names on a single server. This allows one server to share its resources, such as memory and processor cycles, without requiring all services provided to use the same host name. The term virtual hosting is usually used in reference to web servers but the principles do carry over to other Internet services.
The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.
Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546"Transport Layer Security (TLS) Extensions".
HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. HSTS is an IETF standards track protocol and is specified in RFC 6797.
A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its now-deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.
DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).
DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.
The Automatic Certificate Management Environment (ACME) protocol is a communications protocol for automating interactions between certificate authorities and their users' servers, allowing the automated deployment of public key infrastructure at very low cost. It was designed by the Internet Security Research Group (ISRG) for their Let's Encrypt service.
[...] *.a.com matches foo.a.com but not bar.foo.a.com.
For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.
{{cite journal}}: Cite journal requires |journal= (help)Wildcard certificates are not allowed for EV Certificates.
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: [...]
{{cite journal}}: Cite journal requires |journal= (help){{cite journal}}: Cite journal requires |journal= (help){{cite journal}}: Cite journal requires |journal= (help)