NGINX introduit la prise en charge native du protocole ACME

• NGINX a dévoilé une version preview prenant en charge nativement le protocole ACME, qui automatise l’émission et le renouvellement des certificats SSL/TLS
• Grâce au nouveau module ngx_http_acme_module basé sur Rust, il devient possible de demander, installer et renouveler des certificats uniquement via la configuration NGINX, sans outil externe
• Cela réduit la dépendance à des outils externes comme Certbot et améliore la sécurité ainsi que l’indépendance vis-à-vis de la plateforme
• La version initiale prend en charge le challenge HTTP-01 ; la prise en charge de TLS-ALPN et DNS-01 est prévue par la suite
• La prise en charge d’ACME devrait aussi jouer un rôle important dans l’automatisation de la sécurité au-delà du web, notamment dans les environnements IoT et edge computing

---

Vue d’ensemble et principaux changements

• NGINX a publié une version preview de la prise en charge du protocole ACME
• Le nouveau module ngx_http_acme_module est conçu pour permettre de gérer directement, depuis la configuration NGINX, la demande, l’installation et le renouvellement des certificats
• Cette prise en charge d’ACME s’appuie en interne sur le NGINX-Rust SDK et est fournie sous forme de module dynamique basé sur Rust
• Cette fonctionnalité est disponible aussi bien pour les utilisateurs open source que pour les clients enterprise de NGINX Plus
• En réduisant la dépendance à des outils externes comme Certbot, elle améliore la sécurité et l’efficacité de la gestion des certificats

Présentation du protocole ACME

• Le protocole ACME (Automated Certificate Management Environment) est un protocole de communication qui automatise l’émission, la validation, le renouvellement et la révocation des certificats SSL/TLS
• Grâce à une communication automatisée avec la CA (Certificate Authority), le client peut gérer directement le cycle de vie des certificats sans intervention manuelle d’un intermédiaire
• Il a été développé et publié en 2015 par l’Internet Security Research Group (ISRG) dans le cadre du projet Let’s Encrypt
• Avant l’arrivée d’ACME, le processus d’émission des certificats était plus manuel, plus coûteux et plus exposé aux erreurs
• La version actuelle, ACMEv2, ajoute diverses fonctionnalités comme différents modes de validation et la prise en charge des wildcards, ce qui renforce sa flexibilité et sa sécurité

Flux d’automatisation des certificats avec ACME dans NGINX

• Dans NGINX, l’automatisation du cycle de vie des certificats via le protocole ACME se déroule en 4 étapes

• 1. Configuration du serveur ACME

  • Pour activer la fonctionnalité ACME, il faut impérativement spécifier l’URL du répertoire du serveur ACME avec acme_issuer
  • En cas d’émission de certificat, il est aussi possible d’indiquer en option des informations de contact client, le chemin de stockage des données d’état, etc.

• 2. Allocation de mémoire partagée (zone)

  • Avec acme_shared_zone, il est possible de configurer en plus une zone de mémoire partagée pour stocker les certificats, les clés privées et les données de challenge
  • La taille par défaut est de 256K, extensible selon les besoins

• 3. Configuration du challenge

  • La version preview actuelle ne prend en charge que le challenge HTTP-01, utilisé pour vérifier la propriété du domaine
  • Pour cela, il faut définir dans la configuration NGINX un listener sur le port 80 ainsi qu’une réponse 404 par défaut
  • La prise en charge des challenges TLS-ALPN et DNS-01 est prévue ultérieurement

• 4. Émission et renouvellement des certificats

  • En ajoutant la directive acme_certificate à un bloc serveur, il devient possible d’automatiser l’émission et le renouvellement du certificat TLS pour le domaine concerné
  • Le domaine visé par l’émission du certificat est généralement indiqué via server_name
  • Les expressions régulières et les wildcards dans server_name ne sont pas pris en charge dans cette version preview
  • Les variables du module $acme_certificate et $acme_certificate_key permettent d’associer automatiquement le certificat et la clé

Principaux avantages

• Le protocole ACME est au cœur de la forte progression de l’usage de HTTPS dans le monde
• L’automatisation de la gestion des certificats réduit fortement les coûts de gestion du cycle de vie des certificats et les erreurs dues aux manipulations manuelles
• La suppression des outils externes permet de réduire la surface d’attaque et d’améliorer la portabilité
• Elle favorise aussi la standardisation de la sécurité dans des environnements variés

Feuille de route

• Ajout prévu de la prise en charge des challenges TLS-ALPN et DNS-01
• Extension des fonctionnalités sur la base des retours utilisateurs
• Avec l’adoption croissante de l’IoT, des API et de l’edge computing, ACME devrait jouer à l’avenir un rôle central dans une infrastructure de sécurité automatisée sur un périmètre toujours plus large
• La prise en charge native d’ACME par NGINX devrait servir de base pour faire de la sécurité web, de l’automatisation et de la scalabilité des standards d’avenir

Bien démarrer

• Les utilisateurs open source peuvent utiliser le module précompilé via les packages Linux NGINX
• Pour les clients enterprise de NGINX Plus, il est fourni sous forme de module dynamique pris en charge par F5
• Voir la documentation du module dans NGINX Docs

[GN⁺]

Avis Hacker News

• Pour l’instant, la version preview ne prend en charge que le challenge HTTP-01 pour vérifier la propriété du domaine du client.
  La méthode DNS-01 serait bien plus utile pour les utilisateurs de nginx qui ne sont pas exposés publiquement (par exemple avec Nginx Proxy Manager). DNS-01 se contente de mettre à jour un enregistrement, donc j’ai toujours trouvé que c’était l’approche la plus propre. J’attends vraiment l’arrivée de cette fonctionnalité.
  • Mais il faut impérativement disposer d’une clé API DNS, et beaucoup de fournisseurs DNS ne proposent pas de clé API distincte par zone. Personnellement, j’aime DNS-01, mais en pratique il peut être nécessaire d’accepter un compromis un peu décevant.
  • Pas besoin d’attendre : angie le prend aussi en charge (angie est un fork de nginx créé par d’anciens développeurs nginx partis de chez F5).
  • Ce qui est frustrant avec l’ACME de Traefik, c’est qu’on ne peut utiliser qu’une seule clé API par fournisseur DNS. Du coup, c’est très contraignant si on veut restreindre les clés API par domaine ou utiliser des domaines répartis sur plusieurs comptes. J’espère que nginx sortira cette fonctionnalité sans cette limitation.
  • Personnellement, dans mon homelab, j’utilise DNS-01 avec une combinaison de step-ca et caddy. L’expérience est très satisfaisante.
  • Comme DNS-01 y est très bien pris en charge, je recommande aussi de passer à Angie.
• C’est un changement assez important. Caddy le faisait depuis longtemps, mais tout le monde ne préfère pas caddy. Cette mise à niveau pourrait grignoter des parts d’usage à des logiciels comme Traefik.
  • J’aime particulièrement la syntaxe épurée de Caddy. J’utilise actuellement nginx (via nginx proxy manager) et Traefik, mais j’ai récemment testé un projet avec Caddy et c’était très agréable. Si j’ai le temps, j’aimerais migrer mon environnement self-hosted vers Caddy. Ou peut-être utiliser quelque chose comme pangolin. pangolin propose même une alternative à Cloudflare Tunnels.
  • Je viens justement de passer complètement à caddy. Le facteur décisif, ça a été la réponse assez passive de nginx au problème de désynchronisation HTTP/1. Attendre qu’un incident survienne, ou ne pas avoir de réponse claire de nginx quand un auditeur pose la question, ça ne me convient pas.
    Caddy est clairement plus simple que nginx. Il fournit des templates couvrant divers services, des tests et même des services spécifiques aux établissements d’enseignement, ainsi qu’un meilleur logging, une gestion des certificats parfaite pour mon usage et de meilleures métriques.
    En revanche, j’en suis encore à me former côté plugins : caddy n’a pas de rate limiting, et à cause d’un bug de Power BI, un certain utilisateur demande une image 300 000 fois par jour, donc ce n’est pas idéal non plus.
  • Je pense clairement la même chose. J’utilise encore un peu traefik chez moi, mais maintenant je vais probablement le remplacer directement.
• C’est un changement bienvenu. Dokku (dont je suis le mainteneur) utilise actuellement le plugin letsencrypt comme solution de contournement, et les utilisateurs rencontrent souvent des problèmes aléatoires. Il arrive aussi que nginx « bloque » pendant un reload et ne trouve plus les endpoints. Moins il y a de variables complexes comme ça, mieux c’est.
  Mais il faudra probablement encore du temps avant que cette fonctionnalité n’arrive dans les dépôts stables Ubuntu ou Debian.
  En plus, comme le challenge DNS (certificats wildcard) n’est pas encore pris en charge, cela ne devrait pas beaucoup aider Dokku à court terme.
  • Bonjour ! Ravi de vous croiser ici.
    J’ai essayé Dokku (et j’essaie encore), mais la barrière à l’entrée m’a semblé assez élevée.
    Par exemple, avec Coolify, il suffisait de créer une GitHub App pour connecter immédiatement le déploiement, et j’ai aussi déjà une expérience de build/déploiement de conteneurs avec GitHub Actions.
    La documentation officielle de dokku ressemble plus à un manuel de référence, on a l’impression de lire une encyclopédie : documentation officielle sur l’initialisation Git de dokku
    J’ai l’impression qu’un guide de démarrage vraiment direct, qui aide à déployer tout de suite comme Coolify, serait plus utile : aide à l’intégration GitHub de coolify
    Ce serait bien d’avoir pour Dokku des guides d’installation d’applications OSS populaires, un guide d’introduction avec des objectifs et validations étape par étape, ainsi qu’un tutoriel qui couvre d’un coup le reverse proxy sur bare metal et plusieurs applications populaires.
    Au final, le but quand on utilise Dokku n’est pas Dokku lui-même, mais d’atteindre facilement et rapidement « l’état souhaité » grâce à Dokku.
    Idéalement, je veux un processus sans douleur où je peux « cliquer sur un dépôt qui me plaît et le déployer immédiatement sur ma machine ». Ensuite seulement, j’ai envie d’explorer les détails de l’infrastructure sous-jacente.
• Bonne nouvelle. Pour ceux qui ne le sauraient pas, il existait déjà une solution simple appelée dehydrated. Il suffit d’ajouter quelques lignes à la configuration du vhost :

    location ^~ /.well-known/acme-challenge/ {  
      alias ;  
    }  
  

  dehydrated est depuis longtemps un outil léger utilisé pour automatiser le renouvellement HTTP-01.
  • La fonctionnalité elle-même est vraiment excellente, mais c’est dommage qu’un projet dont des milliers de personnes dépendent ne continue pas à publier de release stable.
    Un logiciel sans release officielle v1.0.0 peut voir son interface changer à tout moment sans préavis. Le major version 0 finit toujours par devenir un piège.
    Je recommande de demander aux mainteneurs de publier une version stable.
    dehydrated est bloqué au major version 0 depuis 7 ans.
    0ver.org vaut aussi le détour :
    c’est une philosophie de versioning du type « si c’est utilisé en production, ça devrait déjà être en 1.0.0 ».
    Plus de détails ici.
• Il y a eu un petit raté dans cette release : ngx_http_acme_module a été inclus dans les paquets de plusieurs distributions Linux, mais Debian stable manque à l’appel.
  D’après la liste officielle des paquets nginx, oldstable et oldoldstable sont là, mais Debian 13 Trixie, sorti il y a 4 jours, n’y est pas.
  • Nous sommes en train de préparer l’upload du paquet Trixie. Il devrait arriver cette semaine. Debian 13 n’est sorti qu’il y a 4 jours, donc il a fallu du temps pour mettre en place l’infrastructure du nouvel OS. (Je travaille chez F5.)
  • Je pense que c’est probablement une erreur du côté de Debian.
• Depuis que j’ai découvert Caddy, je n’utilise plus nginx. L’expérience de développement est bien meilleure.
• Le problème des grandes entreprises de l’open source, c’est qu’elles sont toujours en retard quand il s’agit de comprendre et d’implémenter correctement les « innovations de base ».
  nginx ne fait qu’ajouter maintenant ce que Caddy et Traefik faisaient déjà il y a 5 ans.
  Cela dit, je pense que c’est une bonne évolution. Au moins, on n’aura plus besoin d’exécuter certbot soi-même.
  • En réalité, Caddy prenait déjà en charge dans une certaine mesure le HTTPS automatique de Let’s Encrypt dès 2016, soit il y a presque 10 ans.
    nginx introduit donc cette fonctionnalité avec environ 9 à 10 ans de retard.
• Personnellement, je n’ai jamais vraiment eu l’impression que le modèle où nginx sert le contenu web et certbot gère le renouvellement posait problème.
  À l’origine, je trouve meilleure la philosophie Unix consistant à bien faire une seule chose et à pouvoir combiner les outils.
  Les « outils » qui essaient de tout faire finissent inévitablement par être moins bons sur au moins un aspect.
  • Configurer certbot est une expérience assez pénible.
    Même quand certbot essaie d’automatiser la configuration, ça marche mal dès qu’on sort d’un environnement standard.
    Le fait de tout gérer directement dans nginx me paraît finalement être une meilleure solution.
• Si je comprends bien, cela veut dire qu’avec cette fonctionnalité, quelques lignes ajoutées au fichier de configuration nginx suffisent pour ne plus avoir à installer/exploiter certbot.
  Je me demande aussi si cela ouvre la voie à une utilisation simple d’alternatives à Let’s Encrypt.
• C’est un changement prometteur.
  Caddy est vraiment pratique, avec beaucoup de fonctionnalités prêtes à l’emploi.
  Personnellement, si je n’ai pas encore complètement basculé vers Caddy, c’est à cause de mon besoin des modules rate limiting et geo de nginx.