As the web moves towards a “secure by default” approach, enabling HTTPS on your website is becoming more and more important. I’ve spent the last few weeks updating the websites I manage to run HTTPS, including some that run in docker. As some readers may have noticed, I have also switched the fullcirclemagazine.org website over to HTTPS. The reason for this is simple - Google (and others) are encouraging the use of HTTPS by clearly denoting (with a green padlock) encryption on websites. This month’s article will therefore be dedicated to what HTTPS is, how to get set up with Let’s Encrypt, and how to combine it with docker.
Comme le Web évolue vers une approche « sécurisée par défaut », l'activation du HTTPS sur votre site Web devient de plus en plus importante. J'ai passé ces dernières semaines à mettre à jour les sites Web que je gère pour qu'il fassent tourner HTTPS, y compris certains qui tournent sous Docker. Comme certains lecteurs pourraient l'avoir remarqué, j'ai aussi modifié le site Web fullcirclemagazine.org en HTTPS. La raison en est simple : Google (et d'autres) encouragent l'utilisation de HTTPS en indiquant clairement (avec un cadenas vert) le cryptage des sites Web. L'article de ce mois sera donc dédié à ce qu'est HTTPS, comment l'installer avec Let's Encrypt et comment le marier à Docker.
What is HTTPS and Let’s Encrypt? HTTPS helps to protect private data when logging in, when using HTML forms, or otherwise when sharing information with a website. The information is secured via encryption, and can also prevent man-in-the-middle attacks (where another device intercepts your packets). Depending on your host, it may be automatically configured, or an option you can pay for. Previously, SSL certificates were issued only by certain companies (at cost), and self-signed certificates were not considered secure. That changed recently with Let’s Encrypt, which will create secure, trusted certificates for free. The main difference between paid certificates and free ones through Let’s Encrypt are the duration. Certificates from Let’s Encrypt expire after 90 days - meaning you need to actively renew them more often than paid certificates. However, this can be done with a helper tool (I use ‘certbot’), and, combined with crontab, will keep the certificates updated without much effort.
Qu'est-ce que HTTPS et Let's Encrypt ?
HTTPS aide à protéger les données privées quand on s'identifie, quand on utilise des formulaires HTML ou, autrement, quand on partage des informations sur un site Web. L'information est sécurisée via un cryptage et peut aussi prévenir les attaques du genre homme-au-milieu (man-in-the-middle - quand un autre équipement intercepte vos paquets). Selon votre hôte, il peut être configuré automatiquement ou une option pour laquelle il faut payer. Avant, les certificats SSL étaient émis seulement par quelques sociétés (en payant) et les certificats auto-signés n'étaient pas considérés comme sûrs.
Ça a changé récemment avec Let's Encrypt, qui crée des certificats sûrs et fiables gratuitement. La principale différence entre les certificats payants et ceux gratuits par l'intermédiaire de Let's Encrypt est la durée. Les certificats de Let's Encrypt expirent au bout de 90 jours, ce qui signifie que vous devez vous-même les renouveler plus souvent que les certificats payants. Cependant, ceci peut être fait avec un outil d'aide (j'utilise « certbot ») et, en combinaison avec crontab, les certificats seront maintenus à jour sans grand effort.
What is Docker? Docker is a system for running services in virtual containers - and is built upon the existing Linux kernel. This means that it is faster, and requires less disk and RAM space than full virtualized environments (such as Vagrant). You can use it to run any number of systems, and multiple containers can communicate with each other via a private network.
qu'est-ce que Docker ?
Docker est un système pour faire tourner des services dans des conteneurs virtuels, et il est construit sur le noyau Linux existant, ce qui signifie qu'il est plus rapide et qu'il demande moins d'espace disque et RAM que des environnements complètement virtualisés (comme Vagrant). Vous pouvez l'utiliser pour faire tourner un nombre quelconque de systèmes, et des conteneurs multiples peuvent communiquer entre eux via un réseau privé.
Prerequisites In my case, the services I worked with covered 3 containers. One running jwilder’s nginx-proxy image, one running a basic nginx image, and one running a basic apache image. The basic nginx and apache images were linked together as a LEAMP server (an Apache server behind an Nginx server, where Nginx covers static files, and PHP files are handled by Apache). Nginx-proxy is an image that automatically directs and manages the traffic to various other containers (so the URLs lead to the correct container).
Prérequis
Dans mon cas, les services avec lesquels je travaillais couvraient 3 conteneurs. L'un faisait tourner une image de nginx-proxy de jwilder, un autre, une image d'un nginx de base et un autre, une image d'un apache de base. Les images de base de nginx et apache étaient liées entre elles sous forme de serveur LEAMP (un serveur Apache derrière un serveur Nginx, où Nginx s'occupe des fichiers statiques et Apache gère les fichiers PHP).
Nginx-proxy est une image qui dirige et gère automatiquement le trafic vers divers autres conteneurs (de sorte que les URL conduisent vers le bon conteneur).
Where to start? My original research didn’t indicate too many posts on this particular topic. There were plenty on setting up nginx or apache to serve HTTPS sites. However, the complication comes from using nginx-proxy. As the traffic is technically forwarded between 3 containers, I originally assumed that I would need to configure SSH on both the Nginx-proxy and the Nginx containers. Fortunately, after some trial and error, it turns out that you only need to configure HTTPS on Nginx-proxy, and the settings are then carried through.
Par où commencer ?
Ma première recherche ne m'a pas donné trop de messages sur ce sujet précis. Il y en avait plein sur le paramétrage de nginx et apache pour desservir des sites HTTPS. Cependant, la complication vient de l'utilisation de nginx-proxy. Comme le trafic est techniquement transmis à 3 conteneurs, j'ai présumé au début que j'aurais besoin de configurer SSH sur les deux conteneurs Nginx-proxy et Nginx.
Heureusement, après un peu de tâtonnement, il s'avère que vous n'avez besoin de configurer HTTPS que sur Nginx-proxy et que les paramètres sont ensuite partagés.
Create Certificate To do this, you’ll need to install certbot, which depends on your server’s OS and version. For most Ubuntu versions, you’ll need to add the certbot/certbot ppa (instructions here: https://certbot.eff.org/all-instructions/). Once you’ve installed certbot, you’ll want to create your certificate. I did this using the certonly command, as I did not want certbot to attempt to autoconfigure anything. To configure the certificate, run the following command: certbot certonly Then answer the questions (you will need to point it to the actual webroot of your website that is publically accessible, otherwise Let’s Encrypt cannot confirm you own the domain and the certificate is not created). Once the certificate is created, it will be stored in /etc/letsencrypt/live/<URL>/fullchain.pem and /etc/letsencrypt/live/<URL>/privkey.pem
Créer un certificat
Pour ce faire, vous devez installer certbot, ce qui dépend de l'OS de votre serveur et de sa version. Pour la plupart des versions d'Ubuntu, vous devrez ajouter le ppa certbot/certbot (instructions ici : https://certbot.eff.org/all-instructions/).
Une fois certbot installé, vous pourrez créer votre certificat. Je l'ai fait en utilisant la commande certonly, car je ne veux pas que certbot tente d'auto-configurer quoi que ce soit. Pour configurer le certificat, lancez la commande suivante :
certbot certonly
Puis répondez aux questions (vous aurez besoin de le faire pointer sur la vraie racine de votre site Web qui est accessible publiquement, autrement Let's Encrypt ne peut pas certifier que le domaine vous appartient et le certificat n'est pas créé). Une fois le certificat créé, il sera stocké dans /etc/letsencrypt/live/<URL>/fullchain.pem et /etc/letsencrypt/live/<URL>/privkey.pem.
Create folder for docker volume While you can link the folder from letsencrypt up with docker, I would recommend creating a new folder that you can more easily access (in your user’s home folder, for example). A command that works for this would be: mkdir -p ~/nginxproxy-certs cp /etc/letsencrypt/live/<URL>/{fullchain,privkey}.pem ~/nginxproxy-certs/ If you want nginx-proxy to automatically apply the certificates, you’ll need to have them saved in the style of <URL>.crt and <URL>.key. These can be symbolic links, if you want to create subfolders in nginxproxy-certs for each URL. However, the links must be at the top level of the directory (directly in nginxproxy-certs).
Créer un dossier pour le volume docker
Alors que vous pouvez relier le dossier de letsencrypt à docker, je vous recommanderais de créer un nouveau dossier auquel vous pourrez facilement accéder (dans votre répertoire home, par exemple).
Une commande qui fonctionne pour cela serait :
mkdir -p ~/nginxproxy-certs
cp /etc/letsencrypt/live/<URL>/{fullchain,privkey}.pem ~/nginxproxy-certs/
Si vous voulez que nginx-proxy utilise automatiquement les certificats, vous devrez les avoir stockés dans le style de <URL>.crt et <URL>.key. Ils peuvent être des liens symboliques, si vous voulez créer un sous-dossier dans nginxproxy-certs pour chaque URL. Cependant, les liens doivent être au plus haut niveau du répertoire (directement dans nginxproxy-certs).
Link Certificate to Nginx-Proxy To supply the certificates to the image, you can use the following command (taken from the official nginx-proxy): docker run -d -p 80:80 -p 443:443 -v /path/to/certs:/etc/nginx/certs -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy Replace the /path/to/certs with the actual folder you placed the certificate in. If you set the names of the files properly, you will just need to make sure the VIRTUAL_HOST line is correct for each docker container. If you prefer more control (or have one certificate for multiple domains), you can instead set the CERT_NAME variable in the container’s environment. If your files are called example.crt and example.key, the CERT_NAME would then just read ‘example’. For ease of use and managing the variables, I’d recommend using docker-compose, as opposed to doing it directly with docker run.
Relier le certificat à Nginx-proxy
Pour fournir les certificats à une image, vous pouvez utiliser la commande suivante (prise sur le site officiel de nginx-proxy) :
docker run -d -p 80:80 -p 443:443 -v /path/to/certs:/etc/nginx/certs -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
Remplacez /path/to/certs par le vrai dossier dans lequel vous avez placé le certificat. Si vous avez indiqué correctement le nom des fichiers, vous aurez juste à vous assurer que la ligne VIRTUAL_HOST est correcte pour chaque conteneur docker.
Si vous préférez avoir plus de contrôle (ou si vous avez un seul certificat pour plusieurs domaines), vous pouvez, à la place, paramétrer la variable CERT_NAME dans l'environnement du conteneur. Si vos fichiers s'appellent example.crt et example.key, « example » sera juste lu dans CERT_NAME.
Pour une utilisation et une gestion facilitée des variables, je recommanderais l'utilisation de docker-compose, plutôt que de le faire directement au lancement de docker.
Possible issues I ran into an issue where I had mistakenly linked the cert file in place of the private key, which resulted in nginx -s reload failing on nginx-proxy. There were no obvious errors, but it resulted in the port 443 being closed, and the connection being refused. So if nginx-proxy isn’t working properly for you, make sure you are linking the correct folder, and have read/write permissions; then run nginx -s reload manually to see if there are any errors.
Problèmes possibles
J'ai rencontré un problème quand j'ai relié par erreur le fichier cert au lieu de la clé privée, ce qui a entraîné le non-fonctionnement de nginx -s reload sur nginx-proxy. Il n'y avait pas d'erreurs évidentes, mais ça avait pour résultat que le port 443 était fermé et que la connexion était refusée. Aussi, si nginx-proxy ne fonctionne pas pour vous, assurez-vous que vous êtes relié au bon dossier et que vous avez les permissions en lecture/écriture ; ensuite, lancez nginx -s reload manuellement pour voir s'il n'y a pas d'erreur.
Where can I find more information on Docker? The docker hub pages for the various images typically tell you how to configure them. If you read the documentation page on docker-compose, you’ll also be able to use that without issue. If you want to read my article on Docker, you can find it in FCM#107. I hope this article proves useful for anyone who, like me, was making the process much more complicated than necessary, or was running into a similar issue as I did. If you have any questions, comments, or article suggestions, feel free to contact me at lswest34+fcm@gmail.com.
Où puis-je trouver plus d'information sur Docker ?
Les pages hub de Docker pour les différentes images vous disent typiquement comment les configurer. Si vous lisez la page de documentation de docker-compose, vous pourrez l'utiliser aussi sans problème. Si vous voulez lire mon article sur Docker, vous pouvez le trouver dans le n° 107 du FCM.
J'espère que cet article se montrera utile à toute personne qui, comme moi, rend les processus plus compliqués que nécessaire, ou qui tombe sur un problème comme le mien. Si vous avez une question, un commentaire ou un suggestion d'article, n'hésitez pas à me contacter par courriel à lswest34+fcm@gmail.com.