About Wildcard Certificates

You'll probably know that certificates containing the wildcard character "*" in the CN of a server are called wildcard certificates.

On the other hand there is RFC 2595 "Using TLS with IMAP, POP3 and ACAP" which states:

RFC 2459 explicitly does not address wildcards in host/domain name matching.

So it seems that there are different specifications for different protocols...

ToDo: Have a closer look at RFC 3280 and RFC 5280

IIS bug

The encoding of the certificate request created by IIS that contains a wildcard will result in the following error:

The following hostnames were rejected because the system couldn't link them to your account, if they are valid please verify the domains against your account.

(This possibly concerns IIS 5 or 6.)


You can use OpenSSL to create a certificate request for a common name that contains a wildcard and import this certificate for use in IIS.

IIS 8 on Windows server 2012 R2

You can create in that version:

  1. certificate - without specification, saving an output into a request file, it's not possible to enter SANs,
  2. domain certificate - a request file is not created, the certificate is sent to a local CA accessible in a local network; it's not possible to use SANs here, too.

You can use the first function to get CAcert server certificates. Use the function "Create a certificate request..." to get a request with a CN containing the wildcard character "*"; no problems to save the request into a file. An error occurs as far as in the function "Complete a certificate request...", where you need to enter the file containing the certificate response from CA. The program reports that the certificate could not be removed (!), but after the display refresh, the new wildcard certificate displays, its subject indeed contains the wildcard character "*" and all seems to be OK: the certificate can be used in IIS (web --> links --> https) and IIS is operational with it.

To have the possibility to enter SANs, e.g. "*.contoso.com" and "contoso.com", it is better to create a certificate request with the MMC module Certificates.

Interoperability study

Since Mozilla does not match the names according to RFC 2818 there may be other products that do not.

Please add your own browser/tool/library/application here.


The OpenSSL library does not contain code to check the server's name in the certificate, so it's up to the application wether to accept wildcards or not.

Internet Explorer

Internet Explorer 6.0.2800.1106: * does not match subdomains

Mozilla & Co

SeaMonkey 1.0.5 on Linux&Windows: * matches subdomains.



Fixed in SVN in November 2005: http://bugs.kde.org/show_bug.cgi?id=106476





WildcardCertificates (last edited 2016-05-04 20:26:59 by AlesKastner)