boulder

Boulder est une implémentation d'une autorité de certification (AC) basée sur ACME, et c'est le logiciel qui fait fonctionner Let's Encrypt. Le protocole ACME permet à une AC de vérifier automatiquement qu'un demandeur de certificat contrôle réellement un identifiant, et permet aux abonnés d'émettre et de révoquer des certificats pour les identifiants qu'ils contrôlent. Architecture Boulder est divisé en composants séparés selon le contexte de sécurité : - Frontaux Web (un par version d'API) - Autorité d'enregistrement - Autorité de validation - Autorité de certification - Autorité de stockage - Éditeur - Metteur à jour des CRL Le frontal Web, l'autorité de validation, le stockeur de CRL et l'éditeur ont besoin d'un accès Internet et présentent donc un risque de compromission plus élevé. L'autorité d'enregistrement peut fonctionner sans connectivité Internet mais communique avec le frontal Web et l'autorité de validation. L'autorité de certification ne reçoit des instructions que de l'autorité d'enregistrement. Tous les composants utilisent l'autorité de stockage pour la persistance, qui repose sur MariaDB. Les composants communiquent via gRPC ; les composants distants sont instanciés sous forme de paires client/serveur, où le client implémente l'interface Go du composant et le serveur détient la logique réelle. En interne, le système est organisé autour de cinq types d'objets qui correspondent directement aux ressources ACME : comptes, autorisations, défis, commandes et certificats. Les requêtes des clients ACME créent de nouveaux objets et modifient ceux existants, et l'autorité de stockage conserve des copies persistantes de l'ensemble d'objets actuel. Configuration de développement Boulder est livré avec un Dockerfile et utilise Docker Compose pour installer et configurer toutes les dépendances. C'est la méthode recommandée par les mainteneurs pour l'exécuter à des fins de développement et d'expérimentation, et elle n'est explicitement pas adaptée à un environnement de production. Le projet suggère Pebble, une version miniature de Boulder, pour l'intégration continue et l'expérimentation rapide par les développeurs de clients ACME. Flux de travail typique : - Cloner le dépôt et s'assurer que Docker Engine 1.13.0+ et Docker Compose 1.10.0+ sont installés ; au moins 2 Go de RAM sont recommandés pour l'hôte Docker. - Exécuter ./t.sh pour la batterie standard de linters, de tests unitaires et d'intégration ; ./t.sh -u pour les tests unitaires, ./t.sh -i pour les tests d'intégration, et ./tn.sh pour la configuration « config-next » représentant un état futur probable. - Exécuter docker compose run bsetup une fois pour écrire les certificats dans test/certs, puis docker compose up pour démarrer Boulder. - Le fichier docker-compose.yml monte le checkout dans /boulder afin que les modifications de l'hôte soient reflétées immédiatement dans les conteneurs. Par défaut, Boulder utilise un faux résolveur DNS qui résout tous les noms d'hôte vers 127.0.0.1, ce qui convient aux tests d'intégration à l'intérieur du conteneur. Pour permettre à un client basé sur l'hôte de communiquer avec Boulder, trouvez l'IP Docker de l'hôte et définissez la variable d'environnement FAKE_DNS en conséquence ; le résolveur simulé (sd-test-srv) répond alors à toutes les requêtes A avec cette adresse. Les pare-feu basés sur l'hôte doivent autoriser les connexions de l'instance Docker vers l'hôte sur les ports de validation requis. Travailler avec des clients ACME Avec l'environnement de développement en cours d'exécution, les points de terminaison ACME sont exposés à l'hôte sur http://localhost:4001/directory (ACME v2, HTTP) et https://localhost:4431/directory (ACME v2, HTTPS). L'utilisation des points de terminaison HTTPS nécessite de configurer le client avec un truststore contenant le certificat AC test/certs/ipki/minica.pem. Comme le faux résolveur renvoie 127.0.0.1 pour toute requête, des certificats peuvent être émis pour n'importe quel domaine comme s'il résolvait vers localhost ; changer FAKE_DNS modifie l'adresse renvoyée, et elle est souvent définie sur la machine hôte exécutant le client ACME. Le README montre l'exécution de Certbot contre un Boulder local avec une variable d'environnement SERVER personnalisée et l'option --standalone. Notes de production Le projet indique que Boulder est conçu sur mesure pour Let's Encrypt et destiné uniquement à soutenir la PKI Web et les exigences de base du CA/Browser Forum. Il note que Boulder n'est souvent pas le bon choix pour les organisations qui l'évaluent pour la production, et qu'une PKI gérée de manière centralisée sans autorisation de domaine ACME est généralement un meilleur choix. Un guide de déploiement et de mise en œuvre est proposé, décrivant le travail requis et les considérations de sécurité. L'environnement de développement basé sur Docker n'est explicitement pas adapté à la production : il utilise du matériel de clé privée publiquement disponible, expose des ports de débogage et est fragile face aux défaillances de composants. Le support et le développement privilégient la mission de Let's Encrypt, de sorte qu'un support rapide ou des pull requests qui s'écartent significativement des objectifs de première ligne peuvent ne pas être acceptés. Contribution et licence Les directives de contribution, le processus de revue de code, le code de conduite et d'autres conseils se trouvent dans CONTRIBUTING.md ; le code de conduite communautaire est référencé sur le forum communautaire de Let's Encrypt. Le projet est sous licence Mozilla Public License 2.0.