Comment se porte Let’s Encrypt ?

Cet article a été publié il y a 6 ans 7 mois 2 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Philippe m’a récemment remonté à juste titre sur Twitter que mon article sur Let’s Encrypt sent un peu la naphtaline. Voyons donc un peu ce qui a changé, en bien ou en mal. Mais si, je vais bien trouver un truc mauvais dans cette histoire, en fouillant bien…

Un besoin grandissant, pour tous les types de structures

En effet, le chiffrement des communications devient un élément de plus en plus déterminant, que ce soit au niveau des navigateurs qui vont indiquer de plus en plus lourdement quand un site est « en clair » (surtout dans le contexte de la saisie de données), mais aussi par les moteurs de recherche, Google en tête, qui vont intégrer le chiffrement dans les critères de référencement; et je les soupçonne d’avoir déjà commencé.

Et c’est une évolution sur laquelle je guide beaucoup de clients depuis maintenant un peu plus d’an, que ça soit sur le passage à HTTPS au niveau de leurs sites, soit sur de bonnes pratiques quand il est déjà en place (mixed-content, configuration affreuse). Que ce soit via Let’s Encrypt ou pas d’ailleurs, les implications de l’utilisation du HTTPS sont souvent très mal perçues (voire pas du tout) par la majorité des non-techniciens.

Mes torts sur l’article original

Mes premiers reproches étaient surtout liés à mon installation plus ou moins bancale liée à ISPConfig plutôt que le logiciel lui-même. Ceci dit, encore maintenant il n’est pas toujours évident de savoir quel est la raison précise liée à une erreur (les multiples difficultés que j’ai rencontré ces derniers mois sur le renouvellement étaient liées à l’IPv6, mais pour comprendre ça, j’en ai chié).

Maintenant que j’ai eu l’occasion d’utiliser l’outil « officiel » sur pas mal de plateformes, j’ai une meilleure expérience à partager, d’autant que le système ne se résume pas qu’à son outil principal, c’est avant tout un protocole qui peut être implémenté avec plusieurs langages, certbot, parce que c’est son nom maintenant, est lui écrit en Python (et ça a son importance).

Certbot, un outil qui évolue constamment

J’ai connu les débuts, et les premières évolutions ou les besoins liés à Python 2.7 font mal quand on tente d’utiliser le client officiel sur des plateformes un peu anciennes (Centos 5 et même Centos 6), et c’est pas toujours évident d’avoir un fonctionnement propre; si au début le warning n’est pas méchant, aux premiers dysfonctionnements c’est la loose. Là ça m’est pas arrivé directement à moi, mais à un collègue qui a du reprendre quasiment tout à zéro sur la plateforme d’un de ses clients (une vingtaine de certificats, ça commence à piquer).

Ce n’est pas un mal, ACME, le protocole, est encore jeune dans l’absolu, l’outil aussi, et ses capacités, notamment d’automatisation, augmentent doucement avec le temps. Le passage dans le giron de l’EFF n’a pas eu d’influence sur le rythme de son développement (c’est pas toujours garanti), ce qui est à mon sens une bonne chose.

Il faut malgré tout un environnement qui tienne la route, et c’est pas toujours aussi facile quand on entre dans le monde réel qui n’a pas toujours décidé de tourner sur les dernières versions, qui met à jour son application une fois tous les 10 ans parce qu’on décide qu’un budget de maintenance « n’est pas utile » (spoiler : c’est une connerie, et au premier gros pépin de sécurité, je vous assure que vous vous réveillez).

Les projets alternatifs se sont organisés

La première fois que j’ai eu à me passer du client officiel, pour enregistrer un certificat sur une Debian 5 (oui, le monde réel est un peu plus compliqué que ce qu’on pense), les solutions alternatives n’étaient pas d’une grande fiabilité, et j’ai galéré pour en faire marcher un sans trop de difficultés; d’ailleurs trois mois plus tard impossible de renouveler le certificat, et le script utilisé alors n’était plus maintenu. Si j’avais pu modifier moi-même à l’arrache le machin pour obtenir un renouvellement, les nouveaux problèmes qui se sont posés trois mois après ont achevé la plateforme. Fort heureusement depuis la machine est partie à la retraite et l’on a pu migrer sur du CentOS 7.

Dernièrement pour les plateformes récalcitrantes (et encore, pas que), j’ai découvert acme.sh, qui n’a donc aucune dépendance à Python, et j’ai été surpris par la qualité de script et de sa documentation. Le fait qu’il intègre en plus la création de certificat utilisant les courbes elliptiques alors que ce n’est toujours pas pris en charge complètement dans le client officiel est assez intéressant (d’ailleurs si vous regardez le certificat du blog…), sa rapidité m’a plu aussi. En soi le niveau de verbosité n’est pas nécessairement plus intéressant pour le débug, mais bon, son installation est super simple, et même pour un simple dépannage (« coucou on doit passer en ligne dans 1h mais y’a un débile qui a pas commandé le certificat »), vous gagnez un temps fou comparé à certbot, qui doit créer le virtualenv, qui va tenter de se mettre à jour à chaque lancement, la procédure de vérification rendant tout très long.

J’ai également pu lire d’autres articles qui utilisent des projets plus ou moins similaires, ou surtout dédiés à certains types d’environnement. On voit aussi que la possibilité de « commander » un certificat s’est généralisé chez plusieurs hébergeurs de sites mutualisés, j’ai pu enregistrer un certificat pour le NAS de ma maman directement via l’interface dudit NAS sans avoir à bricoler (enfin presque, mais c’est lié à l’installation classique derrière une box), bref, il n’a jamais été aussi facile d’utiliser ce type de certificat, pour le plus grand bonheur des personnes qui pensent qu’il faut tout chiffrer. Et si c’est pas nécessairement une réponse parfaite (cherchez un peu « Interception TLS » sur votre moteur de recherche préféré, vous comprendrez), il n’y a que peu de personnes pour encore avancer que c’est inutile de mettre en place ce type de sécurité. Moi le premier.

Le futur de Let’s Encrypt ne fait pas du surplace

À moins d’un gros, gros pépin de sécurité provoquant un coup d’arrêt au projet (du style exploitation frauduleuse généralisée), sa large adoption devrait éviter à Let’s Encrypt de sombrer comme a pu terminer CACert, toujours vivant mais pratiquement inutilisable pour le commun des mortels. Les plus gros sponsors du début sont toujours là, certains ont même augmenté leur participation, au moins financière, c’est donc plutôt solide comme fondation pour garder l’infrastructure, le protocole, au moins une implémentation fonctionnelle, debout et vivant.

Et les évolutions arrivent, avec entre autres l’année prochaine le système « ultime », à savoir le certificat wildcard, qui permet de couvrir n’importe quel sous-domaine (niveau 3), sans avoir à le déclarer préalablement; alors qu’actuellement on est limité à 100 sous-domaines à déclarer explicitement. Ces certificats, qui existent déjà chez les fournisseurs classiques, coûtent ultra cher et sont habituellement réservés aux entreprises qui peuvent facilement absorber le tarif. Également au programme de l’année prochaine, la version « 2 » de l’API liée au protocole ACME, qui dépassera les frontières de l’EFF pour devenir un standard IETF, le but étant que le protocole soit exploitable non seulement par Let’s Encrypt, mais aussi potentiellement par d’autres autorités de certifications, dans le but de faciliter et de fiabiliser la délivrance et la mise à jour des certificats sur les plateformes de destination.

Bref, non seulement le bilan est bien moins dégueulasse qu’à l’époque de mes premiers tests (et je ne parle pas de mon installation, mais bien du paysage), mais en plus l’avenir s’annonce pour l’instant solide, et au moins pour des projets personnels, ou certains projets pros qui n’ont pas nécessairement de disposer d’une garantie financière qui est souvent la raison du cout d’un certificat, il est possible d’avoir une solution fiable, abordable, et automatisable.

Bref, longue vie à Let’s Encrypt 🙂