Acme Challenge 404 Invalid Response

My domain is:
vrlab.ddns.net

I ran this command:
sudo certbot --nginx -d vrlab.ddns.net -v

It produced this output:

Plugins selected: Authenticator nginx, Installer nginx
Requesting a certificate for vrlab.ddns.net
Performing the following challenges:
http-01 challenge for vrlab.ddns.net
Waiting for verification...
Challenge failed for domain vrlab.ddns.net
http-01 challenge for vrlab.ddns.net

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: vrlab.ddns.net
  Type:   unauthorized
  Detail: 193.159.50.206: Invalid response from http://vrlab.ddns.net/.well-known/acme-challenge/puQGiYcQorDYPn1Uhhtl4TtnxNeWEbi_Brc_Oog1XIg: 404

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.

Cleaning up challenges
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.

My web server is: nginx 1.18.0

The operating system my web server runs on is: Ubuntu 22.04.1 LTS

My hosting provider, if applicable, is: selfhosted

DNS Provider: noip.com

I can login to a root shell on my machine: yes

I'm using a control panel to manage my site: no

The version of my client is: 1.32.0

Good Morning!

I'm trying to get a certificate to connect to my MongoDB Server with TLS encryption.
My Setup is a little bit complicated. I'm running the nginx server on a virtual machine listening on port 8080. My router is routing traffic from port 80 to port 8080. So it basically looks like that:
client -p80-> router -p8080-> host -p8080-> vm with nginx.

A bit complicated but it works. I can access the default page of nginx over http://vrlab.ddns.net/. I created a test file at webhost/.well-known/acme-challenge/test, which I can also access over the Internet: http://vrlab.ddns.net/.well-known/acme-challenge/test

Thank you for any help!

Welcome to the community @kermal

Your setup looks to be working fine to reach nginx on port 80.

Could you have tried running certbot --nginx when nginx was not running? Because odd things, like a 404, can occur when you do that.

Would you restart your server, ensure nginx is running, and then try certbot again.

If that doesn't work please upload the certbot log at /var/log/letsencrypt/letsencrypt.log. You will need to copy that to a .txt file for upload.

5 Likes

Hey thanks for the reply!

I restarted the server and confirmed that I still can access nginx over the internet. Certbot however gets the same error message.

Thank you for your help!
letsencrypt-log.txt (20.4 KB)

2 Likes

The log does not show any server blocks. But, it does see a file in /sites-enabled/

Can you show contents of this file:

/etc/nginx/sites-enabled/default
4 Likes

Yes that's the file:
default.txt (2.4 KB)

1 Like

Oh, right. I think the problem is because you need to use listen 8080

I don't think that works with --nginx plug-in. You might try adding a listen 80; in that default file server block. That should allow the plug-in to use that server block as authenticator. It will also use it as a model to setup an https server block (port 443). This listen won't actually do anything since you are handling port 80 in your router. It is just to "fake out" the plug-in

OR, switch to using --webroot authentication. That will get a cert but won't update your nginx config so you'll have to setup an https server block manually. The Mozilla configurator is a good tool for that.

4 Likes

I'm not sure about the port 8080, but you can do -a webroot -i nginx to combine both.

2 Likes

You are a genius @MikeMcQ !
Thank you for your help, it worked!

2 Likes

Normally you can combine -a webroot with -i nginx but in this case I don't think what would have worked. The nginx plug-in uses the http server block as a model to install the https server block. But, it didn't find one to update for authentication so wouldn't have one as a model either.

The log file normally shows the server block(s) the nginx plug-in changed for authentication. In this case none was shown even though one server block was defined and the plug-in backed it up. I concluded it did not identify the listen 8080; server block as an http block.

I'd like to test permutations around this idea but spare time does not allow that today :slight_smile:

3 Likes

The webserver plugins often work differently for authentication compared to the installation code. It might work, it might not. I just don't know and would have tried/suggested it instead of assuming it didn't work :wink:

1 Like

I actually suggested two ways I thought both would work. Webroot by itself needs manual config for https server block. That's a fact

You were proposing a third option. We don't know that "you can do" that in this case. It might be worth trying before assuming it would :slight_smile:

3 Likes

You can do it (as in, the command to combine both plugins), I didn't say it would work :wink:

3 Likes