Encrypt all the things!

Mark Henderson

Let’s talk about encryption. Specifically, HTTPS encryption. If you’ve been following any of the U.S. election debates, encryption is a topic that the politicians want to talk about – but not in the way that most of us would like. And it’s not just exclusive to the U.S. – the U.K. is proposing banning encrypted services, Australia is similar. If you’re really into it, you can get information about most countries cryptography laws.

But one thing is very clear – if your traffic is not encrypted, it’s almost certainly being watched and monitored by someone in a government somewhere – this is the well publicised reason behind governments opposing widespread encryption. The NSA’s PRISM program is the most well known, which is also contributed to by the British and Australian intelligence agencies.

Which is why when the EFF announced their Let’s Encrypt project (in conjunction with Mozilla, Cisco, Akamai and others), we thought it sounded like a great idea.

The premise is simple:

  • Provide free encryption certificates
  • Make renewing certificates and installing them on your systems easy
  • Keep the certificates secure by installing them properly and issuing them best practices
  • Be transparent. Issued and revoked certificates are publically auditable
  • Be open. Make a platform and a standard that anyone can use and build on.
  • Benefit the internet through cooperation – don’t let one body control access to the service

Let’s Encrypt explain this elegantly themselves:

The objective of Let’s Encrypt and the ACME protocol is to make it possible to set up an HTTPS server and have it automatically obtain a browser-trusted certificate, without any human intervention.

The process goes a bit like this:

  1. Get your web server up and running, as per normal, on HTTP.
  2. Install the appropriate Let’s Encrypt tool for your platform. Currently there is ACME protocol support for:
    1. Apache (Let’s Encrypt)
    2. Nginx (Let’s Encrypt — experimental)
    3. HAProxy (janeczku)
    4. IIS (ACMESharp)
  3. Run the tool. It will generate a Certificate Signing Request for your domain, submit it to Let’s Encrypt, and then give you options for validating the ownership of your domain. The easiest method of validating ownership is one that the tool can do automatically, which is creating a file with a pre-determined, random file name, that the Let’s Encrypt server can then validate
  4. The tool then receives the valid certificate from the Let’s Encrypt Certificate Authority and installs it onto your systems, and configures your web server to use the certificate
  5. You need to renew the certificate in fewer than 90 days – so you then need to set up a scheduled task (cron job for Linux, scheduled task for Windows) to execute the renewal command for your platform (see your tool’s documentation for this).

And that’s it. No copy/pasting your CSR into poorly built web interfaces, or waiting for the email to confirm the certificate to come through, or hand-building PEM files with certificate chains. No faxing documents to numbers in foreign countries. No panicking at the last minute because you forgot to renew your certificate. Free, unencumbered, automatically renewed, SSL certificates for life.

Who Let’s Encrypt is for

  • People running their own web servers.
    • You could be small businesses running Windows SBS server
    • You could be a startup offering a Software as a Service platform
    • You could be a local hackerspace running a forum
    • You could be a highschool student with a website about making clocks
  • People with a registered, publically accessible domain name
    • Let’s Encrypt requires some form of domain name validation, whether it be a file it can probe over HTTP to verify your ownership of the domain name, or creating a DNS record it can verify
    • Certificate Authorities no longer issue certificates for “made-up” internal domain names or reserved IP addresses

Who Let’s Encrypt is not for

  • Anyone on shared web hosting
    • Let’s Encrypt requires the input of the server operator. If you are not running your own web server, then this isn’t for you.
  • Anyone who wants to keep the existence of their certificates a secret
    • Every certificate issued by Let’s Encrypt is publically auditable, which means that if you don’t want anyone to know that you have a server on a given domain, then don’t use Let’s Encrypt
    • If you have sensitive server names (such as finance.corp.example.com), even though it’s firewalled, you might not want to use Let’s Encrypt
  • Anyone who needs a wildcard certificate
    • Let’s Encrypt does not issue wildcard certificates. They don’t need to – they offer unlimited certificates, and you can even specify multiple Subject Alternative Names on your certificate signing request
    • However, you may still need a wildcard if:
      • You have a lot of domains and can’t use SNI (I’m looking at you, Android 2.x, of which there is still a non-trivial number of users)
      • You have systems that require a wildcard certificate (some unified communications systems do this)
  • Anyone who needs a long-lived certificate
    • Let’s Encrypt certificates are only valid for 90 days, and must be renewed prior to then. If you need a long-lived certificate, then Let’s Encrypt is not for you
  • Anyone who wants Extended Validation
    • Let’s Encrypt only validates that you have control over a given domain. It does not validate your identity or business or anything of that nature. As such you cannot get the green security bar that displays in the browser for places like banks or PayPal.
  • Anyone who needs their certificate to be trusted by really old things
    • If you have devices from 1997 that only trust 1997’s list of CA’s, then you’re going to have a bad time
    • However, this is likely the least of your troubles
    • Let’s Encrypt is trusted by:
      • Android version 2.3.6 and above, released 2011-09-02
      • FireFox version 2.0 and above, released 2006-10-24
      • Internet Explorer on Windows Vista or above (For Windows XP, see this issue), released 2007-01-30
      • Google Chrome on Windows Vista or above (For Windows XP, see this issue), released 2008-08-02
      • Safari on OSX v4.0 or above (Mac OSX 10.4 or newer), released 2005-04-29
      • Safari on iOS v3.1 or above, released 2010-02-02

However, these are mostly edge cases, and if you’re reading this blog post, then you will know if they apply to you or not.

So let’s get out there and encrypt!

The elephant in the room

“But hang on!”, I hear the eagle-eyed reader say. “Stack Overflow is not using SSL/TLS!” you say. And you would be partly correct.

We do offer SSL on all our main sites. Go ahead, try it:

However, we have some slightly more complicated issues at hand. For details about our issues, see the great blog post by Nick Craver. It’s from 2013 and we have fixed many of the issues that we were facing back then, but there is still some way to go.

However, all our signup and login pages however are delivered over HTTPS, and you can switch to HTTPS manually if you would prefer – for most sites.

Let’s get started

So how do you get started? If you have a debian-based Apache server, then grab the Let’s Encrypt tool and go!

If you’re on a different platform, then check the list of pre-build clients above, or take a look at a recent comparison of the most common *nix scripts.


 

Addendum: Michael Hampton pointed out to me that Fedora ships with the Let’s Encrypt package as a part of their distribution and is also in EPEL if you’re on RedHat, CentOS or another distribution that can make use of EPEL packages.

«
»
  • Thomas

    I should point out, though, that the Lets Encrypt packages and tools may end up being extremely outdated as development of LE continues. This is an observation in Ubuntu, in which someone is attempting to try and get the LE client removed from the upcoming release, until it is officially ‘stable’

  • personally I wouldn’t want to use the package versions, since doing a git clone is easy, and guarantees you’re always on the “latest and greatest”

    also, at least as of a couple weeks ago, some of the informaiton in this SF blog post are incorrect (with regards to CentOS 6) – see my how-to write-up: http://antipaucity.com/2016/01/06/lets-encrypt-centos-6-truly-free-ssl