When deploying a server into production, you’ll most likely need to secure it with a SSL certificate, but even when installing some test servers, adding some encryption is always a good idea as well.
Depending the purpose of the server, and the environment it will be running in, a self-signed certificate may or may not be sufficient. But even if it is sufficient for the intended use of the server (only for internal services or resources for instance), having a nicely signed and trusted certificate makes everything a lot easier, even on a test server. At least it’s a good practice to avoid having your users develop a bad habit of trusting servers with self-signed certificates in general.
Think about the way the modern web-browsers handle websites with SSL certs which couldn’t be truly verified… Either showing the HTTP -only website as “not secure” (when no SSL cert is present) or even blocking access to the website if the SSL cert can’t be trusted.
The problem with official SSL certs, signed by a trusted 3rd party Certificate Authority, is: they cost money.
So buying SSL certs for all your servers, including the tests servers, can become quite expensive. Especially for smaller organizations.
You could go for a wildcard certificates which allow you to secure an unlimited amount of sub-domains with a single certificate. For instance: a SSL cert linked to *.mydomain.com will secure both production.mydomain.com and test.mydomain.com, or any other sub-domain.
While they can be very handy, and relatively cheap, the biggest concern with wildcard certificates is that, if one sub-domain or server gets compromised, all the other sub-domains using the same wildcard certificate might get compromised as well. Meaning that while a wildcard certificate gives you an easy and cheap way of securing an unlimited amount of servers, things can go very wrong if the cert gets compromised and give you a lot of extra work to replace the cert on all servers which are using it. One ring to rule them all right…?!
Another option would be a cert with SAN (Subject Alternative Names). This type of certs gives you the possibility to add a list of SAN entries to one specific certificate. This way, the cert will still cover multiple sub-domains, but only limited to the specified list. For instance a SAN list with “test1”, “test2”, “trial” will secure test1.mydomain.com, test2.mydomain.com, trial.mydomain.com. Hence all test servers in use can be secured with 1 single certificate, but production.mydomain.com will require a separate cert as “ production” is not in the SAN list.
This gives you a little more security when certs would get compromised, but still involves buying the certs and renew them over time, which can still be quite expensive for smaller (test) projects.
So, there is no such thing as a free lunch… or free security… or is there?
Well, yes, kind of! And this brings us to “Let’s encrypt’ !
Let’s encrypt (LE) is a free certificate authority providing publicly trusted certificates for website owners. Free, easy to install and easy to maintain / renew!
The beauty of LE is the really simple installation process. The only thing needed is shell access and 2 commands to be executed. The only hiccup here might be hosting providers without shell access to the hosting server. If that’s the case, check with your provider to see if they have a plugin in the hosting interface, like cPanel, to allow installation of free Let’s Encrypt SSL certs.
For the purpose of this post, I’ll limit the discussion to shell enabled servers.
And before we continue, let’s move one additional comment out of the way. The frequent question I hear is: What if the browser or operating system stops trusting the certificate chain? Well, first of all, have a look a Google. They are one of the big sponsors of LE, so it’s very unlikely that they will distrust it any time soon, and for other browser/OS compatibility info, have a look at: https://letsencrypt.org/docs/certificate-compatibility/
I think we should be good for the foreseeable future, and although there are people saying LE vulgarises the use of SSL certs (making people put less value in the fact that a website has a SSL cert or not), having one is better than just no security at all in my opinion. It’s all about educating internet users on how to check if they can trust a public web service, not where the SSL cert came from as such. But that’s a discussion we’ll leave for another time…
Another comment is the relatively short validity of the issued certificates, only 90 days, but while you could see this as additional workload to frequently having to renew the certs, it’s definitely a good think on the security side of it. Furthermore, Certbot (see below) is able to take care of the auto-renewal, and auto-renewal can also be achieved by creating a cron job:
$ sudo crontab -e
# Add this to the crontab and save it:
* 7,19 * * * certbot -q renew
I might do a post on cron jobs later. For more about how to use cron jobs: https://opensource.com/article/17/11/how-use-cron-linux
Before we really have a look at how to get those free SSL certs, one more thing. If LE is really the equivalent to a free lunch, why wouldn’t we all start using Let’s Encrypt and stop paying for expensive SSL certs? There must be something (apart from the comments above), holding us off having a big free SSL party right?
Well, while LE provides us with a really nice tool to easily encrypt our web servers, there is indeed 1 big difference or disadvantage: the green bar…
By now, anno 2018, we should all be used to seeing that green bar in the URL when browsing SSL protected websites. In the past, we only had the padlock next to the URL to identify a secure website, but over time Extended Domain Validation was added to provide even more information on whether the website should be trusted or not.
Very important when browsing websites, such as web shops, where we disclose very personal information such as credit card details and shipping addresses.
Extended Domain Validation (EV) not only checks the certificate requests against the domain name, but also proves that the certificate was requested by a trusted and verified entity. Before issuing the EV certificate, the CA will first verify the requesting entity’s identity (additional to checking the domain name as such).
Let’s Encrypt however, only provides domain validation, and no extended validation, meaning LE does not check the identity of the owner of the server / website. Your users, even if we know that (unfortunately still the case in 2018) too many people get into trouble by browsing phishing websites, not checking the SSL validation (green bar and/or padlock) and disclosing personal data to untrustworthy websites, a website without the green bar might provide less trust to your end users.
Maybe not a big deal for the intended purpose of your (test-) server, but still a consideration to keep in mind.
The final consideration I’d like to add, before having a look at the installation process, is the rate limit which LE puts on the system. Understandable for a free service, but if needed you can request an exception (do it well in advance as it can take some time to get approved): https://letsencrypt.org/docs/rate-limits/
So, now that we had this, longer than intended, overview of what LE is all about, let’s have a quick look on how to use it.
‘Let’s encrypt’uses the ACME protocol to verify that the requesting entity controls the given domain name, so to request an LE certificate, you’ll have to choose an ACME client to do so.
LE recommends the use of Certbot:
We recommend that most people start with the Certbot client. It can simply get a cert for you or also help you install, depending on what you prefer. It’s easy to use, works on many operating systems, and has great documentation.
If Certbot does not meet your needs, or you’d simply like to try something else, there are many more clients to choose from below, grouped by the language or environment they run in.
The ACME clients below are offered by third parties. Let’s Encrypt does not control or review third party clients and cannot make any guarantees about their safety or reliability.
For the purpose of this post, I’ll stick with Certbot and use Ubuntu 16.04.
The prerequisites are simple:
- Ubuntu 16.04 server
- non-root sudo-enabled user (add a normal user to the sudoer-list with the following command: usermod -aG sudo normalusername)
- Apache web server installed and configured to use the correct FQDN of the hosted web service
The first thing to do will be installing Certbot. As Certbot is the official client, the developers have their own repository. So let’s add it to the server with the following commands.
$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install python-certbot-apache
Note: for the purpose of this post I’m only focusing on using LE on an Apache server. Visit the Certbot site to get customized instructions for your operating system and web server.
Once Certbot is succesfully installed, you can easily use it to request your fancy, new and publicly trusted SSL cert. The only things you need are the FQDN of the server (or multiple sub-domains if needed), your email address and the following commands (Certbot will automatically configure your Apache server to use the new certificate).
Note: The following commands, which automatically create the certificate, must be executed on the target server where the FQDN resolves to. This is important for the automatic processing of the certificate request. See below for "manually" creating LE certificates (for instance for wildcard certs or when creating the certificates on another machine than the target server).
In case you only want to secure one FQDN:
$ sudo certbot --apache -d www.mydomain.com
If you want to use one single cert for multiple sub-domains, or SAN (as discussed above):
$ sudo certbot --apache -d mydomain.com -d www.mydomain.com -d server.mydomain.com -d alias.mydomain.com
Note: if you have multiple servers or virtual hosts, you will need to run the command(s) once on each server.
After running the commands above you will be presented by some questions. Certbot will ask you for the email address you want to use for cert recovery and notifications, as well as the choice between forcing all connections over HTTPS, or allowing HTTP access (subject to the type of server you are deploying, and what you want to achieve, but forcing all connections over HTTPS might be a good idea).
Provide the information and let Certbot do it’s magic. Upon completion you should find your fancy SSL certs in /etc/letsencrypt/live and on the web server by browsing to the https URL.
If you want Certbot to create the certificate without reconfiguring Apache to use the certificate, you need to add the “certonly” flag:
$ sudo certbot --apache certonly -d www.mydomain.com
(the certificate will be created in /etc/letsencrypt/live/, waiting for you to deploy it)
After installing a SSL cert it’s always a good idea to run it through a test, such as https://www.sslcheck.nl
As you can see, the LE provides a really basic SSL cert, with only Domain Validation, no additional features or information, and a 90 day validity.
The SSL checker will also give you the details on the Let’s Encrypt Authority and DST Root CA X3 chain of trust.
Also, have a look at your website via: https://YOURFQDN, and investigate the URL / SSL padlock.
Initially, as I was hosting this blog myself, I used LE to create the SSL certificate, but for other reasons, not related to SSL, I decided to move it to a managed hosting in the mean time. The hosting included a SSL cert, so, for those who are checking my URL now: the blog does not have a LE cert. Nevertheless LE gave me what I needed to configure the blog with SSL initially.
As you can see, LE really provides you a nice and easy way to get your servers the SSL cert they need, but just remember the difference between a normal SSL padlock and the green bar with Extended Validation:
As discussed, LE certificates are valid for 90 days, but Certbot will run a renewal task, by default twice a day (certbot renew) via the systemd timer. The auto-renewal will renew all certs within a 30 day expiration timeframe.
For non-systemd distributions you can add a cron job via /etc/cron.d, as discussed above.
To test the renewal, run the following command:
$ sudo certbot renew --dry-run
In case the renewal fails, you should get an expiration notification by Certbot, sent to the email address you provided when you requested the cert.
Now, what about wildcard certificates? Well, first of all, as LE is free and easy to implement, you might want to stick with individual or SAN certificates to limit the risk in case the cert gets compromised. However, there might be situations (such as testing purposes) where a wildcard might come in handy.
Good news! Earlier this year LE added wildcard certificates to their services: https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578
The only difference with requesting “normal” SSL certs is the way you request them, being manually over a DNS-01 challenge, but don’t worry, even if this adds an additional step, the process is still straight forward and easy.
Note: creating wildcard certificates is only possible with the ‘certonly’ flag. Certbot will not be configuring Apache with wildcard certs automatically.
First of all, make sure you have access to the DNS server / portal of the domain for which you are creating a wildcard cert. You will have to add a DNS record to complete the cert request.
To make the request, run the following command:
$ sudo certbot certonly --manual -d *.yourdomain.com --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory
You will be asked once again to provide your email address, and choose whether or not you want to subscribe to the newsletter. Once the request has been made, you will receive instructions similar to the following:
Please deploy a DNS TXT record under the name _acme-challenge.yourdomain.com with the following value abcdefgh...1234567...
Before continuing, verify the record is deployed.
Press Enter to Continue
This is where your DNS server / portal comes in, as you should add a text DNS record for the domain with the name and value provided by Certbot (a random string will be provide as in the instruction above…). Add the record and set the TTL to the smallest allowed value (e.g. 600s).
Grab a coffee!
Once the DNS record has been replicated (you can check the public DNS replication for _acme-challenge.yourdomain.com on DNS checkers such as https://dnschecker.org for instance), hit Enter to continue on the Certbot prompt.
Just like when creating the cert without automatically configuring Apache to use it, the wildcard cert will available in /etc/letsencrypt/live.
Note: the command I used above, to create the wildcard cert, can also be used for a specific FQDN, in case you want to create it on another machine than the actual server you are requesting the cert for, and in case you can’t (or don’t want to) manually add the DNS record for the FQDN, have a look a some available plugins here.
For more advanced usage, have a look at the Certbot User Guide!
As usual, if you liked this post, hit the like button, tell your friend about this blog and leave a comment below. Don’t hesitate to make suggestions, or corrections!