NGINX va supporter directement ACME (donc, les certificats Let's Encrypt) via un nouveau module ngx_http_acme (implémenté en Rust). Utiliser Certbot ne sera plus nécessaire.
Traefik, Caddy et Apache avaient déjà cette fonctionnalité.
Traefik, Caddy et Apache avaient déjà cette fonctionnalité.
Pour moi c'est un must have.
J'utilise Traefik car il fait de la découverte automatique (discovery) Docker. Il suffit d'annoter un container avec les bons libellés pour que Traefik mette en place les règles de routage et la prise en charge du certificat chez une autorité de certification supportant ACME (comme Let's Encrypt).
Cependant je le soupçonne de prendre beaucoup plus de CPU que nécessaire. Donc si les autres se mettent à niveau, je pourrais m'y pencher.
Uniquement le challenge HTTP-01. Ça va sûrement de soit, mais je tiens à le préciser pour ceux qui utilisent le challenge DNS-01 par exemple.
Reste à savoir si F5 fournira des containers nginx avec se module pré-compilé. Actuellement quand on veut un module nginx, faut le compiler… en regard des sources de la version exacte de nginx. Un peu comme les modules du noyau Linux. Ça se traduit donc en général par une compilation de nginx et des modules nécessaires. Sans un ajout comme module directement disponible ça ne change pas trop la donne étant donné qu’il existait également d’autres modules nginx qui faisaient le job, juste pas éditée par F5.
Je croise donc les doigts pour que ce module soit dispo de base… (surtout qu’il n’est pas dans le même langage que le projet, donc il faut deux compilos)
Oui, enfin, nginx est dispo dans beaucoup de distro. Compiler un module nginx, c'est vraiment facile ET rapide.
Bien plus que d'installer un conteneur docker qui doit avoir accès à un volume sur le disque en dehors de son conteneur je trouve. En tout cas, c'est moins alambiqué.
Après, je n'ai pas encore lu le module en Rust, peut-être qu'il ne faudra pas le recompiler à chaque version ?
Je ne sais pas si je ferai le changement. Déjà parce que j'utilise un certificat wildcard, ensuite parce que mon serveur héberge également un serveur IMAP (dovecot) SMTP (postfix), XMPP (prosody), qui ont également besoin de certificats, et donc j'aurais de toutes façons besoin d'un truc pour eux.
Mais mon cas d'utilisation n'est pas la seule vérité dans ce monde, évidemment que c'est très utile d'avoir le serveur Web qui gère tout seul le certificat :)
Autre exemple LinuxFr.org: le certificat d'un serveur/conteneur est partagé entre nginx et postfix, donc on gardera dehydrated (ou un autre client ACME) pour cela. Ça n'empêche pas l'arrivée de ce module d'être une bonne nouvelle, mais ce n'est pas la révolution/la solution qui balaie tout non plus.
# Résumé
Posté par nud . Évalué à 7 (+5/-0).
NGINX va supporter directement ACME (donc, les certificats Let's Encrypt) via un nouveau module
ngx_http_acme(implémenté en Rust). Utiliser Certbot ne sera plus nécessaire.Traefik, Caddy et Apache avaient déjà cette fonctionnalité.
[^] # Re: Résumé
Posté par steph1978 . Évalué à 4 (+2/-0).
Pour moi c'est un must have.
J'utilise Traefik car il fait de la découverte automatique (discovery) Docker. Il suffit d'annoter un container avec les bons libellés pour que Traefik mette en place les règles de routage et la prise en charge du certificat chez une autorité de certification supportant ACME (comme Let's Encrypt).
Cependant je le soupçonne de prendre beaucoup plus de CPU que nécessaire. Donc si les autres se mettent à niveau, je pourrais m'y pencher.
[^] # Re: Résumé
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Uniquement le challenge HTTP-01. Ça va sûrement de soit, mais je tiens à le préciser pour ceux qui utilisent le challenge DNS-01 par exemple.
Reste à savoir si F5 fournira des containers nginx avec se module pré-compilé. Actuellement quand on veut un module nginx, faut le compiler… en regard des sources de la version exacte de nginx. Un peu comme les modules du noyau Linux. Ça se traduit donc en général par une compilation de nginx et des modules nécessaires. Sans un ajout comme module directement disponible ça ne change pas trop la donne étant donné qu’il existait également d’autres modules nginx qui faisaient le job, juste pas éditée par F5.
Je croise donc les doigts pour que ce module soit dispo de base… (surtout qu’il n’est pas dans le même langage que le projet, donc il faut deux compilos)
[^] # Re: Résumé
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
… mais DNS-01 à l’air dans les cartons : https://github.com/nginx/nginx-acme/issues/11
Probablement à travers une socket sur laquelle vient se greffer le plugin du provider DNS qui va bien. Bonne archi à mon avis.
[^] # Re: Résumé
Posté par Glandos . Évalué à 4 (+2/-0).
Oui, enfin, nginx est dispo dans beaucoup de distro. Compiler un module nginx, c'est vraiment facile ET rapide.
Bien plus que d'installer un conteneur docker qui doit avoir accès à un volume sur le disque en dehors de son conteneur je trouve. En tout cas, c'est moins alambiqué.
Après, je n'ai pas encore lu le module en Rust, peut-être qu'il ne faudra pas le recompiler à chaque version ?
# Les clients à part seront toujours nécessaires
Posté par Glandos . Évalué à 5 (+3/-0).
Je ne sais pas si je ferai le changement. Déjà parce que j'utilise un certificat wildcard, ensuite parce que mon serveur héberge également un serveur IMAP (dovecot) SMTP (postfix), XMPP (prosody), qui ont également besoin de certificats, et donc j'aurais de toutes façons besoin d'un truc pour eux.
Mais mon cas d'utilisation n'est pas la seule vérité dans ce monde, évidemment que c'est très utile d'avoir le serveur Web qui gère tout seul le certificat :)
[^] # Re: Les clients à part seront toujours nécessaires
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
Autre exemple LinuxFr.org: le certificat d'un serveur/conteneur est partagé entre nginx et postfix, donc on gardera dehydrated (ou un autre client ACME) pour cela. Ça n'empêche pas l'arrivée de ce module d'être une bonne nouvelle, mais ce n'est pas la révolution/la solution qui balaie tout non plus.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.