This article is the first one in a series called startups’ tools. We will talk about SSL and Let’s Encrypt. Most startups are tech oriented companies which heavily relies on computer softwares and infrastructures. However they are not always specialists for every technical aspects. Since, at Open Agora we have invested time into some essential tools, we want to make this knowledge available to people facing similar problems.
What is SSL and Why should we care about SSL certificates?
SL/TLS is a technology used, on the web, to confirm identity, ensure integrity and encrypt communications (in the rest of this article we will simply use SSL rather than SSL/TLS because TLS is simply an upgrade of SSL technology). It can be used by several protocols but the most common use of SSL is the https protocol (the green lock on the left of the address of websites in browsers).
In order to use https, a website needs SSL certificates.
First these certificates will prove to the website’s visitors that they are actually connected to the site they are willing to connect (it means that some third party has signed the certificates and guarantees the authenticity of the website).
Second, SSL certificates enable encryption between websites and Internet browsers. Whenever you download a non-encrypted webpage it may be observed on every network device on the path to it, and the data you transit to such a webpage could also be observed.
SSL is certainly not perfect, and some large governmental entities (NSA, for example) could be able to break the encryption provided by SSL certificates. However, it requires a lot of computing power and it is usually not feasible in real time. In any case it is not accessible to the regular security hackers.
For a web company, SSL certificates are necessary to offer privacy and security to its customers, and of course to be identified.
What is Let’s Encrypt?
Let’s Encrypt is a free, automated, and open certificate authority. It is run for the public’s benefit and is operated by a non-profit organization called Internet Security Research Group (ISRG), whose mission is to reduce financial, technological, and education barriers to secure communication over the Internet.
In order to provide SSL certificates to any website who requests one, it hosts an infrastructure that handles certificates requests, and it provides a piece of software (certbot) which proceeds to the creation of these certificates on the server hosting the website. During the creation process there is an exchange that enables Let’s Encrypt to verify that the server requesting the certificates is correctly registered with the identity contained in the certificate. More precisely, this whole process is a fully documented protocol (called ACME), and certbot is only a client for this protocol (there are several other such clients, as you may see here).
How does it work?
Assume that you want to create a certificate for a website at the address
test.example.com. Certbot runs on this machine, and initiates a communication with Let’s Encrypt servers, telling he wants certificates for
test.example.com. Then, these servers initiate a connexion with
test.example.com, using the IP address from public DNS servers. If certbot is really working on this server, it is able to answer correctly the few challenges from Let’s Encrypt, and then is authorized to have his SSL certificates (in fact, signed by Let’s Encrypt).
If someone requests certificates for
test.example.com, but does not possess this server, it will not be able to answer the challenges, and thus Let’s Encrypt will not deliver any certificates.
Now, we briefly describe how to set up Let’s Encrypt certificates on a Debian GNU/Linux, Apache server, in a simple configuration. It should be easily transposable to any other distribution or web server.
Context: consider a Debian server,
test.example.com, with a public address registered in the global DNS system.
First you need to install certbot:
sudo apt update sudo apt install certbot python-certbot-apache
(You should be prompted for your password. You may also install
python-certbot-nginx if you are running Nginx)
Afterwards, we assume there is a running installation of Apache on this system, you simply need to type:
sudo certbot --apache -d test.example.com
(Obviously, you simply need to replace
--nginx if you are running Nginx)
And this is it! You have installed Let’s Encrypt certificates. Your certificates are stored in folder
The files are:
cert.pem: The simple SSL certificate (should not be used in most cases);
chain.pem: SSL chain certificate (should not be used in most cases);
fullchain.pem: The SSL certificate and the chain (this is the file you should use);
privkey.pem: This is your private key (il has never left your server).
In fact these files are (symbolic) links to actual files which are stored in folder
The links (in the live folder) always point to the most recent version in the archive folder.
Using this certbot invocation make it edit your Apache configuration, specifying the location of
privkey.pem, which are your certificate and key files.
SSLCertificateKeyFile /etc/letsencrypt/live/test.example.com/privkey.pem SSLCertificateFile /etc/letsencrypt/live/test.example.com/fullchain.pem
Let’s Encrypt does only sign three months certificates (90 days). The purpose is to limit the effects of compromised certificates. However, it enables simple renewal. In fact you have nothing else to do in order to renew your certificates. In the unlikely event where they are not automatically renewed (1 month before they are obsolete), you simply have to type:
sudo certbot renew
The renewal configuration is stored in the file
To learn more about Let’s Encrypt, we invite you to read our article. We present a couple of tools for advanced configuration, in particular if you are using a reverse proxy (like nginx) for accessing your websites.
Read more on our blog
Let’s Encrypt: Advanced configuration
Feel free to contact us if you have any questions.
About Open Agora
Nuanced and targeted consultations
Open Agora solutions allow you to collect rich opinions and easily reach consensus