Publication d’acme-dns-tiny et du RFC 8555

Ce weekend, j’ai pris le temps de sortir une nouvelle version de mon projet acme-dns-tiny dont je vous avais parlé il y a presque 4 ans déjà.

Cette version 2.2 est une sortie mineure, mais elle a été l’occasion de mettre à jour le site du projet, de publier quelques correctifs mineurs déjà publiés dans la branche master et d’intégrer des correctifs du projet original ACME tiny.

Ce qui m’a motivé à reprendre le développement du projet, c’était que j’ai récemment appris à utiliser de manière plus avancée l’intégration continue de Gitlab.

Maintenant, dès que je fais une Merge Request, des images Docker pour Debian Jessie, Stretch et Buster sont fraîchement préparées et elles sont utilisées pour exécuter les tests du projet.

C’est assez cool d’avoir les images Docker toujours à jour, parce que, avant, je devais le faire manuellement. C’était clairement un frein pour reprendre le développement du projet (il fallait que je me replonge dans les commandes Docker, que je me rappelle pourquoi j’avais fait comme ça les builds…).

Grâce à l’intégration continue de Gitlab, j’ai aussi ajouté des contrôles sur le style du code pour suivre au mieux les directives de la PEP 8. Ces directives me semblent avoir du sens et elles me permettent d’unifier le style du code des 3 scripts proposés par le projet.

Vous noterez que dans le script acme-dns-tiny.py, j’ai choisi de désactiver les règles de pylint au sujet du nombre d’instructions et du nombre de variables utilisées dans un bloc.

Comme l’idée du script est de pouvoir être lu par un maximum de personnes, j’ai préféré garder un grand bloc d’instruction pour qu’il puisse être lu de haut en bas sans avoir besoin de rechercher des fonctions éparpillées au début du code. En effet, le but est que les administrateurs systèmes puissent aussi auditer le code pour être sûr que les clés privées ne soient pas divulguées.

Finalement, quitte à sortir une nouvelle version pour ces améliorations mineures, j’ai également profité de vérifier si le projet est compatible avec la version définitive du standard Automatic Certificate Management Environment (ACME) définie dans la RFC 8555.

En effet, la version précédente d’acme-dns-tiny a été publiée pour être compatible avec le 16^ème brouillon du standard.

Heureusement, le texte de la RFC n’a pas beaucoup changé depuis ce brouillon et le code d’acme-dns-tiny n’avait quasiment pas besoin d’être adapté.

À propos de cette RFC 8555, elle a été publiée en mars 2019 et je n’ai pas vu de nouvelle sur LinuxFr après une rapide recherche.

Ce standard est au cœur du projet Let’s Encrypt et il permet de fournir des certificats X.509 à moindre coût.

Ces certificats sont très utiles pour sécuriser le transfert des données entre client et serveur et pour s’assurer que le serveur appartient bien au propriétaire du nom de domaine. Ils sont typiquement utilisés pour le web avec le protocole HTTPS, mais également tous les protocoles qui permettent d’utiliser TLS, comme SMTP, IMAP, XMPP, LDAP, les connexions aux bases de données MariaDb, Postgresql…

Pour vérifier que la personne qui demande un certificat possède bien un nom de domaine, l’autorité de certification devait jusqu’à la publication de ce standard définir lui même le moyen utilisé.

Pour les certificats gratuits ou bon marché, souvent, l’identité était déjà vérifiée de manière automatique par l’autorité de certification.

Cependant, elle demandait au propriétaire du nom de domaine des actions manuelles comme: cliquer sur un lien unique publié dans un mail adressé, par exemple, à hostmaster@example.com, ou de créer une ressource DNS unique le temps de la vérification de l’identité, ou encore d’installer un fichier unique sur un site web à une adresse précise…

L’avantage du RFC 8555, c’est qu’il définisse clairement différent moyens sécurisés de vérifier que le demandeur de certificat possède bien un nom de domaine (soit en installant un fichier sur un serveur web, soit en installant une ressource DNS).

En plus d’être sécurisés, ces vérifications sont non seulement automatisable pour les autorités de certifications, mais aussi pour les demandeurs de certificat.

Dorénavant, il n’y a plus besoin d’intervention humaine pour demander et recevoir des certificats X.509 et c’est pour ça que je disais plus haut que ce RFC permet de les fournir à moindre coût.

Non seulement, Let’s Encrypt a développé le standard ACME dans le RFC8555, mais en plus, le projet fournit une implémentation logicielle libre nommée boulder pour le serveur de l’autorité de confiance.

Côté client pour les demandeurs de certificats, Let’s Encrypt avait débuté le développement de certbot, puis le projet a laissé le maintient du client à l’Electronic Frontier Foundation (EFF). Let’s Encrypt tient à jour une liste de tous les clients disponibles (dont, acme-dns-tiny de votre serviteur 😊)

Comme le standard et boulder ont évolué en même temps, boulder connaît quelques divergences par rapport au RFC. Heureusement, aujourd’hui la liste des divergences est courte :)