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

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

    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.