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
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:
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.
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:
Rescorla Informational [Page 4]
RFC 2818 HTTP Over TLS May 2000
3. Endpoint Identification3.1. Server Identity 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
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.