Certbot challenge fails internal logs have 404 error

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
cloudbaseandbeyond.duckdns.org

I ran this command:
sudo certbot --nginx -w /var/www/certbot --nginx-sleep-seconds 5

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Plugins selected: Authenticator nginx, Installer nginx

Which names would you like to activate HTTPS for?

1: cloudbaseandbeyond.duckdns.org

Select the appropriate numbers separated by commas and/or spaces, or leave input

blank to select all options shown (Enter 'c' to cancel):

Requesting a certificate for cloudbaseandbeyond.duckdns.org

Performing the following challenges:

http-01 challenge for cloudbaseandbeyond.duckdns.org

Using default address 80 for authentication.

Waiting for verification…

Challenge failed for domain cloudbaseandbeyond.duckdns.org

http-01 challenge for cloudbaseandbeyond.duckdns.org

Cleaning up challenges

Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

Domain: cloudbaseandbeyond.duckdns.org

Type: dns

Detail: DNS problem: SERVFAIL looking up A for

cloudbaseandbeyond.duckdns.org - the domain's nameservers may be

malfunctioning; no valid AAAA records found for

cloudbaseandbeyond.duckdns.org

My web server is (include version): nginx

The operating system my web server runs on is (include version):
Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

My hosting provider, if applicable, is:

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):
sudo certbot —version

certbot 1.12.0

The Lets Debug said there are no issue, go to the forum, so here I am

My server shows the following access logs, showing that the document root is accessible
23.178.112.105 - - [22/Nov/2025:13:15:03 +0000] "GET /.well-known/acme-challenge/xTxGcwzCoDARaGAuJRZG9QXghFzmoHlrMBY-ZFish3o HTTP/1.1" 404 125 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)”

149.50.96.133 - - [22/Nov/2025:13:19:38 +0000] "GET / HTTP/1.1" 403 555 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36”

65.21.146.168 - - [22/Nov/2025:13:32:53 +0000] "GET /.well-known/acme-challenge/letsdebug-test HTTP/1.1" 404 125 "-" "Mozilla/5.0 (compatible; Let's Debug emulating Let's Encrypt validation server; +https://letsdebug.net)”

66.133.109.36 - - [22/Nov/2025:13:32:58 +0000] "GET /.well-known/acme-challenge/Ppaz4gaWP4zngyM6FDmWcHNBKf0z56GnPOdcoxbb_fs HTTP/1.1" 404 125 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)”

65.21.146.168 - - [22/Nov/2025:13:33:09 +0000] "GET / HTTP/1.1" 403 125 "-" "Go-http-client/1.1”

23.178.112.212 - - [22/Nov/2025:13:37:58 +0000] "GET /.well-known/acme-challenge/YAo9jH9w6L-A6LFyNgh7iypzG2eywaaVS5ZLahbALBw HTTP/1.1" 404 125 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)”

192.168.1.1 - - [22/Nov/2025:13:39:39 +0000] "GET /.well-known/acme-challenge/under_maintenance.html HTTP/1.1" 200 197 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.1 Safari/605.1.15 Ddg/26.1"

2

The -w option doesn't do anything if you don't specify the --webroot authenticator.

1 Like
3

Welcome to the Let's Encrypt Community! :slightly_smiling_face:

There are serious issues with the duckdns nameservers.

3 Likes
4

In terms of serious issues with DuckDNS as DDNS provider, I would need more help understanding that. I’ve served services for 10 years so far without any issue.

5

I apologise for what is some sort of c&p error, there’s no ‘-w’ option listed in the help. I ran:

sudo certbot --nginx --webroot /var/www/certbot --nginx-sleep-seconds 5

6

That command makes no sense as nginx and webroot are separate authentication plugins, meaning that those are two conflicting options.

3 Likes
7

While I agree the command is incorrect, you can use the nginx plugin as just the installer with a separate authenticator.

That command is incorrect and would result in an error. The --webroot option does not allow an argument. You probably meant --webroot --webroot-path /var/www/certbot or using the short version for --webroot-path perhaps --webroot -w /var/www/certbot.

In any case, even with the correct command used and/or copy/pasted, DuckDNS' DNS is a mess and preventing you from getting a certificate.

3 Likes
8

Correct, but that's not the right way to do it, as you know. :slightly_smiling_face:

This is:
-a webroot -w WEBROOT_PATH -i nginx

2 Likes
9

Contact DuckDNS and show them the results of the DNSViz site previously linked by @griffin

There is nothing you can do. Their servers reply with inconsistent results sometimes leading to queries failing with SERVFAIL

It is not unique to Let's Encrypt it is a general DNS Server problem with DNSSEC. For example, this google DNS query test site also shows SERVFAIL: Query: cloudbaseandbeyond.duckdns.org - Google Public DNS

image
image2973×1521 220 KB

3 Likes
10

Not sure actually, I could imagine an explicitly selected authenticator overrides the --nginx implied authenticator.

1 Like
11

Might be, but I wouldn't want to bet on it. :grin:

From the certbot manual:

--nginx
Use the Nginx plugin for authentication & installation

12

Apparently Certbot doesn't like it:

Too many flags setting configurators/installers/authenticators 'nginx' -> 'webroot'

2 Likes
13

Thanks for checking this for me. :folded_hands: Much easier than my searching through the docs to determine the outcome. I can safely file this fact away in memory for future reference (so long as the devs don't vary the functionality without my knowing).

5 Likes
14

Thanks for helping. I tried:

sudo certbot --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx

Which names would you like to activate HTTPS for?

1: cloudbaseandbeyond.duckdns.org

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Requesting a certificate for cloudbaseandbeyond.duckdns.org
Performing the following challenges:
http-01 challenge for cloudbaseandbeyond.duckdns.org
Using default address 80 for authentication.
Waiting for verification...
Challenge failed for domain cloudbaseandbeyond.duckdns.org
http-01 challenge for cloudbaseandbeyond.duckdns.org
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

There’s no change in failure. Still get 404 error. Nothing left in the NGINX document root after the above command, even previous files I’d loaded. However, despite still supplying services, my goal appears unreachable even if the mysterious 404 error is resolved, as even if that is understood and resolved, you’re saying it’s a no-go for reasons I will have to research in regard to the DDNS.

PS the help has no webroot-path option. Suspect that certbot is adding files somewhere else and removing the evidence.

15

There’s a line in the log file that implies certbot is overriding the NGINX config and trying to listen to port 80, which will be ignored. So that still doesn’t explain the 404, but is somewhat misleading.

Here:
2025-11-22 15:56:47,416:DEBUG:certbot_nginx._internal.http_01:Generated server block:
[[['server'], [['listen', '80'], ['server_name', 'cloudbaseandbeyond.duckdns.org'], ['root', '/var/lib/letsencrypt/http_01_nonexistent'], [['location', '=', '/.well-known/acme-challenge/dWUsSq_U_2XB9tp556R1sr6KrgMfjPgRrh6GT0Ydqkc'], [['default_type', 'text/plain'], ['return', '200', 'dWUsSq_U_2XB9tp556R1sr6KrgMfjPgRrh6GT0Ydqkc.T4OF6vIyEGoYUVkcPySFKtcmB47Uo5tbGJu30yg7o4c']]]]]]

There’s no port 80 traffic to NGINX, as to why a 404 could come about if the above is in place is a mystery

16

With the nginx authenticator, certbot does not actually add files or directories anywhere. It temporarily modifies your nginx configuration to serve the challenge directly.

2 Likes
17

The HTTP-01 challenge must be reachable externally on port 80 (or via redirection from port 80 to port 443).

2 Likes
18

I redirect to port 8080 atm - so can try that change

19

If you redirected external port 80 to internal port 8080 then you need to use:

--http-01-port 8080

3 Likes
20

Thank you - that’s not a listed option and has got rid of the 404 error as you nicely pointed out:
23.178.112.212 - - [22/Nov/2025:16:29:24 +0000] "GET /.well-known/acme-challenge/g3xSM0wqGai49hsWH6uiJNC4m8u_kicgo4bh9LTot6s HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)”

185.247.137.210 - - [22/Nov/2025:16:29:25 +0000] "GET / HTTP/1.1" 403 125 "-" "Mozilla/5.0 (compatible; InternetMeasurement/1.0; +https://internet-measurement.com/)”

35.166.205.103 - - [22/Nov/2025:16:29:27 +0000] "GET /.well-known/acme-challenge/g3xSM0wqGai49hsWH6uiJNC4m8u_kicgo4bh9LTot6s HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)”

13.213.1.239 - - [22/Nov/2025:16:29:28 +0000] "GET /.well-known/acme-challenge/g3xSM0wqGai49hsWH6uiJNC4m8u_kicgo4bh9LTot6s HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)”

16.171.135.225 - - [22/Nov/2025:16:29:35 +0000] "GET /.well-known/acme-challenge/g3xSM0wqGai49hsWH6uiJNC4m8u_kicgo4bh9LTot6s HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)”

18.219.82.236 - - [22/Nov/2025:16:29:35 +0000] "GET /.well-known/acme-challenge/g3xSM0wqGai49hsWH6uiJNC4m8u_kicgo4bh9LTot6s HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)”

Now down to the overall issue, not happy with DDNS provider:
Some challenges have failed.

IMPORTANT NOTES:

THANKS!

2 Likes