Working with Wild Card Certificates

Yesterday one of my colleagues came up to me with a simple problem regarding wild card certificates. I gave him the solution immediately, but it had to take a lot of convincing to do. This shows that there is a lot of confusion around how wild card certificates work.

For first time readers, wildcard certificates are server certificates which contain a wildcard (*) as part of the hostname. They offer a great advantage as one hostname containing a wildcard can match multiple hostnames provided they satisfy the condition.

Typically the Issued To section of the certificate will contain a hostname with a wildcard. There are real world examples like Facebook and Yahoo:

 

SAN certificates can also contain wildcard hostnames. They are a parent set, so a SAN certificate is also a wildcard certificate if it contains a hostname with a wildcard as shown in the above image.

****CONFUSION****

As only one cert can be bound to a specific IP+Port, regular certificates were not very helpful. Wildcard certificates provided solution to this problem. Thought not a full-fledged solution to the problem. It provided some relief. The admins could have a certificate issued to *.contosso.com and then have hostnames configured accordingly.

However this gave rise to some confusion. Even though this is clearly documented in the RFC’s. I have still seen many getting confused on this.

Consider a certificate issued to *. contosso.com. If this has to be configured any web server, then a question arises. What all valid hostnames can be configured with the above certificate?

Lets take a look at the below table

	SSL Certificate issued to	Host Name configured on the web server	Is valid?
1	*.contosso.com	marketing.contosso.com	✔
2	*.contosso.com	hr.contosso.com	✔
3	*.contosso.com	apps.developers.contosso.com	❌
4	*.contosso.com	123.test.beta.contosso.com	❌

Looking at the above table you should have understood that the wildcard character allows only one single domain as an addition to the hostname.

If you were to configure a host name as per 3 & 4 on IIS for a cert issued to *.contosso.com, then the client browser would throw an error indicating address mismatch. Different browsers throw different errors.

Below is a snapshot of errors thrown by different browsers:

• Internet Explorer:

IE displays a user friendly error. It doesn’t contain any detailed errors, which is not required but nevertheless they cant be completely ignored. A little more detail in this regards would have been better.

• Google Chrome:

Chrome does a better job than IE here, it provides more details informing the user what the certificate is issued to and the hostname they are browsing to.

• Mozilla Firefox:

Mozilla Firefox gives more detailed error on what actually happened. It includes the Error code ssl_error_bad_cert_domain.

• Opera

Opera gives details about the certificate, but the information is not presented as clearly as Firefox or Chrome for that matter.

****REASON****

Now why is that the last 2 (3 & 4) in the table were invalid? The reason is that the RFC2818 defines it to be this way. The RFC allows matching of only a single domain for a given wild card character.

Below is a snippet of RFC 2818:

Rescorla Informational [Page 4] RFC 2818 HTTP Over TLS May 2000 3. Endpoint Identification In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack. If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Matching is performed using the matching rules specified by [RFC2459]. 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. In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI. If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself obtained without using HTTP/TLS, a man in the middle could have replaced the URI. In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it meets their expectations.

If you observe the above snippet carefully you would notice that certificates can be issued to IPAddresses as well. But then the IPAddress should match the IPAddress in the certificate exactly. failing which could lead to a address mismatch error.

Hope this clears some confusion. Let me know if this post helped you.

Comments

• Anonymous
  June 12, 2013
  Great Blog Post!!! Knowing this will help me a lot with SharePoint Apps for 2013.

• Anonymous
  September 25, 2013
  It is a very helpful information,It makes the process less complicated and provides prompt processing to the owner without much ado. With the help of this facility, a website administrator can easily administer several domains from a single certificate and the network safety will also be guaranteed. Thanks for sharing............. www.primasecure.net/ssl-certificates

• Anonymous
  November 21, 2013
  So this is hindering us right now, as we have used wildcards in the past that worked great we just started to try to use wildcard certs with subdomain of a subdomain. uat.stack1.mydomain.com (*.mydomain.com cert) Is it possible to obtain     ..mydomain.com   ??? thanks for info