Before we get into the cdist type for Let's Encrypt talk, a small announcement: we have received many requests from our readers to put a visible RSS feed link on our blog. So we did it, you can find the new icon below this post next to our twitter, linkedin and github icons. Thanks everybody for the support. :)
What are SSL/TLS certificates for?
In the early years of the World Wide Web, there was only HTTP (HyperText Transfer Protocol) for receiving HTML websites. The protocol was mainly responsible for running client-server talking. Back in those days the general security on web was not regarded as a critical issue yet, thus HTTP was not encrypted. But since then the internet grew only bigger and bigger, and so did its security concerns. People started to share information with websites more than ever. Now we use passwords nearly everywhere, and we do everything on the web, including online banking.
With the increase of information exchange on the net, demand for security became higher. The previously non-encrypted HTTP got an encryption update: HTTPS (HyperText Transfer Protocol Secure).
The main difference is that now all communication between server and client is encrypted. But there came this question: How do we know, if the server is trustworthy?
This question was answered by creating Certificate Authorities (CA) trusted by most people. Now the process for the webserver admins is not only to create certificates and implement them inside the webservers, but also to ensure that their certificates get signed by a CA. Sort of a chain of trust it is. If the CA signs a certificate, this newly-signed certificate is trusted by the CA, and if people trusted the CA they would feel safe enough to trust this newly-signed certificate.
What is Let’s Encrypt?
HTTPS used to be mostly designated for communication which had to be encrypted, like logins. Then more and more people started to want HTTPS everywhere. But to obtain a well-signed certificate, it took a lot of effort, time and knowledge.
Let’s Encrypt is a CA which fixed exactly this issue by designing this process as automated as possible. (Yeah! Geeks love automation.) It only takes a small webserver, some webspace and correct DNS entries. There is also a binary for this purpose called Certbot.
Certbot simply creates the request for certificates signed by Let’s Encrypt. The request gets processed by Let’s Encrypt, which then tries to connect and access the server with the requested DNS name. If everything goes well, a signed certificate is placed on the webserver. The certificate itself is valid for 90 days. This means after 90 days, a new certificate has to be issued. No worries though, this process is well automated with Certbot as well. A cronjob checking the certificate validity and automatically starting the request process can be set up very fast.
What does the cdist type do?
We here at ungleich try to provide all our websites via HTTPS. Therefore we need several signed certificates. Since we are all geeks here, we don’t like to do the same steps over and over again. What we like to do is creating new cdist types for taking over this repetition.
To get a certificate signed by Let’s Encrypt, you need to do few configurations. First, install a webserver (e.g. nginx) and there should be a simple configuration available, which allows Let’s Encrypt to call your server back when you request a certificate. Second, your server needs to have correct DNS entries, otherwise the process will fail. For the second part, we already have everything in cdist. But for the first part, we had to create a new type. This is how a type with the self-explaining name was born: __ungleich_http_server_ssl_redirect_letsencrypt.
This type simply installs the nginx package and creates the correct server config (on port 80 => HTTP) for Certbot to work properly. And it directly redirects everything else to HTTPS. This means: every other request on HTTP which is not from Let’s Encrypt will automatically be redirected to use HTTPS instead.
The type only requires one parameter, the “webroot”, to be given. The webroot is the small webspace location where Let’s Encrypt will access.
How to embed this type into other types
With the two types:
- __ungleich_http_server_ssl_redirect_letsencrypt
- __letsencrypt_cert
It is possible to have a fully configured HTTPS webservice managed by cdist.
Here's one simple sample cdist manifest on how to use the types correctly*:
__ungleich_http_server_ssl_redirect_letsencrypt test.ungleich.ch \
--webroot /var/www
require=”__ungleich_http_server_ssl_redirect_letsencrypt/test.ungleich.ch” \
__letsencrypt_cert --admin-email technik@ungleich.ch \
--webroot /var/www test.ungleich.ch
In addition, the following type could be used to create a HTTPS nginx app proxy: “__ungleich_nginx_app_proxy”
* the DNS entry for test.ungleich.ch has to be applied already in the DNS server
HTTPS is the future because of many reasons. Transport encryption is becoming more and more important, even for static content. It is not only more secure, but nowadays it is required by most browsers. Plus, it is faster than HTTP in most cases.
So, start using SSL and obtain your signed certificate from the Let's Encrypt Certificate Authority. Of course, if you haven't done it yet.
To learn more about our configuration management tool cdist, more infos are here. You can also join our chat to talk about cdist, it's open for everybody.