Let's encrypt !

Monday, 08 January 2018
|
Écrit par
Grégory Soutadé

Logo Let's encrypt

Au revoir 2017, bonjour 2018 ! Alors que l'actualité brûlante du moment tourne autour de la faille de sécurité trouvées sur différents processeurs supportant l'exécution spéculative (faille non triviale à exploiter), j'ai pour ma part choisi de passer à Let's Encrypt. Il s'agit d'une organisation à but non lucratif dont l'objectif est de promouvoir l'utilisation de connexions sécurisées (SSL/TLS) sur internet. Pour ce faire, elle propose la génération gratuite (et scriptée) de certificats pour le protocole HTTPS. Elle trouve de plus en plus les faveurs des webmasters, surtout quand on sait qu'un certificat coûte entre 15€ et plusieurs milliers d'euros par an (avec des garanties, tout ça, tout ça).

Leurs certificats sont déployés depuis plus de deux ans maintenant et il faut dire que ça marche plutôt bien ! Auparavant, j'utilisais ma propre autorité de certification, ce qui permet de contrôler finement les paramètres du certificat final, vérifier que l'on n'est pas attaqué... Mais il faut reconnaître que pour la navigation courante et surtout pour gPass, avoir un certificat reconnu de base est devenu une nécessitée.

Surtout que let's encrypt fourni l'utilitaire certbot (disponible dans les paquets Debian) qui s'occupe de (re-)générer, valider, configurer automatiquement tout ce qu'il faut. Il n'y a qu'à renseigner une adresse mail valide ainsi que la liste des domaines concernés.

J'ai eu deux erreurs lors de cette procédure. La première :

Domain: denote.soutade.fr
Type:   unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge.
Requested
605840d8f5902f3f5f9b465e90fefda9.5e9055daac5e4439a0d768344e093378.acme.invalid
from 89.95.86.199:443. Received 1 certificate(s), first certificate
had names
"58d2ce91621ca3bc9dad2ae778ba8110.6f005c32f7a4345e14b2120f34d7e6c7.acme.invalid,
dummy"

Et la seconde concernant le nom de domaine teamazurevasion.fr que j'héberge également sur le même serveur (le DNS pointe vers soutade.fr, ça ne plaît pas trop au robot).

Domain: teamazurevasion.fr
Type:   unknownHost
Detail: No valid IP addresses found for teamazurevasion.fr

Il faut dire que ma configuration est un peu particulière puisque j'ai un premier serveur web/proxy (tournant sous nginx) qui s'occupe des sites statiques ainsi que de la liaison sécurisée (TLS). Il communique par socket avec un second serveur (Apache) pour toute la partie dynamique (PHP, Django). La solution consiste donc à stopper le service nginx et utiliser le mode standalone (une fois le port 443 libéré) pour (re-)générer mes certificats :

service nginx stop
certbot certonly --standalone --expand -d soutade.fr -d www.soutade.fr -d blog.soutade.fr
-d demo-gpass.soutade.fr -d denote.soutade.fr -d dynastie.soutade.fr -d gpass.soutade.fr
-d gpass-demo.soutade.fr -d iwla.soutade.fr -d music.soutade.fr
service nginx start

Une petite entrée de plus dans /etc/crontab et voilà, je n'ai plus à me soucier de la gestion de mes certificats ! Bon, j'aurais également pu déployer des scripts dans /etc/letsencrypt/renewal-hooks/.

J'attendais avec impatiente l'arrivée des wildcards (*.nom.de.domaine) qui devaient être intégrés à partir du 4 janvier, mais étant donné que certbot ne génère qu'un seul fichier certificat (embarquant tous les noms de domaines), j'ai finalement sauté le pas. Bien sûr, un wildcard sera plus pratique pour tout ce qui n'est pas configuré explicitement au niveau de mes serveurs webs. Activation prévue fin février, attendons de voir.

Auteur :


e-mail* :


Le commentaire :




* Seulement pour être notifié d'une réponse à cet article
* Only for email notification