Certbot not creating .wellknown/acme-challenge file

Help
1

I'm trying to setup Let's Encrypt certbot on a docker container hosted on nginx.

Since nginx is just a proxy-pass to a docker container, I'm forwarding requests to .well-known to the disk

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

and calling it like this

certbot --nginx --webroot-path /var/www/certbot -d dev.satrimono.com

It fails the validation:

Invalid response from http://dev.satrimono.com/.well-known/acme-challenge/eSVrXetc

Both nginx root and certbot consider /var/www/certbot as the root folder and should create .well-known folder inside of it.

Adding /var/www/certbot/.well-known/acme-challenge/file1.txt gets served properly.

Why is certbot not creating the needed file?

According to this command, nothing gets created there.

watch -n 0.5 ls -a /var/www/certbot

My domain is: dev.satrimono.com

I ran this command: certbot --nginx --webroot-path /var/www/certbot -d dev.satrimono.com

It produced this output: Invalid response from http://dev.satrimono.com/.well-known/acme-challenge/eSVrXetc

My web server is (include version): nginx/1.22.1

The operating system my web server runs on is (include version): Debian 6.1.85-1

My hosting provider, if applicable, is: Vultr

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): 2.1.0

2

Hi @Mystery,

The trouble is that the --webroot-path option is ignored by the --nginx plugin.

(Maybe it should give a more explicit error!)

The --nginx method (when used as an authenticator, that is, to prove control over the domain name) doesn't create a file in the filesystem at all, but instead temporarily configures nginx with some nginx logic to serve the static content required by the CA.

What you want is probably something more like

certbot -a webroot -i nginx --webroot-path /var/www/certbot -d dev.satrimono.com

In that case the specified --webroot-path will actually be used (with the webroot authenticator creating a static file at the specified location).

3 Likes
3

Still the same 404 problem.

4

What happens with your watch command? (If you want to get fancier, you could also use inotifywait!)

If you'd like to check your setup at the moment that Certbot believes it's satisfied the challenge (so for example with the file actually existing), you can add the --debug-challenges option; then you'll be prompted to press Enter to continue, so you'll have an opportunity to look at the filesystem and do whatever other tests you'd like.

1 Like
5

The file DOES get created. I can access the file from my browser.

http://dev.satrimono.com/.well-known/acme-challenge/PqIvQBg_1B14y5trRCvroFKYI3NlFn0OJHfZRaNwt3c

So then why does it fail when I press Enter?

6

Can you share more of the error output that Certbot displays from the certificate authority?

1 Like
7 
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported theseproblems:
Domain: dev.satrimono.com
Type:   unauthorized
Detail: 2001:19f0:5401:34d:5400:4ff:fee3:fe9: Invalid response from http://dev.satrimono.com/.well-known/acme-challenge/LmQ812-Q3vRaJNnyS46P-lalb-S4HpuSUk_HG23jUJc: 404
8

Thanks. Your IPv4 and IPv6 servers are returning different content. Presumably the IPv4 version is working as expected and the IPv6 version isn't. Can you check into how to harmonize their behaviors?

3 Likes
9

I was just thinking of that; saw that Facebook Debugger was returning the Default website (welcome to nginx) instead of the website.

"dev" DNA records point to the server for both IPv4 and IPv6. "2001:19f0" is indeed the right server.

nginx default website is untouched.

This is the website configuration. Not seeing anything wrong. What else am I missing?

server {
listen        80;
server_name   dev.satrimono.com;

location /.well-known/acme-challenge/ {
root /var/www/certbot;
}

location / {
proxy_pass         http://127.0.0.1:6005/;
proxy_http_version 1.1;
proxy_set_header   Upgrade $http_upgrade;
proxy_set_header   Connection $connection_upgrade;
proxy_set_header   Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header   X-Forwarded-Proto $scheme;
}
}

It's a brand new server configuration with everything set to defaults.

Disabling default.conf makes dev.satrimono.com the default server and Facebook Debugger then fetches the right data; but that's not the right solution. Is the default config bugged?

10

You are missing a listen statement for IPv6. You need one for each (v4 and v6) like:

Without that nginx will not select that server block for IPv6 incoming requests

2 Likes
11

Great it works now. Thanks!

3 Likes
12

To clarify this entanglement a bit further...
Not only does the --nginx override/conflict with --webroot.
But the webroot plugin parameter used itself is incomplete; As it requires two parts:

  • --webroot
    This part "turns on" the plugin

  • --webroot-path or -w
    This part defines the location to be used for the coming FQDN(s)

As we see below in the [highlighted] docs:
image
from: User Guide — Certbot 2.11.0.dev0 documentation (eff-certbot.readthedocs.io)

2 Likes
13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.