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:

image image

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. W hat 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:
image 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:

image

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:

image

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

  • Opera

image

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






  3.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





   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.
        

</td>
</tr>
</tbody>
</table>




  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.