The Other Side of HTTPS Support

One of the main themes of IndieWebCamp UK 2014 was a heavy push for TLS support on our personal sites, mainly thanks to the eternal patience and knowledge of Tim Retout. A large proportion of the participants either got TLS working on their site for the first time or upgraded their support to remove vulnerabilities and support snazzy extra features like perfect forward secrecy.

One unexpected side effect of all this added security revealed itself when Al Power asked me about adding microformats2 to his newly TLSed up site. I immediately recommended and as useful tools for checking how well your site is marked up, only to find that they didn’t work due to a TLS verification error.

We consulted Tim, who looked at the results for Al’s site, and pointed out that it wasn’t sending the “intermediate certificate” which had been used to sign his site’s certificate,

The SSL Labs testing UI makes it quite clear if you have certificate chain issues by highlighting missing certs in orange as “requires download”.

StartSSL have a root certificate which is typically shipped with browsers and other clients (e.g. cURL) in their bundle of trusted certificates. However, StartSSL don’t directly sign their customers’ certs with the root, but instead with various “intermediate” certificates, all signed by the root and therefore verifiable. Sites shouldn’t send root certs, but if they don’t send intermediate certs (as shown above) most browsers will download and verify the intermediate certs by themselves.

Command line HTTP clients like cURL, and their interfaces in programming languages typically do not exhibit this helpful behaviour. Rather, they demand to be pre-loaded with all of the root AND intermediate certs you expect to be using, even if sites send intermediates (which they should, but I try to aim to reproduce browser behaviour when crawling as much as possible).

Wherever Guzzle (my PHP HTTP client) was getting it’s cert bundle from (either the system or the default bundle shipped with Guzzle), it was missing many of the StartSSL intermediate certs, rendering my tools useless for testing people’s newly-secured sites. Fortunately, Aaron Parecki had dealt with similar problems recently and provided the answer: download StartSSL’s complete bundle and add it to the existing bundle.

Much like embedded content attacks, this isn’t a security problem which just affects people like me who build tools to help others make their sites better — in the reactive, connected indieweb we’re building, where sites talking to each other is commonplace, it affects everyone, and, until we have better tools, will need to be debugged and fixed, over and over again, by everyone. It’s yet another demonstration that HTTPS support is not in any way “easy”.

How can we make this better? For a start, by making our tools better. Both and shrewdness now ship with built-in certificate bundles, which are used by default, allowing both myself and contributors to fix problems like this in one place and eliminate environment-specific issues. Hopefully this approach will be adopted by other tool-builders, so everyone can enjoy having a secure site without compromising it’s ability to communicate with others.