I have two domains pointing to the same server : molytov.xyz and noitworksfor.me
I have nginx configs for these subdomains set up, pointing to various selfhosted services.
molytov.xyz
fndm.molytov.xyz
imdb.molytov.xyz
lr.molytov.xyz
lx.molytov.xyz
paste.molytov.xyz
que.molytov.xyz
rss.molytov.xyz
up.molytov.xyz
wiki.molytov.xyz
www.molytov.xyz
I tried to certify my second domain yesterday and it gave me an error that was along these lines. The long string in the amce challenge URL was probably different.
I ran this command:
certbot --nginx
I then selected the domain.
It produced this output:
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: [wiki.molytov.xyz](http://noitworksfor.me)
Type: connection
Detail: 89.147.110.112: Fetching http://noitworksfor.me/.well-known/acme-challenge/6J-99oofM2iWA7mgpkI_q02PM6Ir1ObbQk8X0dkQiSo: Server is speaking HTTP/2 over HTTP
Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
I checked to visit that domain in firefox just to check, and it was showing the fndm.molytov.xyz website.
In chromium, it just tries to download an empty file.
I had to remove all my webserver configs so that website was the only one enabled in nginx, get the certificate, then re-add all my configs to the sites-enabled folder where I keep active site configs.
This is now happening across other of my subdomains where certificates are marked as insecure in my browser, pointing to the wrong websites, I'm unable to re-issue certificates too because it gives the same error.
It's all screwing up and there's no clear reason why it should be. I've had this issue with certbot several times before and it's annoying and tedious to manually edit every nginx config, revoke every certificate manually, then redo all of it. That's the only thing that seemed to be able to get past the issue. Why are configurations for different subdomains interfering with eachother?
My web server is (include version): Nginx 1.18.0
The operating system my web server runs on is (include version): Ubuntu 22.04.3
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 1.21.0
First, I see your domains just fine with both HTTP and HTTPS. I tried molytov.xyz, its fndm and wiki subdomains and your noitworksfor.me. At least, the certs are fine and the redirects are fine. (one example here)
The --nginx plugin usually works very well. But, unusual ways of configuring the server block might confuse it. Your Certbot version is a little dated. The current is 2.7.1 and the snap install is recommended for Ubuntu 22. See the Certbot install on how to install the snap version to replace your apt one. (link here)
But, before doing that we could look at your entire nginx config. Could you upload the config.txt file output from below command? You must use capital T. The file will be large
sudo nginx -T >config.txt
Or, paste that output here but please add 3 backticks before and after the output like:
```
pasted info
```
Thanks for your quick reply. Yeah I think I have things working for now, but I still feel like there's something I'm missing I need to cover to make sure what the actual issue is.
I had found that using http2 for listening on port 80 causes issues, via this Serverfault post. Does certbot not support http2?
After going through my configs, removing http2 on port 80 for all of them and reloading nginx (plus re-issuing some certificates for 2 of the subdomains I had revoked before I found the post), things seem to be working okay now.
My configs are pretty basic and identical aside from the port they listen on. This is what my search engine service's config looks like for instance:
server {
server_name lx.molytov.xyz ;
location / {
proxy_pass http://localhost:portnumberhere ;
}
listen [::]:443 ssl http2 ; # managed by Certbot
listen 443 ssl http2 ; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/lx.molytov.xyz/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/lx.molytov.xyz/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = lx.molytov.xyz) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80 ;
server_name lx.molytov.xyz ;
return 404; # managed by Certbot
}
This is after I removed the http2 for port 80, where the line originally was listen 80 http2;
This is what my nginx.conf looks like. It's pretty much all default.
So if I understand this issue correctly, use basic http listen when first setting the config, then use certbot, then manually add http2 for the ssl listen line if I want it?
I've had issues where a subdomain with an expired or revoked certificate ends up showing another site in the past, like how I had my wiki subdomain showing my fndm subdomain page. Does this have to do with Firefox? I had noticed the issue being different depending on whether I used that or chromium, so it looks like Firefox deals with revoked certificates in a weird way.
Regarding the certbot version, does certbot only update on snap now? I had removed it from my server when I set it up. If I just sudo apt autoremove, and then follow the snap setup, there won't be any issues right?
Interesting question. I am not sure and don't have time to test. But, I don't see why you would need to use that for port 80 HTTP requests. All that server block is doing is redirecting to HTTPS.
There are two possible compatibility issues. One is whether Certbot properly recognizes a listen 80 statement with http2. The other is when the Let's Encrypt Server sends the HTTP challenge to your domain whether it supports http2 for any HTTP connection (it would if redirected to HTTPS I am just not sure if it does for HTTP).
Notably, the http2 option is deprecated in nginx per its docs (quoted below)
The http2 parameter (1.9.5) configures the port to accept HTTP/2 connections. Normally, for this to work the ssl parameter should be specified as well, but nginx can also be configured to accept HTTP/2 connections without SSL.
The parameter is deprecated, the http2 directive should be used instead.
So, with all that, yes, when you choose the nginx plugin you setup the server block for port 80. When successful Certbot creates a server block for port 443 modeled on the one for port 80. The port 80 one becomes mostly a redirect to HTTPS.
If you don't like Certbot updating your nginx config you could use the --webroot option instead. You still need a port 80 server block to handle the incoming HTTP request from the Let's Encrypt server. A basic one looks like this
server {
listen 80;
listen [::]:80; # if using IPv6
server_name example.com www.example.com;
location /.well-known/acme-challenge/ {
root /var/certbot; # make/use folder as you prefer
}
location / {
return 301 https://$host$request_uri;
}
}
With --webroot you need to reload nginx after so if you don't have a cron doing that regularly anyway you could use the --deploy-hook. Example:
I'm considering transitioning to Caddy eventually, I heard it makes this stuff easier to manage. As for the nginx service, I restarted it after installing the python venv package to use certbot from pip, so everything should be okay for now.
Regarding http2, might as well remove it and just use regular http to avoid potential issues in the future.
Certbot does not do the validation, the ACME server does that.
While strictly speaking HTTP/2 is allowed without TLS, de facto it's only used in combination with TLS on port 443. Apparently the ACME protocol or Let's Encrypts implementation thereof does not allow HTTP/2 on port 80.