13 KiB

Raw Permalink Blame History

title	date	author	template	tags
Sécuriser ses sites web avec Let's Encrypt	2016-01-02	raspbeguy	post	auto-hébergement,http,let's encrypt,nginx,openssl,planet libre,sécurité,serveur,tutoriels,web,www

Bonjour à tous ! Nous allons débuter l'année avec un tutoriel sur la prise en main de Let's Encrypt, l'autorité de certification censée révolutionner l'usage de la technologie SSL par sa facilité d'usage, et qui doit permettre à Madame Michu de sécuriser son petit blog de cuisine traditionnelle en toute simplicité et sans avoir besoin de faire perdre une après-midi à son petit neveux du côté de sa belle-mère, qui se trouve être administrateur système, afin qu'il lui répète une quinzaine de fois les étapes de création et de validation d'un certificat en bonne et due forme. Ah, la famille...

Mais tout d’abord, je vous souhaite à tous une bonne année 211 - 25 ! Au niveau personnel, je vous souhaite tout le bonheur que vous méritez, tant sur le plan professionnel/scolaire qu'avec votre famille/amis/béguin divers. Instruisez-vous, soyez curieux, incitez vos proches à la sagesse, et bien sûr, restez vous-même gentils.

Au niveau citoyen, je souhaite comme toujours une prise de conscience collective sur cette cage en or qu'est devenue aujourd'hui la vie sur les internets, et une plus grande sagesse de nos têtes décideuses (à défaut d'être pensantes) à propos de la réalité numérique, qu'elles n'ont toujours pas bien intégrée.

Enfin, revenons à notre tutoriel. Au cours du mois dernier, vous l'avez peut-être remarqué, le certificat de notre blog (ainsi que les certificats de nos services internes, mais ça c'est nos oignons) ont changé d'autorité de certification. Nous sommes passés d'un certificat Gandi, offert avec notre nom de domaine, à un certificat Let's Encrypt, grâce à l'ouverture de ce service en bêta publique. Pourquoi avons-nous changé ? Et bien, d'abord, depuis le temps que nous vous en parlions, il aurait été ironique que nous n'utilisions pas le système Let's Encrypt. Ensuite, cette manière de procéder n'est pas sans avantages pour un administrateur système, principalement pour les raisons suivantes :

Gain de temps global, même pour la première utilisation ;
Possibilité de créer un seul certificat pour plusieurs domaines ;
Automatisation très poussée des différentes étapes, permettant l'écriture de scripts pour les renouvèlements.

J'avoue qu'avant la bêta publique et la possibilité de mettre vraiment les mains dans le cambouis, je n'avais aucune idée du fonctionnement, même basique, de ce service. Je n'ai même jamais personnellement manifesté d'attirance particulière envers les technologies de sécurité. En fait, son fonctionnement théorique est très simple, et permet même, à mon sens, de se rendre bien compte du processus de certification SSL dans sa globalité.

Principe de la vérification d'identité

Lors de la création d'un certificat, on doit suivre un protocole invariant de l'autorité de certification :

On crée une clef secrète (ou on utilise une clef générée antérieurement).
À partir de cette clef secrète, on génère une demande de certification (contenant une clef publique et des informations sur l'identité de l'entité à certifier).
On soumet cette demande à l'autorité de certification désirée, qui génère et signe un certificat, ce qui dit aux outils des utilisateurs de votre service qu'il s'agit bien de vous, car il fait confiance à l'autorité de certification.

Les deux premières étapes sont instantanées ; cependant, la dernière étape prends traditionnellement plus de temps, car l'autorité de certification doit s'assurer de l'identité du domaine qu'elle doit certifier. Chez les autorités classiques, il s'agit souvent de fournir des pièces d'identités, ou de répondre à un mail auquel seul le possesseur du domaine peut accéder (du type admin@example.com).

Let's Encrypt prends en charge ces 3 étapes (il faut reconnaitre que c'est très facile d'automatiser les 2 premières) en passant par un utilitaire chargé de communiquer avec le serveur de son autorité de certification.

Processus de vérification d'identité

Une fois la clef et la demande de certificat générées, l'exécutable local communique au serveur http un code de vérification à rendre accessible par le serveur de certification.
L'utilitaire demande à l'autorité de certification de procéder à une vérification d'identité en envoyant la demande de certificat et lui communique le code servi par le serveur http à tester.
Le serveur de certification accède au serveur http en utilisant le système DNS
L'autorité de certification accepte l'identité et transfert le certificat.
L'utilitaire met le certificat généré à disposition des services de l’utilisateur.

Ainsi, le processus de création du certificat ne prends en tout et pour tout que quelques dizaines de secondes. Cependant, par cette méthode, on est contraint de mettre en service, au moins temporairement, un service web pour chaque domaine à tester, ce qui est gênant pour des domaines qui ne sont pas destinés à pointer sur un site web.

Configurer son serveur web

Let's Encrypt met à disposition des "extensions" lui permettant de communiquer tout seul au serveur web les informations pour l'étape de la vérification d'identité. Cependant, j'utilise Nginx, et à ce jour seul Apache dispose d'une extension stable. Il existe une extension expérimentale pour Nginx mais je n'ai pas su m'en servir convenablement, ou alors j'ai eu la flemme de comprendre comment elle marchait. De toute façon, selon les retours utilisateurs et les forums, la méthode générique (dite du webroot) est la plus utilisée, c'est donc celle qui sera présentée, et vous verrez, ce ne sera pas bien compliqué.

Tout d'abord, il faut définir le dossier qui sera mis à disposition par le serveur web. Par exemple, pour pouvez créer et choisir l'emplacement /var/www/webrootauth.

Vous devez ensuite modifier la configuration de chaque domaine que vous souhaitez faire certifier. Vous avez le droit à 100 domaines couverts par votre certificat, vous avez donc de la marge, et vous auriez tort de vous priver. Sous Nginx, vous devez ajouter au sein de chaque server block :

location ~ ^/.well-known/acme-challenge(/.*)?$ {
	root /var/www/webrootauth;
	default_type text/plain;
}

Sans oublier de recharger Nginx :

service nginx restart

ou bien, selon votre distribution Linux :

systemctl restart nginx

Pour information, cela demande à Nginx de servir le contenu de /var/www/webrootauth à l'adresse http://example.com/.well-known/acme-challenge/, adresse qui sela utilisée par l'autorité de certification.

Installer l'utilitaire

EDIT : C'était prévisible, maintenant quelques distributions intègrent Let's Encrypt dans leurs dépôts. Cette méthode est donc à privilégier par rapport à la méthode ci dessous.

Il faut maintenant télécharger l'exécutable mis à disposition par Let's Encrypt. Pour cela, vous allez avoir besoin de Git, veillez donc à ce qu'il soit installé sur votre machine.

Devenez super-utilisateur :

sudo su -

Puis clonez le dépôt du projet :

git clone https://github.com/letsencrypt/letsencrypt /root/letsencrypt

Configurer Let's Encrypt

Il est possible d'exécuter Let's Encrypt à la sauvage sans fichier de configuration, uniquement avec des paramètres long comme mon bras. Il est néanmoins plus propre d'écrire son fichier de configuration, cela donne des scripts plus propres et un historique bash plus clair. Et comme ça vous n'avez pas des tonnes de lignes de commandes à retenir en cas de perte de vos scripts :)

Un fichier de configuration Lets Encrypt ressemble à ceci :

rsa-key-size = 4096
server = https://acme-v01.api.letsencrypt.org/directory
email = votreadresse@domaine.truc
authenticator = webroot
webroot-path = /var/www/webrootauth
text = True
renew-by-default = True
agree-tos = True
domains = hashtagueule.fr,mail.hashtagueule.fr,wiki.hashtagueule.fr,mysql.hashtagueule.fr,znc.hashtagueule.fr,ttrss.hashtagueule.fr

Petite explication :

rsa-key-size : la taille de la clef, on l'a mis au maximum, parce qu'on est des gros bourrins. Sachez que la génération d'une clef 4096 bits prends plus de temps, mais elle n'est générée qu'à la première exécution.
server : l'adresse du serveur de certification. Ça ne sert à rien de le changer.
email : l'adresse e-mail de votre compte Let's Encrypt (s'il n'existe pas, il sera créé automatiquement, pas d’inquiétude).
authenticator : la méthode de vérification d'identité, on a dit qu'on choisissait la méthode webroot.
webroot-path : doit correspondre au chemin choisi précédemment.
text : indique que l'on souhaite exécuter l'outil en lignes de commandes, pratique pour les scripts et permet de tout exécuter sans intéraction (un mode pseudo-graphique existe mais n'est pas pratique).
renew-by-default : indique que les certificats existants doivent être renouvelés.
agree-tos : indique que vous acceptez la paperasse lié à l'utilisation des certificats, à lire quelque part sur leur site, mais bon, rien de bien méchant.
domains : là, vous devez indiquer tous les domaines que doit couvrir le certificat qui va être généré, séparés par une virgule.

Vous placerez ce fichier quelque part d'accessible. Par exemple, vous pouvez le placer dans /root/le-config/cli.ini.

Générer ponctuellement le certificat

Tout est en place pour la génération de votre premier certificat, la tension monte, je vous sens tout excité. Allez, lancez-vous, en voiture Simone. Pour générer votre certificat, en tant que super-utilisateur, exécutez la commande suivante :

/root/letsencrypt/letsencrypt-auto certonly --config /root/le-config/cli.ini

Laissez mijoter quelques instants. La première fois, des dépendances nécessaires vont s'installer, il va configurer deux trois trucs, et finalement faire le boulot.

Normalement, à la fin, vous allez avoir un message vous félicitant du succès de l'opération. Bravo, vous avez un certificat Let's Encrypt :)

Vous pourrez ensuite configurer votre serveur web pour utiliser ce certificat. Sous Nginx, vous préciserez dans vos server blocks :

listen 443;
listen [::]:443;
ssl on;
ssl_certificate /etc/letsencrypt/live/hashtagueule.fr/fullchain.pem;
ssl_certificate\_key /etc/letsencrypt/live/hashtagueule.fr/privkey.pem;

Bien sûr, vous remplacerez hashtagueule.fr par le nom de votre domaine principal. Vérifiez en regardant le nom du dossier à cet emplacement.

Vous pouvez ensuite recharger Nginx, et si tout ce passe bien, vous avez un site sécurisé Let's Encrypt.

Renouvellement automatique

Les certificats générés par Let's Encrypt ont une validité de 90 jours. C'est court, et c'est un fil à la patte de devoir tous les 3 mois demander un renouvellement de certificat. Heureusement, il y a Cron.

Cron est un service sur votre machine qui va se charger d'exécuter des tâches à intervalle régulier. Tous ce que vous avez à faire, c'est d'écrire un script à fournir à cron. Ce script ressemblera à ça :

#!/bin/bash

la_cert_dir=/etc/letsencrypt/live/hashtagueule.fr

/root/letsencrypt/letsencrypt-auto certonly --config /root/le-config/cli.ini 1> /dev/null

# nginx
service nginx reload

# Vous pouvez également scripter les opération à suivre
# pour d'autres services, par exemple votre serveur mail.

# Envoi d'un mail de notification à l'administrateur
mail -a "From: Agent de certification Hashtagueule <letsencrypt@hashtagueule.fr>" -a "Content-Type: text/plain; charset=UTF-8" -s "Renouvellement des certificats" votreadresse@domaine.truc << EOF
Bonjour,

Le certificat des services Hashtagueule a été renouvelé et couvre actuellement les domaines suivants :

$(openssl x509 -in /etc/letsencrypt/live/hashtagueule.fr/cert.pem -noout -text | grep DNS | sed 's/, /\n/g' | cut -d: -f2)

Dates de validité :

$(openssl x509 -in /etc/letsencrypt/live/hashtagueule.fr/cert.pem -dates -noout | cut -d= -f2)

Pour rappel, les certificats délivrés par Let's Encrypt ont toujours une validité de 3 mois. Tâchez donc de définir une période de renouvellement inférieure à cette durée.
Il est à noter également que l'autorité Let's Encrypt ne délivre qu'un maximum de 5 certificats pour le même domaine par semaine. Renouvelez donc avec précaution.

Bonne journée.
EOF

Ce script va renouveler le certificat et vous envoyer un mail de notification comportant les nouvelles dates de validité et les domaines concernés. Classe, non ?

Il vous reste à rendre ce script exécutable et à le placer dans /etc/cron.monthly afin de l'exécuter tous les mois.

Limitations

Comme indiqué précédemment, les domaines à certifier doivent être servis par un serveur web, au moins pour la durée de la vérification d'identité.

D'autre part, évitez de générer trop de certificats, car vous êtes limités à 5 renouvèlements par semaine. En régime permanent ça ne pose pas de problème, mais je me suis déjà fait avoir lors de mes tests...

Voilà, j'espère que ce tutoriel vous aura été utile, et j'espère aussi voir fleurir une multitude de sites sécurisés.

Désormais, vous n'avez plus aucune excuse.

13 KiB Raw Permalink Blame History Unescape Escape