Certbot: Prise en charge HTTP2 dans le plug-in Nginx

À partir de #3640

Actuellement, le plugin nginx ajoute :
listen 443 ssl; # managed by Certbot

Une option pour HTTP 2 serait bien, soit en spécifiant l'indicateur --http2 , soit en vérifiant simplement la compatibilité de nginx.

listen 443 ssl http2;
listen [::]:443 ssl http2;

Des avancées sur la question ? Si j'ajoute http2 à la main, serait-il effacé lors du renouvellement ?

Non. Renouveler votre certificat avec certbot renew ne changera pas ces lignes.

Je viens de vérifier mon problème à ce sujet et j'ai vu qu'il était fermé il y a 22 heures.

Je suppose que la nouvelle de l'ajout de la fonctionnalité serait publiée ici, en premier lieu ?

Étonnamment, rgrep -il http2 certbot-nginx ne renvoie rien. Elle n'est donc toujours pas mise en œuvre.

@benqzq , oui. Toute nouvelle de progrès à ce sujet sera ajoutée ici. Les sujets du forum communautaire de Let's Encrypt sont fermés automatiquement après 30 jours d'inactivité.

Je suggère d'ajouter un indicateur --lhttp (le l signifie "le plus récent") afin de ne pas le verrouiller sur une version spécifique de http. Bien que l puisse prêter à confusion (peut-être --LH ?).

@benqzq Pourquoi compliquer les choses simples ? --http2 est explicite

• le comportement par défaut est http2 désactivé
• --http2 active http2

Parfois, c'est ce dont vous avez besoin, au moins un peu, mais de toute façon, je suis tout à fait d'accord pour une notation générale. L'un ou l'autre est bon à mon humble avis ( --http2 ou une notation générale comme celles que j'ai suggérées).

C'est un outil tellement important, j'aimerais que quelqu'un l'ajoute déjà...

Notant simplement comment j'automatise cela jusqu'à ce qu'un argument soit disponible:

sed -i "s/listen 443 ssl;/listen 443 ssl http2;/" /etc/nginx/sites-available/$domain.conf

N'y a-t-il toujours aucun moyen d'activer http2 avec certbot ? Quelqu'un at-il une solution de contournement?

@KyleTryon J'ai donné ma solution de contournement sed ci-dessus, mais il semble qu'il n'y ait toujours pas de moyen officiel. Je ne peux pas comprendre ça.

@bendqh Ce quelqu'un pourrait être vous !

Étonnamment, cette fonctionnalité n'est toujours pas ajoutée. :-)

@yw662 , souhaitez-vous soumettre une demande d'extraction ?

Il est facile de contourner le problème, alors …… vous savez, si seulement j'ai le temps. Je pense que c'est ça le problème. Le travail autour est facile, mais changer le script n'est pas aussi facile :-).

Coup de coeur pour 2019.

0 0,12 * * * certbot renew --quiet
1 0,12 * * * sed -i "s/listen 443 ssl;/listen 443 ssl http2;/" /etc/nginx/sites-available/default
2 0,12 * * * sed -i "s/443 ssl ipv6only=on;/443 ssl http2 ipv6only=on;/" /etc/nginx/sites-available/default
3 0,12 * * * systemctl nginx reload

--http2 semblerait beaucoup plus facile...

@rowan-OzRunways N'est-ce pas https://github.com/certbot/certbot/issues/3646#issuecomment -323814774 valable pour vous ? Ajoutez simplement http2 à la main une fois et il ne devrait pas être touché lors du renouvellement .

Hmm, je pensais que c'était effacé. Il s'est effacé une fois, mais c'était peut-être certbot-auto Merci, je vais vérifier.

:+1: :+1: :+1: Coup
C'est mon anniversaire s'il vous plait ajoutez ceci merci

C'est incroyable de voir combien de développeurs s'appuient sur la configuration ambiguë (automatisée) au lieu de demander manuellement le certificat et d'adapter un bloc de serveur Nginx à leurs besoins...

le comportement par défaut est http2 désactivé
--http2 active http2

C'est une mauvaise idée car cela se transformera en ANNÉES de didacticiels copiés-collés en ligne qui supposent que HTTP/2 n'est pas pris en charge par défaut, ce qui finira inévitablement par être (et ensuite HTTP/3).... si quoi que ce soit, l'inverse pourrait avoir plus de sens, désactiver HTTP/2 par indicateur, etc.

La "solution de contournement" demande manuellement le certificat :

certbot certonly --noninteractive --agree-tos --expand -m ${SSL_EMAIL} -d ${SITE_DOMAIN_ONE} -d ${SITE_DOMAIN_TWO} --webroot -w /var/www/html/

Réf : https://github.com/littlebizzy/slickstack/blob/master/ss-encrypt.txt

... puis en utilisant un bloc de serveur Nginx personnalisé, par exemple :

server {
listen                 443 ssl http2;
listen                 [::]:443 ssl http2 ipv6only=on;
server_name            @DOMAIN;
    if ($http_host != "@DOMAIN") {
        return 301            $scheme://@DOMAIN$request_uri;
    }

Réf : https://github.com/littlebizzy/slickstack/blob/master/nginx/default-single-site.txt
Réf : https://github.com/littlebizzy/slickstack/blob/master/nginx/nginx-conf.txt

Notre plug-in nginx ne prend actuellement pas en charge l'activation de la prise en charge HTTP/2, même avec un indicateur --http2 . C'est ce qui est suivi par le problème.

En ce qui concerne notre comportement par défaut, ce que nous avons fait avec des drapeaux comme --redirect dans le passé, c'est d'implémenter initialement un support caché derrière un drapeau et d'encourager nos utilisateurs à l'essayer. Une fois qu'il a été bien testé, nous pouvons envisager d'en faire le comportement par défaut pour tous les utilisateurs après nous être assurés que cela ne cassera (m) aucune configuration.

@jessuppi

C'est incroyable de voir combien de développeurs s'appuient sur la configuration ambiguë (automatisée) au lieu de demander manuellement le certificat et d'adapter un bloc de serveur Nginx à leurs besoins...

Vous passez complètement à côté de l'essentiel. Bien sûr, vous pouvez le faire vous-même, mais il existe une fonctionnalité fournie avec le client certbot qui devrait être améliorée. Que vous deviez ou non laisser certbot configurer votre serveur Web est complètement hors de portée de ce problème.

Ce numéro a maintenant 4 ans . Je ne pense pas que les gens se soucient beaucoup de savoir s'ils doivent utiliser un drapeau --http2 ou --no-http2 , tant que certbot le fait automatiquement pour nous.

@bmw pourquoi y a-t-il un si long retard sur quelque chose qui devrait être relativement simple - par rapport à tous les changements majeurs qui ont déjà été mis en œuvre au cours des 4 dernières années ? Certes, l'équipe certbot doit convenir qu'une prise en charge appropriée des nouvelles versions de HTTP2 est également importante...

Il existe en fait un PR ouvert : https://github.com/certbot/certbot/pull/7113

@bmw pourquoi y a-t-il un si long retard sur quelque chose qui devrait être relativement simple

Parce qu'il y a beaucoup de problèmes avec Certbot et que nous sommes une petite équipe, nous devons donc prioriser les choses. Je suis d'accord que cela a de la valeur, nous n'avons tout simplement pas encore pu y accéder.

J'ajouterai une étiquette de priorité à ce problème afin que nous puissions le voir plus facilement lors de la recherche de nouveaux projets à l'avenir.

Salut. Je suppose que même si un correctif est fourni pour que certbot prenne en charge la configuration http2 NGINX, cela ne résoudra pas le fait que Boundler ne pourra toujours pas effectuer de vérifications Webroot par rapport aux connexions HTTP/2, n'est-ce pas ? cf. ce lien

Il s'agit de http2 sur des ports non chiffrés. Ce n'est pas vraiment un problème ici. Nous voulons juste que l'option http2 soit ajoutée aux directives listen sur le port 443 avec chiffrement.

@ cperrin88 Bien sûr, mais quelque chose à garder à l'esprit est que NGINX n'est pas en mesure d'effectuer une mise à niveau du protocole HTTP/1.1 -> HTTP/2 h2c , donc, lors de l'utilisation de la validation webroot, Boundler, le serveur utilisé par let'sencrypt pour effectuer l'échange de défi, ne peut que supposer que le serveur parle HTTP/1.1 et se plaint avec l'erreur : "Le serveur parle HTTP/2 sur HTTP" sinon.

C'est donc quelque chose à garder à l'esprit lorsqu'un patch à ce problème prendra vie à mon humble avis :)

Cette modification ne devrait de toute façon pas ajouter http2 aux ports non chiffrés. Mais nous devrions garder cela à l'esprit.