ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

Not the most user-friendly blog post title. But debugging HTTP2 is not user-friendly.

Development slammed  to a halt a couple days ago when I fired up my development environment in Chrome and was denied access to https://localhost. Not being able to reach your own machine’s web server: that is bad. Worse yet, this very blog shut down with the same denial. More interestingly, the common browser error had a unique signature: ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY. In short, nginx (the dipl.io web proxy) was using weak algorithms when communicating its encryption data. HTTP2 requires encryption to function properly, so no encryption = no website.

Bull, I declared. I haven’t touched my configuration for months. I couldn’t have broken it. I have two laptops I use for developing dipl.io—it’s important to develop in stereo—and when the second one succumbed to the same fate a couple days later, I knew something was up beyond my nginx configuration. And indeed, that something was Chrome.

Remember, SSL is a two-way street. nginx dishes it out, but browsers have to consume what nginx dishes out, and if they’re in disagreement, there is trouble. A week ago, Chrome 48 and nginx were in perfect harmony with this cipher suite configuration:

With the quiet upgrade to Chrome 49, that relationship snapped. One of the above suites probably ended up on the cipher blacklist. Were I less lazy I would actually check. In the end, though, this was the setting that got me back on track with Chrome:

There’s a plus side to all this mess. My SSL report card went from an A to an A+. So, there’s that, which is nice.

One Response to “ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY”

  1. Jojo says:

    Thanks for this. Sticking this into my nginx conf worked out my problem.

Leave a Reply

Your email address will not be published. Required fields are marked *