Wildcard certificate

From Wikipedia, the free encyclopedia
Jump to: navigation, search
An example of a wildcard certificate on https://plus.google.com (note the asterisk: *)
An example of an EV certificate acting as a wildcard certificate on https://www.ssl.com (note the Subject Alternative Name (SAN) field)

In computer networking, a wildcard certificate is a public key certificate which can be used with multiple subdomains 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 domain.[1]

Example[edit]

A single wildcard certificate for *.example.com, will secure all these domains:[2]

  • payment.example.com
  • contact.example.com
  • login-secure.example.com
  • www.example.com

Instead of getting separate certificates for sub domains, you can use a single certificate for all main domains and sub domains and save your money.[3]

Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops),[4] 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):[5]

  • 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

Brief information about wildcard ssl certificate.

Limitation[edit]

Only a single level of subdomain matching is supported.[6]

It is not possible to get a wildcard for an Extended Validation Certificate.[7] A workaround could be to add every virtual host name in the Subject Alternative Name (SAN) extension,[8][9][10] the major problem being that the certificate needs to be reissued whenever a new virtual server is added.[11]

Wildcards can be added as domains in multi-domain certificates or Unified Communications Certificates (UCC).[12] 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 https://www.wikipedia.org as well as the completely different website name https://meta.m.wikimedia.org.[13]

RFC 6125 argues against wildcard certificates on security grounds.[14]

References[edit]

  1. ^ Hendric, William (17 January 2008). "Wildcard SSL Certificate Explained". SSL Certificate Provider. Retrieved 17 February 2015. 
  2. ^ Hendric, William (17 June 2008). "Wildcard SSL Certificate Features". Comodo SSL. SSL Certificate Provider. Retrieved 17 February 2015. 
  3. ^ "Wildcard Certificate Explained in Simpler Terms". 23 May 2016. 
  4. ^ "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. 
  5. ^ "RFC 2595 - Using TLS with IMAP, POP3 and ACAP". Internet Engineering Task Force. June 1999. p. 3. Retrieved 2014-12-15. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com. 
  6. ^ Wildcard SSL certificate limitation on QuovadisGlobal.com
  7. ^ "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. 
  8. ^ x509v3_config-Subject Alternative Name
  9. ^ The subjectAltName field
  10. ^ The SAN option is available for EV SSL Certificates on Symantec.com
  11. ^ Need to be reissued whenever a new virtual server is added
  12. ^ Wildcard domains can be used within UCC on SSL.com
  13. ^ SSLTools Certificate Lookup of Wikipedia.org's wildcard ssl certificate
  14. ^ "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. March 2011. p. 31. 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: [...] 

Relevant RFCs[edit]