How to Deliver Both SHA-1 and SHA-2 Certificates With Your OS X Server

Photo of Greg
Photo by Marcin Wichary - http://flic.kr/p/5k6mrM

In this second article of a series on the new HTTPS landscape, I’ll describe one way of supporting both SHA-1 and SHA-2 with OS X Server.

As I described in the previous article in this seris, Google threw the world a curveball when they announced, without warning, a significant speeding up of the sunsetting process for SHA-1. (See “Adapting Your OS X Server Strategy for SHA-1, SHA-2, and HTTPS Everywhere”.) That announcement threatens to leave behind literally millions of machines, and on the face of it, it appears to force webmasters to make a choice: either support newer certificate technology while dropping support for older machines, or support older machines by dropping HTTPS altogether.

Fortunately, though, it’s not quite as stark as all that, since it is possible to provide newer certificates to browsers which can understand them, and older certificates to browsers which cannot. While there are several ways to support both SHA-1 and SHA-2 for the same domain, most of these are sufficiently impractical that they’re unlikely to find much favour with those of us running OS X-based servers or even with most large hosting organisations in charge of armies of servers. It’s also possible to support SHA-1 and SHA-2 for the same site via a content delivery network (CDN), although for many small businesses this introduces enough other potential headaches and expenses to render this option far from ideal.

However, there is at least one easy way to support both SHA-1 and SHA-2 on a server running OS X, and while it isn’t perfect, I think it offers the best return for a given amount of effort, by a large margin.

The approach leverages the fact that there’s a large overlap between the set of browsers out there which cannot handle SHA-2 and the set of browsers out there which don’t speak server name indication, or SNI. It’s SNI which enables multiple sites using distinct domain-specific certificates to inhabit the same IP address. While you’ll read on many — perhaps most — certificate authorities’ websites that it’s impossible to run two different HTTPS-capable sites from the same IP address without resorting to a multiple domain certificate or a wildcard certificate, that’s just hogwash. In fact, virtually all browsers since IE 7 speak SNI, an extension to TLS which enables the browser to communicate to the server during the handshake which host name it wants to talk to. Specifying the host by name while the secure connection is being set up means that the server can return a name-specific certificate for any of an arbitrarily large set of domains all hosted at the same IP address. Without SNI, the server has no idea which domain’s certificate is required, so it returns the server’s own.

That can still work smoothly for a non-SNI browser provided the server is equipped with a certificate covering multiple domains — usually called a Subject Alternative Name (SAN) or Unified Communications (UC) certificate — or a wildcard certificate which includes the host name which the browser eventually wants to talk to. If the server’s certificate does not include the name the browser wants to communicate with, however, the result will be a host name mismatch error.

Practically speaking, the main limitation of SNI is that Windows XP does not support it, regardless of browser version. Since, as I mentioned in the previous article on Google’s SHA-1 announcement, SHA-2 is unsupported by XP prior to SP3, this means there’s significant overlap between SHA-2-ignorant browsers and SNI-incapable operating systems. Looking at it from another angle, when we consider the set of SHA-2-capable browsers which are actually going to complain visually about a SHA-1 certificate and which also live on SNI-incapable operating systems, we come down to shiny new versions of Chrome running on decrepit Windows XP, which is a relatively small chunk of the web population.

What does this relationship between SHA-2 hipness and SNI fluency mean? It means that we can cover most of our bases by installing a SHA-1 SAN certificate as the main server certificate and separate SHA-2 certificates for individual domains on the server: browsers which don’t speak SNI get the SHA-1 SAN, while browsers which do speak SNI get the individual SHA-2 certificate. This isn’t perfect, since the folks running a new version of Chrome on an old version of Windows will get a warning caused by the certificate’s hash algorithm, but it works for a much larger chunk of the population than settling on either SHA-1 or SHA-2 alone. It also introduces a significant performance hit for older browsers which receive what might be a relatively large SAN certificate, but that’s better than no connection at all. (In the case of certificates and connection speed, size matters a great deal, and smaller is better.)

For the sake of a concrete example, suppose you’re hosting three additional domains on your OS X Server, like so:

  • maindomain.com
  • domain1.com
  • domain2.com
  • domain3.com

Then the server’s main certificate would rely on the older SHA-1 hash and would include something like the following:

  • maindomain.com
  • www.maindomain.com
  • domain1.com
  • www.domain1.com
  • domain2.com
  • www.domain2.com
  • domain3.com
  • www.domain3.com

And the individual domains would each carry their own certificates, using the stronger SHA-2. They might look like this:

  • domain1.com
  • www.domain1.com

And this:

  • domain2.com
  • www.domain2.com

And this:

  • domain3.com
  • www.domain3.com

Any browser which didn’t speak SNI would receive the large main certificate shown first above, regardless of which domain they actually wanted to connect to, while modern browsers would receive the smaller domain-specific alternatives.

In the next post, I’ll run through exactly how to implement this kind of setup using OS X’s Server, Keychain Access, and a small smattering of the command line.

All material on this site is carefully reviewed, but its accuracy cannot be guaranteed, and some suggestions offered here might just be silly ideas. For best results, please do your own checking and verifying. This specific article was last reviewed or updated by Greg on .

This site is provided for informational and entertainment purposes only. It is not intended to provide advice of any kind.