Munin, le monitoring des dieux
Certains connaissent Munin, le corbeau de la mythologie nordique. C'est en l'occurrence un lointain cousin que vous allez découvrir dans cet article : L'outil de monitoring Munin.
Sommaire
Comme nous avons pu le voir dans la première partie de cet article consacré au HTTPS, la sécurisation de la communication dans le monde du web est primordiale. Cette seconde partie est donc logiquement dédiée à sa mise en pratique, pour montrer qu'il est très facile de déployer des certificats gratuits, valables 90 jours et délivrés par une autorité certifiée. Pour ce faire, nous utiliserons Docker, Certbot et Nginx sur un serveur Linux. Bien que cet article ne traite pas des autres serveurs web (comme Apache par exemple), il est bien sûr tout à fait possible de mettre en place le HTTPS sur ceux-la aussi.
Nous allons d'abord utiliser le conteneur Docker officiel de Certbot pour récupérer un certificat TLS pour notre sous-domaine à sécuriser :
docker run -it --rm --name certbot -p 80:80 -p 443:443 -v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" certbot/certbot certonly --standalone --email "user@example.com" -d "tls.example.com"
Cette commande va donc lancer le conteneur de l'application Certbot. Voyons quels sont les paramètres utilisés ici, en commençant par ceux passés à Docker :
-it
indique à Docker que nous voulons avoir la possibilité d'interagir avec l'application. Vous aurez en effet sûrement à accepter les conditions d'utilisation de Certbot lors de la première utilisation.--rm
supprimera le conteneur une fois son travail terminé, sans toutefois supprimer les certificats récupérés bien sûr.-p 80:80 -p 443:443
expose les ports HTTP (80) et HTTPS (443) du conteneur, afin qu'il puisse être contacté par Let's Encrypt, qui vérifiera ainsi que vous êtes bien le propriétaire du serveur.-v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt
expose au conteneur les dossiers nécessaires à Certbot pour stocker de manière persistante les certificats sur le serveur. Sans ces paramètres, les certificats seraient simplement détruits en même temps que le conteneur à la fin de l'exécution.certbot/certbot
indique à Docker quel conteneur lancer, ici le conteneur officiel de Certbot.Les paramètres suivants sont ceux passés directement à Certbot :
certonly
indique à Certbot que nous voulons simplement récupérer un certificat.--standalone
lance l'application en mode standalone, c'est à dire avec son propre serveur web (d'où la nécessité de passer les ports HTTP(S) au conteneur, comme vu plus haut).--email
permet à Let's Encrypt d'avoir un point de contact avec le détenteur du certificat et ainsi lui envoyer un email quand la date d'expiration du certificat approche.-d
indique enfin le nom de domaine ou le sous-domaine concerné par le certificat. Il peut être intéressant de noter que vous pouvez indiquer plusieurs options "-d nom_de_domaine" ici, si vous souhaitez avoir un seul certificat pour plusieurs noms de domaine. Le certificat en question portera alors le nom du premier domaine passé en paramètre.Une fois la commande exécutée, si tout s'est bien déroulé, vous trouverez le certificat dans le dossier "/etc/letsencrypt/live/".
Sachez que vous pouvez aussi récupérer un certificat wildcard, gérant tous les sous-domaines d'un nom de domaine. Dans notre exemple, ce "super-certificat" est récupérable en passant "*.example.com" à l'option "-d" de Certbot. Pour ce faire, le DNS de "example.com" doit bien entendu pointer sur votre serveur.
Cette étape est des plus simples, il suffit de passer l'instruction "renew" à Certbot :
docker run -it --rm --name certbot -p 80:80 -p 443:443 -v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" certbot/certbot renew
On pourra noter la ressemblance importante avec la commande précédente. Le seul changement ici est donc l'instruction "renew" passée à Certbot, qui va donc se charger de vérifier pour chaque certificat stocké si la date d'expiration approche (moins de 10 jours par défaut) et les renouveler si besoin.
Maintenant que notre certificat est récupéré, voyons ce que nous avons à mettre en place au niveau de Nginx pour utiliser le HTTPS au travers de cet exemple de configuration commenté :
server {
listen 443 ssl; # Port HTTPS
server_name tls.example.com; # Nom de domaine concerné par ce bloc de config
ssl_certificate /etc/letsencrypt/live/tls.example.com/fullchain.pem; # Localisation de certifcat
ssl_certificate_key /etc/letsencrypt/live/tls.example.com/privkey.pem; # Localisation de la clef
ssl_protocols TLSv1.2; # Protocole SSL/TLS autorisé
ssl_prefer_server_ciphers on; # Activation du chiffrement coté serveur
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; # Type de chiffrement
root /www/;
}
server {
listen 80; # Port HTTP
server_name tls.example.com; # Nom de domaine concerné par ce bloc de config
return 301 https://$host$request_uri; # Redirection automatique sur le HTTPS
}
Nous avons donc pu voir dans cet article comment mettre en place facilement le HTTPS avec Docker, Certbot et Nginx. Si vous souhaitez approfondir le sujet, n'hésitez pas à passer sur la documentation détaillée de la configuration TLS de Nginx.
Auteur(s)
Jérémy Bernard
Mainly JavaScript and backend stuff.
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
Certains connaissent Munin, le corbeau de la mythologie nordique. C'est en l'occurrence un lointain cousin que vous allez découvrir dans cet article : L'outil de monitoring Munin.
Nous étions plusieurs astronautes de la galaxie Eleven Labs à se rendre le 5 décembre dernier à l'Agile Tour organisé par Microsoft dans ses propres locaux.
Le HTTPS, pourquoi et comment le mettre en place.