NGINX introduit le support natif du protocole ACME

L'équipe de développement NGINX annonce la disponibilité d'une version préliminaire de la prise en charge d'ACME dans NGINX. Cette version introduit le nouveau module ngx_http_acme_module , conçu pour fournir des directives intégrées permettant de demander, d'installer et de renouveler des certificats directement dans la configuration NGINX, sans procédure externe. La prise en charge d'ACME repose sur le SDK NGINX-Rust et est distribuée sous forme de module dynamique écrit en Rust, accessible aux utilisateurs de NGINX Open Source et aux clients NGINX Plus via la plateforme NGINX One.

L'intégration native du protocole ACME à NGINX représente une avancée majeure dans la simplification de la gestion des certificats SSL/TLS. La possibilité de configurer directement le processus d'émission et de renouvellement via les directives NGINX réduit considérablement le risque d'erreurs manuelles tout en améliorant l'efficacité opérationnelle. Cette approche élimine une grande partie de la complexité et des contraintes généralement associées à la gestion des certificats numériques et diminue la dépendance à des outils externes tels que Certbot. Il en résulte un flux de travail plus sécurisé, rationalisé et centralisé, avec une surface d'attaque réduite et une gestion plus transparente.

Un autre avantage par rapport aux outils externes est l'absence de contraintes de plateforme. L'implémentation native dans NGINX garantit une portabilité et une indépendance supérieures, ce qui le rend adapté à un large éventail de contextes, des infrastructures web d'entreprise établies aux environnements cloud en constante évolution. Ce nouveau module constitue ainsi une solution polyvalente et fiable, capable de répondre aux besoins d'évolutivité, de sécurité et d'automatisation propres aux architectures applicatives modernes.

Qu'est-ce que ACME ?

Le protocole ACME (Automated Certificate Management Environment) est un système de communication conçu pour automatiser les opérations liées aux certificats de sécurité numérique, notamment SSL/TLS. ACME permet de gérer l'intégralité du cycle de vie d'un certificat : de son émission initiale à sa validation, son renouvellement et sa révocation. Les clients peuvent ainsi interagir avec une autorité de certification (AC) sans intervention manuelle, ce qui réduit les délais, les coûts et la complexité. La disponibilité d'un protocole standardisé a considérablement facilité l'adoption du protocole HTTPS comme exigence fondamentale pour les sites web, les applications et les services en ligne nécessitant des communications chiffrées et sécurisées.

Le développement du protocole ACME a été initié par l' Internet Security Research Group (ISRG) dans le cadre du projet Let's Encrypt , lancé fin 2015. Cette initiative a eu un impact révolutionnaire : pour la première fois, des certificats SSL/TLS gratuits et faciles à obtenir étaient proposés, à une époque où l'acquisition de certificats était souvent un processus manuel, coûteux et sujet aux erreurs. L'automatisation introduite par ACME a radicalement changé la donne, transformant l'adoption du protocole HTTPS d'une option avancée en la norme de facto du web moderne.

Au fil du temps, le protocole a été perfectionné grâce à la spécification ACMEv2 , qui a introduit de nouvelles fonctionnalités et étendu ses cas d'utilisation. Parmi les principales nouveautés, citons la prise en charge de nouveaux types de défis pour la vérification d'identité, des méthodes d'authentification plus flexibles, l'introduction des certificats génériques (utiles pour protéger des domaines et sous-domaines entiers avec un seul certificat) et une sécurité globale renforcée. Grâce à ces évolutions, ACME est aujourd'hui considéré comme un pilier de la gestion automatisée des certificats numériques et un outil essentiel pour garantir la disponibilité mondiale de connexions chiffrées et sécurisées.

Comment fonctionne le protocole ACME ?

Il y a en fait deux explications à cette question : une explication générale qui couvre les bases, et une explication plus approfondie qui aborde l'aspect technique. Nous allons essayer de rester concis.

Une fois l'agent ACME installé et correctement configuré, le processus est relativement simple. Nous aborderons la configuration plus loin, mais pour l'instant, gardez à l'esprit que lors de la vérification qui a lieu lors de l'installation de l'agent, une paire de clés est générée pour l'agent et l'autorité de certification. Ces clés sont parfois appelées « clés d'autorisation ».

Émission/Renouvellement

Pour obtenir un certificat numérique, l'agent doit générer une demande de signature de certificat (CSR) pour le domaine souhaité et la soumettre à l'autorité de certification (AC). L'ensemble du processus est sécurisé par HTTPS , garantissant ainsi l'intégrité et la confidentialité des informations.

• L'agent génère un CSR pour le domaine
  La première phase consiste en la création du Demande de signature de certificat, qui comprend des données d'identification de domaine (par exemple example.com) et la clé publique qui sera associée au certificat. Ce document constitue le point de départ du processus de validation.

• L'agent signe la clé publique générée avec le CSR avec la clé privée correspondante
  Pour garantir que la clé publique est bien liée au domaine et n'a pas été falsifiée, l'agent utilise sa clé privée pour signer la CSR. Cela établit un lien cryptographique sécurisé entre la paire de clés publique et privée.

• L'agent signe l'intégralité du CSR avec sa clé d'autorisation privée
  Outre la signature associée à la paire de clés de domaine, l'agent applique également la clé privée d'autorisation générée lors de la configuration initiale du protocole ACME. Cette seconde signature permet de prouver à l'autorité de certification que la requête provient d'un client légitime et autorisé à demander des certificats.

• L'AC vérifie les deux signatures et délivre le certificat
  L'autorité de certification vérifie la validité des signatures, l'exactitude de la CSR et l'association au domaine. Une fois ces vérifications effectuées, elle émet le certificat numérique SSL/TLS.

• L'agent reçoit le certificat et l'installe sur le domaine concerné
  Une fois émis, le certificat est envoyé à l'agent, qui l'installe dans la configuration du serveur. Le domaine est alors accessible via des connexions HTTPS sécurisées, le certificat étant valide et reconnu par les navigateurs et les clients.

Vous remarquerez que l'agent dont nous parlons n'est pas un petit bonhomme résidant sur votre serveur, comme le suggèrent les icônes que j'ai choisies. Inutile donc de le préciser. C'est plus amusant de l'imaginer ainsi.

Quoi qu'il en soit, ce processus fonctionne plus ou moins de la même manière pour les renouvellements. L'agent peut être configuré pour envoyer des pings à l'AC à intervalles réguliers afin de renouveler les clés ou de remplacer des certificats entiers. Tout cela se déroule en arrière-plan, sans aucune intervention humaine.

Révocation

Comme pour l'émission, la révocation d'un certificat SSL/TLS requiert l'intervention d'un agent, qui doit générer et signer une demande officielle. Toutefois, dans ce cas précis, la demande ne vise pas l'obtention d'un nouveau certificat, mais l'invalidation d'un certificat existant. L'autorité de certification (AC) révoque alors le certificat et met à jour les registres publics permettant aux navigateurs et clients de vérifier son statut.

• L'agent génère une demande de révocation pour le certificat SSL/TLS
  L'agent crée un document qui identifie le certificat à révoquer, y compris le numéro de série et les informations nécessaires pour le lier de manière unique à l'émission d'origine.

• L'agent signe la requête avec sa clé privée
  Pour garantir que la demande provient bien du titulaire du certificat, l'agent utilise sa clé privée pour la signer numériquement. Cela prouve à l'AC que la révocation n'a pas été demandée par un tiers non autorisé.

• L'AC vérifie la signature pour s'assurer que la demande est autorisée.
  L'autorité de certification vérifie la validité de la signature et sa correspondance avec la clé publique associée au certificat. Si la vérification est concluante, l'AC reconnaît la demande comme légitime.

• L'AC révoque le certificat
  Une fois l’authenticité de la demande confirmée, le certificat est officiellement révoqué, le rendant ainsi non valide pour établir des connexions sécurisées.

• L'état de révocation du certificat est publié auprès des CRL et des répondeurs OCSP
  Enfin, l'AC met à jour le Liste de révocation de certificats (CRL) et les intervenants OCSP (Online Certificate Status Protocol)Ces systèmes permettent aux navigateurs et aux clients de vérifier l’état de validité du certificat en temps réel, garantissant que tout certificat compromis ne peut plus être utilisé pour des connexions HTTPS fiables.

Flux de travail ACME dans NGINX

Le flux de travail ACME au sein de NGINX peut être décrit comme une séquence de quatre phases principales, qui permettent la gestion automatisée de l'ensemble du cycle de vie du certificat numérique :

1. Configuration du serveur ACME
   À ce stade, NGINX est configuré pour communiquer avec une autorité de certification prenant en charge le protocole ACME. Cela établit le point de contact pour demander, valider et obtenir des certificats SSL/TLS.

2. Allocation de mémoire partagée
   Pour garantir efficacité et stabilité, le module NGINX ACME utilise des zones de mémoire partagée pour gérer les informations des requêtes et les statuts de validation. Cette architecture permet une coordination fiable entre les différents processus serveur.

3. Mettre en place des défis
   NGINX est chargé de gérer les vérifications requises par l'autorité de certification, telles que HTTP-01 ou DNS-01. Cette étape est essentielle pour prouver la propriété du domaine et autoriser l'émission du certificat.

4. Délivrance et renouvellement des certificats
   Une fois la validation terminée, le certificat est automatiquement émis et installé. Le module ACME gère également le renouvellement périodique, éliminant ainsi toute intervention manuelle et réduisant le risque d'interruption de service due à l'expiration des certificats.

Configuration du serveur ACME

Pour activer les fonctionnalités ACME dans NGINX, la première étape (et la seule obligatoire) consiste à spécifier l'URL du répertoire du serveur ACME. Ce paramètre indique au module l'autorité de certification à contacter pour l'émission, la validation et le renouvellement des certificats SSL/TLS.

Au-delà de ce minimum requis, vous pouvez définir des informations supplémentaires utiles au bon fonctionnement du module. Par exemple, vous pouvez spécifier les coordonnées à utiliser si l'autorité de certification doit signaler des problèmes liés aux certificats émis. Vous pouvez également configurer le chemin d'accès aux données du module, telles que les informations d'état ou les clés nécessaires au processus de validation. Ces options supplémentaires, bien que non obligatoires, contribuent à une gestion plus fiable et à un meilleur contrôle opérationnel.

acme_issuer letsencrypt { uri https://acme-v02.api.letsencrypt.org/directory; # contact admin@example.test; state_path /var/cache/nginx/acme-letsencrypt; accept_terms_of_service; }

Allocation de mémoire partagée

L'intégration de la prise en charge d'ACME dans NGINX introduit également la directive optionnelle `acme_shared_zone` , conçue pour gérer les certificats, les clés privées et les données de défi de tous les émetteurs configurés dans une zone de mémoire partagée. Cette zone permet aux différents processus serveur d'accéder de manière cohérente aux mêmes informations, évitant ainsi les redondances et simplifiant la coordination interne.

Par défaut, la taille de la zone est de 256 Ko , ce qui est suffisant pour les scénarios simples. Cependant, pour les environnements plus complexes ou avec un grand nombre de certificats à gérer, cette taille peut être augmentée selon les besoins. La possibilité d'ajuster la mémoire dédiée rend l'approche plus flexible, permettant ainsi à NGINX de s'adapter aussi bien aux installations légères qu'aux environnements d'entreprise plus exigeants.

zone_partagée_acme zone=acme_shared:1M;

Mettre en place des défis

Dans cette version préliminaire, l'implémentation ACME dans NGINX prend actuellement en charge les défis HTTP-01 , utilisés pour vérifier que le client est bien propriétaire du domaine. Pour gérer correctement ce mécanisme, vous devez définir un écouteur sur le port 80 dans la configuration NGINX , capable de recevoir et de répondre aux requêtes de validation envoyées par l'autorité de certification. Cette configuration garantit que le serveur peut démontrer automatiquement et de manière transparente qu'il est propriétaire du domaine, condition préalable à l'émission d'un certificat SSL/TLS.

serveur { # L'écouteur sur le port 80 est requis pour traiter les défis ACME HTTP-01 listen 80; location / { # Sert de réponse 404 de base lors de l'écoute des défis return 404; } }

L'équipe de développement prévoit également d'étendre la prise en charge d'autres types de défis, notamment TLS-ALPN-01 et DNS-01 , qui seront intégrés dans les prochaines versions. Ces méthodes supplémentaires élargiront les capacités de validation, offrant une plus grande flexibilité dans les scénarios complexes tels que les équilibreurs de charge, les environnements multi-serveurs ou lorsque l'accès direct au port 80 est impossible.

Délivrance et renouvellement des certificats

Pour automatiser l'émission et le renouvellement des certificats TLS dans NGINX, vous pouvez utiliser la directive `acme_certificate` dans le bloc serveur concerné . Cette directive requiert une liste d' identifiants (domaines) pour lesquels les certificats doivent être générés dynamiquement. Cette liste est généralement définie à l'aide de la directive `server_name` , qui spécifie les noms de domaine associés au bloc serveur.

Un exemple typique est la configuration d'un bloc serveur pour le domaine example.domain, en utilisant l'émetteur ACME précédemment défini (par exemple, celui de Let's Encrypt). Dans ce cas, le module se charge automatiquement de demander et d'installer le certificat SSL/TLS, ainsi que de gérer ses renouvellements périodiques, sans intervention manuelle.

serveur { listen 443 ssl; nom_serveur .example.com; certificat_acme letsencrypt; certificat_ssl $acme_certificate; clé_certificate_ssl $acme_certificate_key; cache_certificate_ssl max=2; }

Il est important de souligner que toutes les valeurs acceptées par la directive ne sont pas nom du serveur sont considérés comme des identifiants valides. La version préliminaire ne prend pas en charge générique (Par exemple *.example.domain) ni l'utilisation de expressions régulièresCes limites seront progressivement révisées dans les futures implémentations pour élargir la compatibilité avec des scénarios plus complexes.

Une fois le certificat obtenu, ses informations peuvent être gérées à l'aide des variables `$acme_certificate` et `$acme_certificate_key` , qui fournissent au module les données nécessaires à l'activation du chiffrement SSL/TLS sur le domaine associé. Cette intégration simplifie le flux opérationnel et garantit une gestion cohérente des certificats directement au sein de la configuration NGINX.

Pourquoi tout cela est important

L'adoption mondiale du protocole HTTPS a été considérablement accélérée par l'introduction du protocole ACME , qui a fait de la sécurité web une exigence fondamentale et non plus une option. En automatisant l'intégralité du cycle de vie des certificats SSL/TLS (de l'émission au renouvellement, en passant par la gestion quotidienne), ACME a éliminé une grande partie de la complexité opérationnelle et des coûts liés aux processus manuels, rendant ainsi la sécurisation des communications en ligne plus simple et plus accessible.

Le rôle d'ACME ne se limite pas au web traditionnel. Avec la croissance exponentielle des objets connectés, des services API et des infrastructures de calcul en périphérie , le protocole s'impose également comme un élément fondamental de l'automatisation de la sécurité dans les environnements distribués et hautement évolutifs. Dans de tels contextes, la capacité à fournir des certificats fiables et toujours à jour est essentielle pour garantir l'intégrité, la confidentialité et la résilience du système.

La prise en charge native d'ACME par NGINX confirme l'importance stratégique de ce protocole pour l'avenir de la sécurité, de l'automatisation et de la scalabilité. ACME restera probablement la pierre angulaire de l'automatisation des certificats pour longtemps encore, étendant son impact bien au-delà du web. La sécurité étant désormais partie intégrante des normes réseau, il est naturel de s'attendre à une évolution continue des modèles de déploiement d'applications et des exigences de sécurité, ce qui entraînera des améliorations et des perfectionnements constants du protocole lui-même.

Tournée vers l'avenir, l'équipe de développement de NGINX s'est engagée à développer progressivement son implémentation afin de répondre non seulement aux besoins actuels des utilisateurs et des clients, mais aussi aux besoins émergents. L'objectif est de fournir des fonctionnalités adaptées à de nouveaux scénarios, avec une approche conciliant fiabilité, sécurité et innovation.

Commencer

Vous pouvez déjà bénéficier de la prise en charge native d'ACME dans NGINX.

• Des packages précompilés téléchargeables sont disponibles pour les utilisateurs de logiciels libres .

• Pour les clients d'entreprise NGINX Plus , via la plateforme NGINX One , le module est fourni en tant que composant dynamique pris en charge par F5.

Vous trouverez plus d'informations sur la configuration et l'utilisation du module dans la documentation officielle de NGINX.