One month to the day late for Festivus I figured I'd share a little bit about how X.509 is disappointing, particularly in the arena of SSL certs used for web services.

Some time ago I wrote a monograph on why providing https:// service on a content distribution network (CDN) was a bit painful, to the point of being a non-starter based on (other external) constraints we had to work within. Some of this is a bit dated - in fact I make some observations about "XP will never have SNI" which will be a bit funny after April 2014 when XP will never get any feature or bug fix ever, its support infrastructure moldering in the grave even as some people do the operating system equivalent of the news articles one periodically reads about folks pulled over with a dead grandparent in the back seat and no idea that they'd passed away.

Anyway, on with the grievances.

A CDN appears to the end user as a shared hosting environment - multiple web sites on one server with one IP address; it's just a server that happens to be replicated in many places one of which is particularly close to the customer.

Unfortunately, SSL and TLS shared-address web hosting is hard. The reason it's difficult is an artifact of protocol layering. In both SSL and TLS, the crypto authentication happens at layer 4 during session set-up (SSL client-hello). X.509 certificates are typically issued for a single hostname (more on that later). It is only after the SSL or TLS session is open (and long after authentication of the certificate) that the HTTP request is sent which indicates what server one is expecting to speak to… way too late to allowed selection of a proper certificate from multiple on hand during the SSL negotiation phase.

Server Name Identification, aka SNI. In a shared environment a server must choose which certificate to use before actually setting up the SSL session. A clean (albeit redundant) way to address this constraint is to tell the server who you're expecting to talk to twice, once as an artifact of SSL session setup (before the crypto) and then subsequently as part of the HTTP GET. This is known as Server Name Indication (SNI). It was initially developed for TLS, with a backport later to work in a standard way with SSL. Because of time frame overlap (circa 2004) with adding TLS to some popular browsers, SNI generally works under TLS with browsers that support TLS. More at http://en.wikipedia.org/wiki/Server_Name_Indication – but note well that there is a substantial installed base out there on which it doesn't work, and will never work (e.g. Internet Explorer on Windows XP). No guarantees can be made about embedded browsers either. At this writing (2012q4) current Opera and Honeycomb/Ice Cream Sandwich Android support SNI but previous versions may not. A contemporaneous informal discussion with an SME at Akamai revealed that SNI support was neither a GA nor LA product for them, which speaks volumes about level of support "in the wild"

Wildcard Certificates Another approach is to issue a wildcard cert, but wildcards are not multi-level. For instance, a wildcard cert for *.cdn.example.com will work for foo.cdn.example.com and bar.cdn.example.com but not bar.foo.cdn.example.com. Wildcard certificates are mentioned in RFC 2459, and the semantics are clarified in RFC 2818 (which is nominally about HTTP over TLS, but some of the clarifications are actually general to all uses of X.509 certs to secure sessions.

Subject Alternative Name Certificates Yet another way to address the certificate problem is to issue a Subject Alternative Name (SAN) certificate, aka a UCC certificate. One can stack up a lot of SANs in a certificate (north of 100 in the spec) but it is difficult to get commercial CAs to issue certs with more than 5 SAN fields. Even if this were possible at a reasonable price, changing certs means a maintenance window and possible service disruption for existing services. The spec says that one may not have wildcards in SAN certs, but this has been observed in the wild; behavior is likely implementation-dependent.

Single IP Address per SSL Domain Name One more approach is to add addresses at the edge such that each https:// service has its own IP address on each CDN distribution appliance, causing a geometric increase (number of DAs * number of https services) in IP addresses required at the edge. This is a possible implementation strategy in an all-IPv6 environment, but if IPv4-only clients are to be supported per-service per-DA addresses are not a viable solution.

This is one of those problems that will solve itself over time, as the perception of a business need to support ancient (read: non-SNI-supporting) browsers fades.