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

• default behavior is http2 off
• --http2 turns http2 on

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 #3646 (comment) 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.

👍 👍 👍 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: #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.

Any updates on this? Today, after spending ages troubleshooting performance on websites I manage behind nginx, I found that nginx/certbot config does not use http2. As we are in 2021 now I assumed that everyone everywhere was using HTTP/2 only to find out that this is not the case. I'd really like to have an --http2 flag to use with certbot so I don't have to do sed -i "s/listen 443 ssl;/listen 443 ssl http2;/" /etc/nginx/conf.d/certbot-rewrite.conf in my script. Just make it the default already...the challenge is done over http and not https anyway so that is irrelevant. All that's needed is a simple one word addition to the default config - everyone should be using HTTP/2 by default now anyway.
Thanks for considering this.

2022 bump

2023 bump

2023 April bump

2023 April 20 bump

2023 may 21 bump

2023 june 6 bump

Just a heads up,

Since nginx 1.25.1, the "listen ... http2" directive is deprecated, use the "http2" directive instead

the old format is

server {
    listen      x.x.x.x:443 ssl http2;

and the new format for nginx >= 1.25.1 is

server {
    listen      x.x.x.x:443 ssl;
    http2  on;

2024 Jan 8 bump

I opened a PR, corrections and suggestions are welcome

2024 March 4 bump