On m’avait fait remarquer lors de la sortie de l’article que sur debian 8 le paquet certbot remplace le client let’s encrypt. Je n’ai pas corrigé ce post comme il est écrit pour debian 7. Mais du coup, comme tout vient à point à qui sait attendre, atomit.fr a écrit un article très complet sur le sujet avec NginX. Il complète très bien cet article. Et c’est par ici que ça se passe : Atomit.fr
Salut à tous, aujourd’hui on se pencher sur Let’s Encrypt, et plus particulièrement comment s’en servir avec apache2 et Debian. Si vous ne connaissez pas Let’s Encrypt c’est que vous n’êtes pas sortie de votre grotte depuis au moins un an ! Et comme un bon exemple vaut mieux qu’un long discours, pour faire ce tutoriel j’ai enrôlé le site geekeries.org dans cet article.
Let’s Encrypt ?
Une infrastructure PKI
Comme d’habitude pour commencer, je vous invite à faire un tour sur le site du projet (et sa page Wikipédia). Ce projet date de 2014 et a ouvert en bêta fin 2015, c’est tout simplement une PKI gratuite et open-source. Depuis le début du projet le gros atout de Let’s Encrypt, c’est ses sponsors. On retrouve quasiment tous les grands noms d’internet, de Google à OVH en passant par Mozilla et Free qui ont donnés une crédibilité et une visibilité très forte au projet. Comme n’importe quelle PKI, Let’s Encrypt délivre des certificats numériques, et gère leurs cycle de vie. Je ne vous fais pas un cours sur les certificats SSL, ça mérite plusieurs articles dédiés (et il y a déjà plein de cours de crypto sur le net).
Surtout, le projet cherche à généraliser l’utilisation de connexions sécurisées sur l’internet, notamment en rendant gratuit la délivrance du certificat. Car, jusqu’à Let’s Encrypt, un certificat SSL commercial coûtait (et coûte encore) entre 50 et 300€ selon l’autorité et la version choisit. Avec Let’s Encrypt, c’est zéro.
Au passage, des concurrents de Let’s Encrypt comme StartSSL délivrent aussi et depuis plusieurs années des certificats gratuits. En écrivant cet article, je me rends compte que pas mal de PKI commerciale ont dû s’aligner et proposent désormais des certificats gratuits ou en mode « free-trial » (comodo par exemple).
Autant vous dire que Let’s Encrypt envoi du lourd et que les services de renseignements qui sniffent les réseaux ne sont pas enchanté par l’idée. Car l’objectif avoué c’est bien de proposer aux admins de pouvoir chiffrer au maximum les communications vers leurs sites, et gratuitement s’il vous plait.
Tutorial, Let’s Encrypt un site dans Apache2 !
Un paquet Debian est en cours de construction.Bientôt vous n’aurez plus qu’à faire ‘apt-get install letsencrypt’ pour l’installer. Mais il n’est pas disponible au moment où j’écris ces lignes.
Installation
En attendant, on va donc partir des sources que l »on va cloner (git) dans /opt :
Et voilà, vu que le projet est majoritairement écrit en python et dans des langages interprété. Aussi, vous n’avez pas besoin de compiler les sources. Vous pouvez mettre à jour Let’s Encrypt à l’aide de la commande ‘git pull’, exécutée dans /opt/letsencrypt.
Mettre en place une version initiale HTTPS du site
https
A ce moment, pour que Let’s Encrypt fonctionne, il faut déjà avoir une version HTTPS de votre site configurée. C’est un peu le serpent qui se mord la queue puisque c’est ce qu’on veut faire avec Let’s Encrypt… Sauf que Let’s Encrypt ne contrôle pas la configuration SSL en place, seulement que le HTTPS fonctionne. Ça peut déjà être le cas si vous utilisiez un certificat payant ou si vous aviez mis en place un auto-signé. Notez qu’il existe d’autres options d’enrôlement pour éviter cette étape, mais comme c’est la plus simple, je vous donne une config de base avec un auto-signé.
Générer un certificat auto-signé et sa clé privée associée :
Vérifier votre configuration de Firewall (sur le 443) si besoin, et vous devriez avoir votre site disponible en HTTPS (modulo un avertissement de sécurité sur le certificat évidement).
Déploiement du certificat Let’s Encrypt
A partir de là, pour passer au certificat Let’s Encrypt sur le site:
cd /opt/letsencrypt
# vous pouvez ajouter autant de -d <domain.tld> si votre site répond à plusieurs DNS
./letsencrypt-auto --apache -d <yoursite.tld>
L’interface va vous poser quelques questions comme : accepter la licence, donner votre e-mail de contact ou encore faut-il rediriger vers HTTPS systématiquement. Normalement tout se fait automatiquement. Il se peut néanmoins que vous rencontriez quelques erreurs, en particulier si votre config de site est un peu « exotique« , pas de panique globalement ça se résout bien après quelques recherche Google et c’est l’occasion de remettre à plat votre conf…
Votre site est maintenant accessible en HTTPS avec un certificat reconnu par la majorité des navigateurs. Il suffit de vous y connecter pour vérifier :
https ok avec Let’s Encrypt
Si vous avez un doute sur la prise en compte, un rapide
service apache2 reload
devrait régler le problème.
Cycle de vie du certificat
Tous les certificat possèdent une date d’expiration pour des raisons de sécurité. Cette durée de validité est liée au temps théorique nécessaire qu’il faudrait à un attaquant pour calculer (ou casser) la clé privée à partir de clé publique. Chez Let’s Encrypt, cette durée est de 90 jour, avec la possibilité de renouveler au bout de 60 jour.
La commande pour renouveler le certificat est la suivante :
cd /opt/letsencrypt
./letsencrypt-auto renew
Il est évidement recommandé de renouveler vos certificats régulièrement. Vous pouvez ajouter une ligne de renouvellement dans votre crontab :
crontab -e
Et ajouter la ligne suivante, pour exécuter le ‘renew’ tous les samedis à 6h06 (au hasard, hein) :
« Quand on confie la sécurité à des amateurs, on a une sécurité d’amateur. » – un obscur ingénieur SSI
Mettre en place HTTPS c’est bien, le configurer correctement c’est mieux. La cryptographie c’est complexe et ça fait appel à un paquet de briques de bases. Chaque brique est une opportunité de vous gaufrer et de laisser un espace à exploiter pour un attaquant. Du coup, il vaut mieux s’assurer que votre conf suit les « best-practices » sur le sujet car elles ne s’inventent pas.
Pour cela, je vous invite à faire appel à ssllabs.com qui testera votre configuration HTTPS pour s’assurer qu’elle est « bien carrée, bien parallèle » (car oui, moi : j’aime bien quand c’est bien bien carré, bien parallèle…).
Et SSLlabs va vous faire un beau rapport vous expliquant ce qui va, et ce qui ne va pas dans votre conf. Après vous n’aurez plus qu’à corriger chaque ligne qui ne va pas.
Du coup, je vous le donne ici, ça revient à ajouter ces lignes-là dans votre fichier de conf du site :
#Tout sauf SSLv2 et SSLv3
SSLProtocol all -SSLv2 -SSLv3
#Toutes les ciphersuite HIGH, sauf sans authentification, et pas de MD5 non plus
SSLCipherSuite HIGH:!aNULL:!MD5
La plupart des config SSL apache sont très bien décrits dans ce how-to. Et si vous voulez le détail exact des « cypher suites » correspondantes. La commande suivante devrait vous aider.
Avec cette conf, Il manque encore quelques suites pour le forward secrecy. Mais si vous regardez dans le détail des résultats, vous vous rendrez compte que seul les navigateurs IE 8 / XP, IE 7 / Vista et Android 2.3.7 n’auront pas accès à cette fonctionnalité. Vous pouvez alors, au choix :
désactiver ces agents dans votre configuration du serveur ; ou
ajouter les algorithmes correspondant pour chaque navigateur supporté dans la SSLCipherSuite du serveur ; ou bien
ne rien faire…
Ce dernier point me parait raisonnable car je ne pense pas que les utilisateurs en question apprécient à sa juste valeur la configuration mise en place juste pour eux. Ensuite, s’ils étaient soucieux de la confidentialité de leurs échanges : ils auraient déjà changé de navigateur….
Conclusion : Test, plugins et dangers…
Avant de conclure cette article, j’aimerai vous indiquer qu’il y a une limite d’enrôlement de 5 certificats par semaine pour un nom de domaine dans Let’s Encrypt. Si vous voulez juste jouer un peu avec le client et ne pas mettre en place un site : utilisez l’infra de test. Ça vous évitera de vous retrouver coincé pour une semaine au bout de 5 essais. De plus, si vous n’utilisez pas apache, il existe aussi beaucoup d’autres plugins d’auto configuration avec Let’s Encrypt. Et si votre application n’existe pas dans la liste, vous pourrez toujours utiliser le plugin manual pour obtenir un couple certificat/clé à installer par vous-même (attention au key usage des certificats de Let’s Encrypt quand même).
Pour finir, je pense que vous avez compris que vous n’avez plus de raisons de ne pas avoir de version HTTPS de votre site à partir de… maintenant. Par contre ça pose une question un peu flippante : « quid des usages malveillant ? » J’entends par là, les seuls contrôles pour la délivrance du certificat sont : le bon réglage du couple DNS/IP qui demande le certificat et fournir un e-mail, et accepter les conditions d’utilisation (« oulala j’ai peur »).
Il n’y a aucun contrôle que le service est légitime et bien intentionné. A titre de réflexion pendant vos vacances, je vous donne l’exemple suivant :
Réserver le DNS « presquelenomdemabanque.com » ;
Y installer une copie du site mabanque.com ;
Déployer la version HTTPS avec Let’s Encrypt (en donnant un faux mail) ;
Et finir par une campagne de spam/phishing avec un lien vers votre faux site.
Résultat : vous aller vous retrouver avec un beau site qui indique « HTTPS » avec le petit cadenas vert dans la barre d’URL. Quel est la probabilité que les victimes tombent dans le piège ? Le temps que le site soit signalé et que le certificat soit révoqué par lets Let’s Encrypt, il risque d’y avoir un bon nombre de gens qui se fasse pirater…
Bref, bonnes vacances à tous et restez chiffrer !
Un commentaire concernant “Certificats HTTPS, Apache2 et Let’s Encrypt Geekeries.org !”
Pas facile de rester au lit toute la journée, hein ? … 😉
Ce site n'utilise pas de cookie pour vous garantir la meilleure expérience. Si vous continuez à utiliser ce site, nous supposerons que vous en êtes satisfait.OK
Pas facile de rester au lit toute la journée, hein ? … 😉