HTTP/2, HTTPS, Let’s Encrypt and WordPress

Let's Encrypt

TL;DR — HTTP/2 is awesome, but requires HTTPS, which is hard to setup. Let’s Encrypt and WordPress can make HTTPS setup simple and help achieve a faster web sooner.

My eyes are heavy, my head foggy. Kind of feels like I’m in a dream right now. A couple of hours ago I got home from Philadelphia, where I attended the WordPress Community Summit and the first annual WordCamp US over the past 7 days. And man, what a time.

There will be plenty of recap posts published this week, so instead, I thought I’d dig into one thing I got very excited about at the summit.


Weeks ago I got really excited about HTTP/2 while researching it for
an episode of Apply Filters. (If you haven’t learned about HTTP/2 yet, I urge you to listen to that episode. I’m very proud of the work Pippin and I did on it.) I learned that adding support for HTTP/2 on your site gives it an instant performance boost. And if you already have HTTPS setup, enabling HTTP/2 is as easy as updating Nginx to version 1.9.6+ and adding http2 to the config file:

listen 443 ssl http2;

If you don’t have HTTPS setup, you have do that in order to get HTTP/2 as it is only supported over HTTPS.


Unfortunately setting up and managing HTTPS is currently a huge pain. You have to generate a CSR, go to a certificate vendor, verify that you’re the owner of your domain, buy a certificate, install it on the server and configure your web server to use it. Then every year you have to go through the first part of the process again, buying a certificate renewal, and replacing the certificate files on your server. It’s an annual annoyance that no one wants.

The process is also terribly broken as well. Ever have a certificate vendor send you your certificate pasted into the body of an email? I have. An email!

Let’s Encrypt

Enter Let’s Encrypt, which just went public beta last week. The goal of Let’s Encrypt is to offer free certificates and automate their issuance and renewal. It’s being developed by an organization backed by Mozilla, Facebook, Automattic and some other big companies.

Basically Let’s Encrypt offers an API where you can request a certificate and it sends one back. They have a command line client that you can install on your server easily enough:

$ git clone
$ cd letsencrypt
$ ./letsencrypt-auto

Then it’s a pretty straightforward command to get a certificate:

$ ./letsencrypt-auto certonly --webroot -w /var/www/example/public/ -d -d

Here we’re specifying our webroot folder so that it can place a file in there to verify domain ownership. Pretty neat. Certificate files end up in /etc/letsencrypt/live/ So now you just need to update your server config with the necessary directives referring to those certificate files. Already soooo much easier than before. But what if it could be even easier. This is the part that I learned about at the summit and got excited about.


Enter WordPress. As you probably already know, around 25% of the web runs on WordPress. When WordPress changes, the web changes. The impact is huge. And so, what better way to convert the web to HTTPS than to use WordPress. Specifically, a WordPress plugin.

Zack Tollman and John Blackbourn have been working on a Let’s Encrypt plugin for WordPress. The idea is that you would search for the plugin in your WordPress dashboard, one-click install it, and run an ultra simple WP-CLI command:

$ wp cert new

The above command assumes you’re in the webroot folder of your site. If you want to run the command from another folder you can provide the --path argument:

$ wp --path=/var/www/example/public/ cert new

The plugin will interact directly with the Let’s Encrypt API, so no need to download and install a command line tool. It hasn’t been decided yet, but I’m guessing it will follow the official Let’s Encrypt client and store certificate files in /etc/letsencrypt/live/ or at least encourage you to move them there.

I highly recommend checking out the GitHub repo and specifically the file to learn how you can help out with development, testing, etc. At the time of publishing this article, the focus is building a PHP library to implement the ACME protocol and interact with the Let’s Encrypt API.


As I said before, one of the main goals of Let’s Encrypt is automating the renewal of certificates. In fact, Let’s Encrypt’s certificates are only good for a max of 90 days, then they expire. That’s a huge departure from the 12-month lifetime you get when you pay for a certificate.

The theory here is that having a short lifetime will annoy people who are doing it manually and encourage them automate renewal. I know it would be incredibly annoying to me if I had to manually renew my certificates every 90 days.

Fortunately automating renewals is as easy as generating a certificate the first time. Just run the same command and it will replace your current certificate files with the renewed ones. No need to update your web server configuration. And so, automating renewal will be just a matter of installing a cron that runs the command on a monthly basis:

0 0 1 * * wp --path=/var/www/example/public/ cert new

I want to reiterate that the WordPress plugin hasn’t been released yet and the command above is just an example of what it could be when it’s released.


HTTP/2 is the future of the web. Converting the HTTP web to HTTPS is the path to get there and so setting up HTTPS has to get a lot easier and ongoing maintenance almost eliminated. Fortunately with Let’s Encrypt, easy is now possible, and soon it will be even easier with the WordPress plugin. I’m really looking forward to a faster web.

About the Author

Brad Touesnard

As founder of Delicious Brains Inc., Brad wears many hats; from coding and design, to marketing and partnerships. Before starting Delicious Brains, Brad was a busy freelance web developer, specializing in front-end development.

  • The real question is when will webhosts support this vs the paid model of https.

    • Jon

      From the hosts I talked to… very soon… and probably for free. Time will tell if that holds up, but Let’s Encrypt makes installing/updating/managing the cert near zero maintenace for the hosts.

      The only people paying for certs are going to be those wanting EV.

    • Oh yea, oops, I meant to write a paragraph about that. Many of the big hosts were in the room when we met about HTTPS at the Community Summit and are totally onboard with Let’s Encrypt. I was surprised by this, but it turns out they don’t make much on SSL certs so it’s not much of a loss and they gain a ton by not having to deal with support tickets about installing new SSL certs AND renewals.

      • Yeah with SiteGround on board thats an awesome start. Now to get WP Engine, Pagely and that little company called GoDaddy involved.

    • The big, largely undiscussed, problem with https is performance. I host my sites on WP Engine’s dedicated servers. I could switch all of my sites over to https tomorrow however my servers would take a huge performance hit. WP Engine’s secret sauce is their customized caching layer. This is mostly ignored when running on https. I talked with a few of the WP Engine guys at WordCamp US, they said they working on partial page caching and some other things like php7 will help “https everywhere” scale however I got the feeling the real answer is I need to host less websites per server.

      • @austinginder:disqus, this is the first I’ve heard about WP Engine not caching https. I had no idea. I have a few https sites on WP Engine. Can you tell me more about that?

        • I first discovered this when attempting to enabling https on a few WP Engine sites. The first question their support guys ask is “which page would you like https on?”. If you press them to enable https everyone, they warn how the performance of the site can be affected as their caching is not optimized for https everywhere. If you want more details, try contacting their support. Maybe you’ll get some more technical details. I suspect their vague answers are due to the fact that their caching system is not something they fully discuss with the public.

          • I’ve had them implement https everywhere on 3 of my sites and they’ve never warned me about performance. #sunuvagun

          • HAProxy, HIpache, NGINX, Varnish (plus), etc. let you terminate TLS at the proxy then work behind the scenes between nodes/containers in HTTP if you want. I’m playing with a cluster on tutum atm… Not quite working yet for me, but I know it’s possible.

          • WPMS.Network

            SiteGround had something similar going on until just a few month’s ago… they were using Varnish in front of their nginx and essentially were not caching HTTPS… when I really pressed them on behalf of some clients at SG and pointed out that their docs had implied that they were caching HTTPS… well, they didn’t respond directly, instead they just fixed their systems so that the docs were correct =)

        • Never had this problem on WPE, in fact with woocommerce sites we need to tell them to exclude https pages from the cache so it doesn’t break user sessions.

          Definite speed increase using SSL on wpengine with wildcard SSL cert so CDN is pulled through HTTPS too

          • @tullibo:disqus You’re right – I recently checked with WP Engine, and they confirmed they cache everything including https… I believe they said they automatically exclude Woocommerce shop URLs, but not sure I recall that correctly. Best to confirm for each site anyway.

            I’m curious how you’re getting a speed increase with SSL though. They’re not using HTTP2 yet.

          • @joefletcher:disqus we almost always use Cloudflare with WPengine – it’s like throwing rocket fuel on a rocket fuel fire. The combo of fast Cloudflare DNS, HTTP2 and additional Cloudflare CDN on top of WPEngine CDN is awesome.

            The render is noticeably faster with SSL+Cloudflare. We use wildcard SSL cert so we can use SSL on the CDN with a custom CDN URL

            I go into it in more detail here, this is the stuff we layer on top of WPE:

          • Awesome – I’m actually doing this exact setup right now, and that blog post rocks. I was just wondering how I was going to handle the cdn + ssl. I did the regular ssl with WPE and forgot about the cdn… will probably do the wildcard cert, but offhand, do you know if I can just provide them a 2nd cert for I was also thinking about using KeyCDN instead of WPE’s MaxCDN since they provide free SSL (Let’s Encrypt) and HTTP2.

          • @joefletcher:disqus probably can use a separate cert as the cert is setup in maxcdn and I think the process is manual, we use the $95 wildcard cert from namecheap

          • @joefletcher:disqus ….oh and with Woo we normally have to log a support ticket and tell them the URLs to exclude. If we don’t do it the user sessions get disconnected from the users and one user may suddenly have another user’s cart.

      • HAProxy, HIpache, NGINX, Varnish (plus), etc. let you terminate TLS at the proxy then work behind the scenes between nodes/containers in HTTP if you want. I’m playing with a cluster on tutum & DO atm… Not quite working yet for me, but I know it’s possible.

      • That’s more an issue with their server setup than with HTTPS per sé. With many parties pushing for increased TLS usage (Google’s Chrome, etc.) hosters should prepare their architecture for the coming demands. WP Engine could terminate TLS in front of their caching layer, enabling them to cache everything. Many people do this, and it’s scalable, but it takes work on their part. The hosting company I work for only caches HTTP-requests and I’m about to change our setup to cache all requests.

    • Exactly! Is the TLV of a customer greater if the hosting company says (something like) “Free SSLs for everyone!” or is the TLV of a customer greater if the hosting company relies on their SSL reseller revenue?

    • David London

      Looks like StackPress is on board

  • Devin Price

    Very timely post! I was just looking for a tutorial on how to enable HTTP/2 on my Digital Ocean box (already running ngnix with SSL). Looks dead simple.

    I’ll wait a bit on the Let’s Encrypt. Excited to learn that Zach and John are working on tools to make this process completely streamlined.

  • Jon

    Exciting news for me too!

    The thing I didn’t hear anyone talk about it compatibility and fall back. What happens with IE 9/10/11? when they hit an HTTP/2 server? Does apache/nginx fall back to HTTPS/1.2

    Yes… I’m googling it now…

    • Yes, H2 is backwards compatible, so it falls back to HTTP 1.1.

  • Exciting times, I guess in next 6 months a lot about what we knew is going to change 🙂

  • Switching to HTTP2 can give an immediate speed boost if you’re already on HTTPS + HTTP1.1 on SOME browsers (estimates are between 23-77%). If you are already on SPDY, however, you will gain speed on H2 supported browsers but your overall coverage of browsers will fallback to slower 1.1. Also, if you are switching from HTTP to HTTPS, you may further decrease your speed on non H2 browsers because of SSL handshake latency and possibly caching issues.

    You also need to consider that H/2 & H/1.1 optimization strategies are opposite, so you need to choose a route: on H/1.1 you should concatenate css & javascript, use spritesheets, and use domain-sharding. on H2 you should NOT do any of those. If you optimize for H2, H1.1 fallback browsers will be much slower. If you optimize for H1, your H2 won’t reach its potential speed.

    At first I was excited by the just-do-it-and-get-speed-boosts by H2, but after looking at the coverage of H2 browsers, you’re more likely to get better performance overall using SPDY until H2 support increases &/or when Chrome drops support for SPDY, which they’ve said they will first half 2016.

    Shows real world H2 coverage closer to 23%:

    “Estimates” coverage is ~63 – 77%:

    P.S., I’d love to be proven wrong by any of this! 🙂

    • > Also, if you are switching from HTTP to HTTPS, you may further decrease your speed on non H2 browsers because of SSL handshake latency and possibly caching issues.

      I would say the performance gain of multiplexing in SPDY & HTTP/2 far outweighs this downside.

      > Shows real world H2 coverage closer to 23%

      These stats aren’t a great way to make a decision. I would say look at YOUR stats, the browser versions your visitors are running and determine if they support HTTP/2. The visitors to this site are mainly developers and tend to be running the latest greatest, so it made sense for us to upgrade.

      • > the performance gain of multiplexing in SPDY & HTTP/2 far outweighs this downside.

        Correct: for H2 browsers – otherwise it falls back to HTTP 1.1. Same for SPDY browsers. Note, H2 does not fallback to SPDY, so you either do H2 or SPDY. If you do H2, roughly 30% will get 1.1 (mostly IE). If you do SPDY, about 25% will get 1.1 (according to

        But good point – first step is to look at your own stats to make this decision, and if actual H2 browser share is vast majority, probably makes sense to go H2.

  • Mint Plugins

    This looks like a game changer! I am trying to update my Digital Ocean to nginx 1.9.6 but it seems to be maxing out at 1.4.6 – any tips about how I can make it upgrade to the true latest? Much appreciated.

    • Latest nginx is 1.9.8. Make sure you are on Mainline version.

      • Mint Plugins

        Thanks for the reply. It took me a while to figure out what that meant so I’ll leave this here for anyone else looking. On your Ubuntu server open the file here: /etc/apt/sources.list and put these lines at the bottom:

        deb trusty nginx
        deb-src trusty nginx

        Then you can update nginx using:

        sudo apt-get update
        sudo apt-get clean
        sudo apt-get install nginx

        • Mint Plugins

          What I didn’t anticipate was that updating to nginx 1.9.8 would break the way that PHP works with nginx – and that virtual sites are set up differently than in previous versions of nginx. Updating to nginx latest version is proving to be quite a bit more difficult than anticipated :/

  • WPMS.Network

    …hoping the plugin will eventually play well with Multisite Networks =)

    also, check out this fun sauce:

  • I have a problem here ~ I think ~ because I have a non-standard Ubuntu 14.04 LTS server installation. ServerPilot builds their own “deb” packages of Nginx, Apache, and PHP and do not install the versions provided by Ubuntu.

    As soon as I try and activate I get a fatal error ~ /public/wp-content/plugins/lets-encrypt-wp-master/lets-encrypt-wp.php on line 13

  • Scott Lesovic

    I’m not sure about switching to HTTP2 quite yet. NGINX removed the SPDY module in favor of HTTP2. If I’m reading the browser support correctly, SPDY is still on top for compatibility. I think I might wait until CloudFlare releases their setup where HTTP2 can fall back to SPDY.

    I am looking forward to trying out Let’s Encrypt and I’ll take a look at the wpcli command to go with it.

  • Pressjitsu

    Worth noting that some webhosts (wink!) already support Let’s Encrypt without the need for root privileges or the LE client. Everything is wrapped into a nice UI and renewals are handled behind the scenes:

  • Awesome, you guys are really on the ball with new projects. I’ve been exploring how to get lets encrypt working with HAProxy which I expect will become a more common setup as dockerized environments are adopted.

  • Robey Lawrence

    Is it still a requirement to have a dedicated IP for each site with a certificate? e.g. I have a VPS running multiple sites, do I need to rent an IP for each that I want HTTPS on?
    Or are there ways around that now?

    • No, SNI-support in all modern webservers and browsers has made that no longer a big issue. Some old browsers and platforms don’t support SNI, e.g. IE on XP, Android 2, Blackberry Browser…

  • As of 05-FEB-16 ~ Please note that the WordPress plugin is a project in progress. It currently does nothing.