## 20160504 AK
----
 [[WildcardCertificates/CZ|česky]] | '''english'''
----
= About Wildcard Certificates =

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

## [[http://rfc.net/rfc2818.html|RFC 2818]] "HTTP Over TLS" states the following:
 [[http://www.ietf.org/rfc/rfc2818.txt|RFC 2818]] "HTTP Over TLS" states the following:


   Matching is performed using the matching rules specified by [[http://www.ietf.org/rfc/rfc2459.txt|RFC 2459]].  If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

## On the other hand there is [[http://rfc.net/rfc2595.html|RFC 2595]] "Using TLS with IMAP, POP3 and ACAP" which ## states:
On the other hand there is [[http://www.ietf.org/rfc/rfc2595.txt|RFC 2595]] "Using TLS with IMAP, POP3 and ACAP" which states:

   A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.

##RFC 2459 explicitly does not address wildcards in host/domain name matching.
[[http://www.ietf.org/rfc/rfc2459.txt|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 [[http://www.ietf.org/rfc/rfc3280.txt|RFC 3280]] and [[http://www.ietf.org/rfc/rfc5280.txt|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.)

=== Solution ===
You [[How to create certificate request#OpenSSL|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,
 1. 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.

=== OpenSSL ===

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.

===== Firefox =====
 * 1.5.0.7/Windows: matches subdomains, the hostname that was entered (NOT the certificate's CN, which I'd consider a bug) is displayed in the statusline. This is filed as a bug in [[https://bugzilla.mozilla.org/show_bug.cgi?id=159483]] so it may be fixed in a new release. But since the bug was opened in 2002 we may probably have to live with it for some more time... /!\ RESOLVED & CORRECTED /!\
 * 3.0.0b5/Ubuntu: matches subdomains.

=== Konqueror ===

 * Konqueror 3.5.1: does not match subdomains.
 * Konqueror 3.5.4-0.5.fc5: matches subdomains (use the lock on the iconbar to inspect the KDE SSL information).
 * Konqueror 3.5.9: matches subdomains.

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

=== Opera ===

 * Opera 9.00: does seem to match subdomains.
 * Opera 9.27: matches subdomains

=== Safari ===
 * 3.1 (5525.13): matches subdomains

=== Lynx ===
 * Lynx 2.6.8rel.1 on FreeBSD: Does not match wildcards at all
 * Lynx 2.8.6rel.4 on Linux: matches subdomains
  * This was on Ubuntu 7.10 (GnuTLS 1.6.3, SSL-MM 1.4.1)

=== Subversion ===
 * 1.4.4 (r25188): matches subdomains

----
 . CategorySoftware