Firstly this article is all about using SSL/TLS certificates to enable HTTPS encrypted connections to websites and web applicaitons. Specifically obtaining LetsEncrypt certificates that are provided for free to support the adotion of the HTTPS protocol. If you don’t now what this is or don’t think you need it you should read about why it’s important.
Why HTTPS Matters by Kayce Basques – Technical Writer at Google and obviously the LetsEncrypt site will explain how and why they supply certificates for free!
If you’re interested in how the web is switching to HTTPS then Scott Helme has an interesting article with stacks of stats and his site has lots of info on web application security.
Secondly if you’re not comfortable with using the command line or are asking the question “what’s the command line?”, well it’s not a direct line to Norad, this article may lose you at times. Please read on but if this all sounds like too much work and you just want to secure connections to your site then simply purchase an SSL/TLS certificate for your site.
Do I need to keep writing SSL/TLS or can we just put that one to be and call it TLS from now on, we know where we are!
So, if you have shared hosting, space on clustered hardware with no administrative shell access, are unable toinstall LetsEncrypt or run automated certificate provisioning through a control panel feature/plugin or just don’t want to? Do not despair you can still use LetsEncrypt, but you may need a friendly support team at your hosting provider.
If you don’t have a friendly support team or support for LetsEncrypt, then it really is time to find another hosting provider.
First things first, obtaining certificates from LetsEncrypt will require the cerbot client, these are normally installed on the hosting server and the process automated. But as said, we’re not doing that! So we will install this on our local/another machine and give it some certificate serving goodness. To find out which version client you need visit the certbot site under the EFF domain.
At this point, if you don’t know who the Electronic Frontier Foundation is, you really should, go to their site and check out all the work they do to defend privacy and rights to it, they really are internet superheroes.
So on the certbot site you just need to specify what software the client will interact with and what OS you are using. Remember most installs of the client on the hosting server, but we will just be dealing with the end certificates and private key so there’s not need to worry too much about the web server software option.
The next option is what OS you are using, this will be the OS of the machine we are running the client on, so select one appropriate for you, if yours is not listed, you could run one of these in a virtual machine. I guess there will be lots of windows users now rolling their eyes at this point as there isn’t a standard client for windows yet. Check the LetsEncrypt list of implemented clients, you may find one there.
ACMESharp appears to be a popular windows client but I haven’t tried or tested it, so I can’t provide any more on this one.
Installing
So once selected the Certbot site will provide instructions on how to obtain the certbot client, it should be available in existing packages from your OS provider. Again we don’t need the server software plugins so we only need to deal with installing the certbot client itself. So for Ubuntu or other linux based OS it will be something like:
$ sudo apt-get install python-certbot-apache
or for MacOSX it is available through Homebrew:
$ brew install certbot
I’m not going into install any further than this, but safe to assume stuff happens and then you can test the install by checking the version:
$ certbot --version
So we now have the certbot client installed and ready for some TLS action!
Requesting a Certificate
The good news is, it starts getting simple from here on in, how simple may depend on your comfort levels with the command line but even if you’ve just installed a linux flavor or opened Terminal on a Mac for the first time, we’re not going to be doing anything too crazy so just breathe.
If you are using the command line for the first time you can add the –dry-run option to the initial command to run the process without breaking anything.
The first command and pretty much all you need to do to start the certificate ball rolling is to request a new certificate and indicate you want to just generate a certificate and with manual instructions:
certbot certonly --manual
or if you want to practice first
certbot certonly --manual --dry-run
This will start the process by asking what domains you want the certificate to cover, assuming most will be just securing a site with no specific subdomains at this point. Just remember to add the domain and the www. subdoman, this is the standard approach for a single domain.
If you want to just provide the domains as part of your initial command you can add each domain with the -d option
certbot certonly --manual -d www.jtinteractive.co.uk -d jtinteractive.co.uk
again with the –dry-run option if you’re just toeing the water
certbot certonly --manual --dry-run -d www.jtinteractive.co.uk -d jtinteractive.co.uk
The next step is just for information really but obviously as this process is all about securing connections and security, certbot will expect to log the requesting IP. I will assume you’re ok with this or are using a VPN.
I has all your IPs!
Now we’ve requested to generate a certificate for a specific domain and this means certbot will now want proof we are the owners of this domain. Certbot will need you to make a change to the site to prove you own the site/domain.
This is a standard step even when purchasing a commercial paid certificate, although you are given several ways to prove the ownership with purchased certificates, with certbot there is just one. You need to add a generated code to a specific location on your site, this is given in the next message:
Make sure your web server displays the following content at http://jtinteractive.co.uk/.well-known/acme-challenge/o0pVkH6SaHD85E-9V3Q-MO-uqXW_m9pC_zyXFoFiQ before continuing: o0pVkH6SuHD85E-9V3Q-MO-uqXW_m9upC_zyXFoFiQ.cJcT0P4tK7iLQfjfaOuDT5iMvyRMYEyIZwtahqTl0
So you need to create the folder structure “.well-known/acme-challenge/o0pVkH6SaHD85E-9V3Q-MO-uqXW_m9pC_zyXFoFiQ/” then create a file inside this last folder with the content “o0pVkH6SuHD85E-9V3Q-MO-uqXW_m9upC_zyXFoFiQ.cJcT0P4tK7iLQfjfaOuDT5iMvyRMYEyIZwtahqTl0”
Don’t copy the codes I used here as your certbot client will generate the last folder and content code specifically for each certificate request you make!
There are other instructions on this screen:
If you don't have HTTP server configured, you can run the following command on the target server (as root):
but these relate to starting and HTTP server and creating the file using the command line with administrative/root access. Which may sound slightly strange. You may expect this to be bit of a chicken and egg question, with the website first and certificate second. But these days it’s often necessary to create and deploy the server in a production ready shape in one action. Building a server and site in parts just will leave insecure gaps in the timeline. If that sounds excessive, when I create new virtual servers, the IPs are actually being re-used (pooled) and therefore come under attack/scans within 20 seconds of being applied to a server instance.
Back to the job in hand, to make the URL respond with the code you will need to create a file that responds with just that code. The most common approach would probably be to place an “index.php” file that just echos the code such as:
<?php echo "o0pVkH6SuHD85E-9V3Q-MO-uqXW_m9upC_zyXFoFiQ.cJcT0P4tK7iLQfjfaOuDT5iMvyRMYEyIZwtahqTl0"; ?>
This assumes that “index” files are set as the default file within a folder. Adjust this and the file contents to suit your servers requirments. Retrun to the command line and press ‘ENTER’ as requested. If all goes well you will either get one or both of the following responses. The one you are hoping for is:
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/jtinteractive.co.uk/fullchain.pem. Your cert will expire on 2017-05-07. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
However you may see this one:
In fact you may, as I tend to do, see both, first the challenge failure and then the success and location of certificates. Don’t worry if this is the case, you only need to be concerned if you only see the failure message on it’s own. In this case double check the file is available, paste the full requesting URL address from the certbot client output into a browser. Confirm you can see this file and it only reports the verification code and nothing else.
This quirk/bug of showing a self-verify challenge failure repeats when renewing a certificate but I will explain that later.
So assuming you now have received the congratulations message which includes the file path to the certificate, key and chain files. In my case and most *nix distros this is:
/etc/letsencrypt/live/yourdomain.com/
Deployment
The next step is to apply these files to your server/site. This article is aimed at those without admin access or administrative access. However you may have the ability to apply certificates through a control panel. This may enable you to apply this certificate but you need to check with your hosting provider.
The files are:
- privkey.pem – Private Key
- chain.pem – Intermediate Certificate
- cert.pem – Server Certificate
- fullchain.pem – All Certificates
Full details on the files and their contents/use can be found on the certbot site.
In the case we are dealing with you will need to supply the files key to your hosting provider for them to apply. I recommend considering how you supply these files especially the private key. Email is not a secure method, if you can SFTP the files to a location outside the web root of your hosting and provide the path to your hosting provider via a support ticket.
The final step would be to redirect all traffic to HTTPS, again in this situation it is expected this may be done by the hosting provider or it can be achieved by adding the REWRITE rule to an .htaccess file in the web root:
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://jtinteractive.co.uk/$1 [R,L]
There you have it, you should now be looking at your site serving all content over an HTTPS connection, reassuring visitors and proudly showing a green padlock (in most browsers).
Renewing
Now a word of caution, forget all this and expect this to continue forever more! Certificates from LetsEncrypt have a short life span when compared to standard paid for certificates. This is done to enhance the security of certificates. This will mean manual processes like the one show here will need to be repeated often, but this is the reason why Certbot certificates should be automated. The push to encrypt the web makes automation essential. It’s just at the moment not every host provider is ready for it.
So renewing, so long as you renew inside the 90 day limit you can renew the certificate with the same process as above but with a different intial command:
certbot certonly --force-renew -a manual -d www.jtinteractive.co.uk -d jtinteractive.co.uk
This will update the certificates in the ‘live’ folder in the same path as before:
/etc/letsencrypt/live/yourdomain.com/live/
As with the initial certificate request the challenge to prove ownership of the domain may show to fail, in fact with a renewal I have seen it fail repeatedly. When this process fails twice in a row, it will abort the process and dump the user out cancelling the request. If this occurs add the –debug option to the command and this should provide extra information including the URL used in the challenge attempt:
FailedChallenges: Failed authorization procedure. www.jtinteractive.co.uk (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.jtinteractive.co.uk/.well-known/acme-challenge/q0ThiZVSJCVpsF0CvyTeMpPsA7nOPE3UArxJV-DA:
It’s worth checking the URL that is reported in the failure, I have found that the generated folder name is actually the one generated in the first/previous attempt. Which appears to show a level of caching and an offset. To correct this you can just re-run the the process on the second of the two permitted attempts, but don’t update the folder and file contents, it will then pass and you will get the succes message and renewed certificates.
I am still checking if this is a known bug, fully manual renewals are not as common as automated. If it hasn’t been reported, I will need to run several more renewals before I can confirm and document this.
So that’s it, there is a lot more that can be done to simplyfy the process from the command line, if you’re happy to experiment.
Support Lets Encrypt and the EFF
Don’t forget to read more on the work being done by EFF to encrypt the web and get HTTPS everywhere by implementing TLS in the browser to plug the current gaps. The more site owners invest in HTTPS the closer we get to a more reliable and safer web. In the mean time support the EFF and the Certbot work.
Comments are closed.