URL: https://linuxfr.org/users/oyp/journaux/let-s-encrypt-en-beta-petit-retour-d-experience Title: Let’s Encrypt en bêta : petit retour d’expérience Authors: ɹǝıʌıʃO Date: 2015年11月17日T23:00:35+01:00 License: CC By-SA Tags: letsencrypt, ssl, certificat, debian, chiffrement et tls Score: 51 Comment vas-tu yau de nal, Je t’écris pour te donner des nouvelles de [Let’s Encrypt](https://letsencrypt.org/), cette nouvelle autorité de certification sponsorisée, entre autres, par Mozilla, l’Electronic Frontier Foundation, Cisco, Akamai... qui fournit des certificats SSL gratuits. Il en a déjà été question sur DLFP, pour annoncer [sa création](https://linuxfr.org/users/claudex/journaux/encryptons) et [son premier certificat](https://linuxfr.org/users/saintgermain/journaux/le-premier-certificat-ssl-de-let-s-encrypt). Le projet est actuellement au stade de bêta sur invitation. Il faut remplir [un formulaire](https://docs.google.com/forms/d/15Ucm4A20y2rf9gySCTXD6yoLG6Tba7AwYgglV7CKHmM/viewform) et attendre quelques jours que les (sous-)domaines demandés soient passés en liste blanche pour pouvoir utiliser le service. On approche de la fin de cette période, puisque la phase de bêta publique est prévue pour le 3 décembre. Le nombre de certificats que l’on peut demander est actuellement limité à 10 par jour et par IP, et il y a aussi une limite (peu claire mais pas gênante pour tester) sur le nombre de certificats par domaine. L’idée de Let’s Encrypt est que le chiffrement devrait être généralisé, et donc gratuit et facile à mettre en place. Pour cela, un [outil](https://github.com/letsencrypt/letsencrypt) en Python est mis à disposition sous licence Apache afin de pouvoir obtenir un certificat automatiquement. Presque. Bon, il faut bien dire que la peinture n’est pas encore sèche, que la [documentation](https://letsencrypt.readthedocs.org/en/latest/) laisse à désirer et que les sites web ne sont pas forcément à jour, mais la bonne nouvelle est que globalement, ça marche. En gros, on télécharge l’outil en clonant le dépôt git, on se crée un fichier de configuration comme indiqué dans la doc, et on lance la commande suivante : `./letsencrypt-auto certonly -a webroot --webroot-path /var/www/example -d example.com -d www.example.com --server https://acme-v01.api.letsencrypt.org/directory --agree-dev-preview ` Je n’ai eu aucun problème pour l’exécuter, mais je suis sous Debian 8, qui est explicitement prise en charge. Je ne sais pas si les utilisateurs d’autres distributions auront autant de chance. Cet exemple montre que les certificats multidomaines (utilisant SAN) sont pris en charge. C’est intéressant dans le cas (fréquent) ci-dessus, pour avoir un même certificat pour example.com et www.example.com, mais ça peut aussi être pratique si on a example.com, fr.example.com, de.example.com pour une application web localisée en plusieurs langues. Cependant, les certificats _wildcard_ (*.example.com) ne sont pas pris en charge, et ont fort peu de chances de l’être, d’après quelques discussions sur le projet. Les certificats sont de bonne facture, puisqu’ils utilisent l’algorithme SHA-256 (donc SHA-2) et, si on le demande dans le fichier de configuration, une clé RSA de 4096 bits, ce qui, après un peu de configuration de nginx, permet à mon serveur perso d’afficher un joli A+ de [SSL Labs](https://www.ssllabs.com/). Leur durée est de 90 jours, ce qui semble peu, mais c’est fait exprès, d’abord parce qu’une durée courte réduit les dégâts en cas de vol d’une clé privée, ensuite parce que le renouvellement est censé être automatique : on met en place une tâche cron qui s’exécute une fois par mois, et on n’y pense plus. Pour entrer un peu dans le détail du fonctionnement, l’outil letsencrypt-auto se charge de toutes les opérations : création, renouvellement, révocation de certificat. Il est censé pouvoir configurer automatiquement Apache et nginx, ce que je n’ai pas testé, mais franchement, ce n’est vraiment pas nécessaire. En mode certonly (télécharger le certificat seulement), il dépose le certificat dans /etc/letsencrypt/live/example.com/ où on trouve, au format pem, le certificat, la chaine complète telle que demandée par Apache (sans le certificat lui-même) et nginx (avec), et la clé privée. Lorsqu’un certificat est renouvelé, les nouveaux vont dans live et les anciens dans /etc/letsencrypt/archive. Il suffit donc de configurer nginx comme ceci :` ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;` et c’est tout. Lors d’une création de certificat, letsencrypt-auto doit permettre au serveur de Let’s Encrypt de vérifier que le serveur d’où provient la requête contrôle le (sous)-domaine concerné. Pour cela, il y a actuellement deux méthodes : - avec un serveur ad hoc sur le port 443, ce qui peut demander d’arrêter le serveur web (c’est dommage), - en déposant un fichier à la racine, avec l’inconvénient que si on demande un multi-domaine, ce n’est possible que si tous les domaines partagent une même racine. Ce n’est pas grave dans la mesure où il est (censé être) facile d’automatiser la création de certificats sans limite, donc le multi-domaine n’est pas si important. Censé, parce qu’en plus des limites en phase de bêta, l’outil a encore quelques bugs gênants. Par exemple, ./letsencrypt-auto fonctionne, mais pas /home/toto/letsencrypt-auto. Ça fait un peu tache. D’autre part, si on a bien créé son fichier de configuration, après la première exécution, on peut supposer qu’il ne demande plus de confirmation... enfin, on espère. Ça reste une bêta, il ne faut pas perdre ça de vue. En tous cas, je n’hésiterai plus à organiser mon serveur en sous-domaines et à les servir tous en https, maintenant que c’est gratuit. Et c’est bien là le but de l’opération.

AltStyle によって変換されたページ (->オリジナル) /