Split from #3640.
From #3640
Currently the nginx plugin adds:
listen 443 ssl; # managed by Certbot
An option for HTTP 2 would be nice, either by specifying --http2
flag or just check nginx for compatibility.
listen 443 ssl http2;
listen [::]:443 ssl http2;
Any progress on the issue? In case I add http2
by hand, would it be wiped out on renew?
No. Renewing your certificate with certbot renew
won't change these lines.
Just checked my issue regarding this and saw it was closed 22 hours ago.
I guess news that the feature was added would be published here, first and foremost?
Surprisingly, rgrep -il http2 certbot-nginx
returns nothing. So it is still not implemented.
@benqzq, yes. Any news of progress on this will be added here. Topics on Let's Encrypt's community forum are closed automatically after 30 days of no activity.
I suggest adding a flag --lhttp
(the l
means "latest") so we won't lock it to a specific version of http. Though l
might be confusing (maybe --LH
?).
@benqzq Why making simple things complex? --http2
is self explanatory
Sometimes its what you need, at least a bit, but anyways, I am all in for a general notation. Either is good IMHO (--http2
or a general notation as the ones I've suggested).
This is such an important tool, I wish someone would add it already...
Just noting how I automize that until an argument will be available:
sed -i "s/listen 443 ssl;/listen 443 ssl http2;/" /etc/nginx/sites-available/$domain.conf
Is there still no way to enable http2 with certbot? Does anyone have a workaround?
@KyleTryon I gave my sed
workaround above, but it seems there is still no official way. I cannot understand that.
@bendqh That someone might be you!
Surprisingly this feature is still not added. :-)
@yw662, are you interested in submitting a pull request for it?
It is easy to workaround so……you know, if only I have time for it. I think this is the problem. The work around is easy, but changing the script is not as easy :-).
Bump for 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
would seem a lot easier...
@rowan-OzRunways Isn't this https://github.com/certbot/certbot/issues/3646#issuecomment-323814774 valid for you? Just append http2
by hand once and it shouldn't be touched on renew.
Hmm I thought it cleared. It did clear once but that may have been certbot-auto
Thanks I’ll check.
:+1: :+1: :+1: Bump
It's my birthday please add this thanks
It's amazing how many developers rely on the ambiguous (automated) configuration instead of manually requesting the certificate and tailoring a Nginx server block to their needs...
default behavior is http2 off
--http2 turns http2 on
This is a bad idea because it will turn into YEARS of copy-pasted tutorials online that assume HTTP/2 is not supported by default, which inevitably it will be eventually (and then HTTP/3).... if anything, the reverse might make more sense, to disable HTTP/2 by flag, etc. There is no reason to add fleetingly relevant command flags if you're relying on "dumb" configuration automation.
The "workaround" is manually requesting the cert:
certbot certonly --noninteractive --agree-tos --expand -m ${SSL_EMAIL} -d ${SITE_DOMAIN_ONE} -d ${SITE_DOMAIN_TWO} --webroot -w /var/www/html/
Ref: https://github.com/littlebizzy/slickstack/blob/master/ss-encrypt.txt
...and then using a custom Nginx server block, e.g.:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2 ipv6only=on;
server_name @DOMAIN;
if ($http_host != "@DOMAIN") {
return 301 $scheme://@DOMAIN$request_uri;
}
Ref: https://github.com/littlebizzy/slickstack/blob/master/nginx/default-single-site.txt
Ref: https://github.com/littlebizzy/slickstack/blob/master/nginx/nginx-conf.txt
Our nginx plugin does not currently support enabling HTTP/2 support even with a --http2
flag. That's what's being tracked by the issue.
As for our default behavior, what we've done with flags like --redirect
in the past is to initially implement support hidden behind a flag and encourage our users to try it. After it has been well tested, we can look into making it the default behavior for all users after making sure that doing so won't break (m)any configurations.
@jessuppi
It's amazing how many developers rely on the ambiguous (automated) configuration instead of manually requesting the certificate and tailoring a Nginx server block to their needs...
You completely miss the point. Of course you can do that yourself but there is a functionality that comes with the certbot client that should be improved. Whether or not you should let certbot configure your webserver is completely out of the scope of this issue.
This issue is now 4 years old. I don't think people care much whether they'd have to use a --http2
or --no-http2
flag, as long as certbot did it automagically for us.
@bmw why is there such a long delay on something that should be relatively simple - compared to all the major changes that have already been implemented in the last 4 years? Surely, the certbot team must agree that proper support to the newer versions of HTTP2 is also important...
There is actually an open PR: https://github.com/certbot/certbot/pull/7113
@bmw why is there such a long delay on something that should be relatively simple
Because there are many Certbot issues and we're a small team so we have to prioritize things. I agree this has value, we just haven't been able to get to it yet.
I'll add a priority label to this issue so we can more easily see it when looking for new projects in the future.
Hi there. I assume that even if a fix is provided for certbot to support http2
NGINX configuration, this won't fix the fact that Boundler will still be unable to perform webroot checks against HTTP/2 connections, right? cf. this link
This is about http2 on unencrypted ports. It's not really a problem here. We just want the http2 option added to the listen
directives on port 443 with encryption.
@cperrin88 Sure, but something to keep in mind is that NGINX is not able to perform a HTTP/1.1 -> HTTP/2 h2c protocol upgrade, therefore, when using the webroot validation, Boundler, the server used by let'sencrypt to perform the challenge exchange, can only assume the server speaks HTTP/1.1 and complains with the error: "Server is speaking HTTP/2 over HTTP" otherwise.
So that's something to keep in mind when a patch to this issue will come to life IMHO :)
This change shouldn't add http2 to unencrypted ports anyway. But we should keep it in mind.
Most helpful comment
From #3640
Currently the nginx plugin adds:
listen 443 ssl; # managed by Certbot
An option for HTTP 2 would be nice, either by specifying
--http2
flag or just check nginx for compatibility.