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.
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?|
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 gives more detailed error on what actually happened. It includes the Error code ssl_error_bad_cert_domain.
Opera gives details about the certificate, but the information is not presented as clearly as Firefox or Chrome for that matter.
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:
3. Endpoint Identification
3.1. Server IdentityIn 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
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.