Certbot failed to authenticate some domains

Help
1

Hi, I've been using your certificates on one of my servers for years.
I'm migrating that server and I'm getting an error when I try to generate the certificate on the new server:

Simulating a certificate request for correo.asistp.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: correo.asistp.com
Type: unauthorized
Detail: 46.105.169.143: Invalid response from http://correo.asistp.com/.well-known/acme-challenge/VoHLBV19kt3pGfEFIRpcQ3kkzjltQqbm_rKoi6ezY_A: 404

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded 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.

The error log shows:

2025-03-28 18:16:20,841:DEBUG:acme.client:Storing nonce: txq0Fkjd2dINGjyP70Kv6iEINGOM_54DJVpxdeYPyQa6gcYWRfA
2025-03-28 18:16:20,842:INFO:certbot._internal.auth_handler:Challenge failed for domain correo.asistp.com
2025-03-28 18:16:20,843:INFO:certbot._internal.auth_handler:http-01 challenge for correo.asistp.com
2025-03-28 18:16:20,843:DEBUG:certbot._internal.display.obj:Notifying user:
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: correo.asistp.com
Type: unauthorized
Detail: 46.105.169.143: Invalid response from http://correo.asistp.com/.well-known/acme-challenge/VoHLBV19kt3pGfEFIRpcQ3kkzjltQqbm_ rKoi6ezY_A: 404

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains s erve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

2025-03-28 18:16:20,845:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/_internal/auth_handler.py", line 108, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/_internal/auth_handler.py", line 212, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.

2025-03-28 18:16:20,845:DEBUG:certbot._internal.error_handler:Calling registered functions
2025-03-28 18:16:20,846:INFO:certbot._internal.auth_handler:Cleaning up challenges
2025-03-28 18:16:20,846:DEBUG:certbot._internal.plugins.webroot:Removing /var/www/html/.well-known/acme-challenge/VoHLBV19kt3pGfEFIRp cQ3kkzjltQqbm_rKoi6ezY_A
2025-03-28 18:16:20,846:DEBUG:certbot._internal.plugins.webroot:All challenges cleaned up
2025-03-28 18:16:20,847:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
File "/snap/certbot/4482/bin/certbot", line 8, in
sys.exit(main())
^^^^^^
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/main.py", line 19, in main
return internal_main.main(cli_args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/_internal/main.py", line 1871, in main
return config.func(config, plugins)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/_internal/main.py", line 1577, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/_internal/main.py", line 142, in _get_and_save_cert
lineage = le_client.obtain_and_enroll_certificate(domains, certname)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/_internal/client.py", line 513, in obtain_and_enroll_certificate
cert, chain, key, _ = self.obtain_certificate(domains)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/_internal/client.py", line 423, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/_internal/client.py", line 492, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/_internal/auth_handler.py", line 108, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
File "/snap/certbot/4482/lib/python3.12/site-packages/certbot/_internal/auth_handler.py", line 212, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.
2025-03-28 18:16:20,852:ERROR:certbot._internal.log:Some challenges have failed.

I have:

Rocky Linux release 9.5
nginx 1.20.1
certbot 3.3.0
Hosting provider OVH

The Let's Debug diagnostic website tool show fine results

Please help me identify and correct the problem.

2

Hello @dld75, welcome to the Let's Encrypt community. :slightly_smiling_face:

Please show the output of each of the following commands

  • sudo certbot certificates
  • sudo nginx -T that is a capital T
1 Like
3

Does the public DNS use the public IP of your new server?

Because the '404' in the error message is for an HTTP Not Found. If the DNS was still pointing at the old server it would return a 404 to the HTTP Challenge.

If so, is the 'root' folder in your new server for this domain a match for the folder used in the webroot path (usually the -w folder). It looks like Certbot is using (or defaulting to) /var/www/html

Is that the root or default root on your new server?

2 Likes
4

Hi, thanks for responding.

The DNS points to my new server's IP.
The /var/www/html path is correct because it's the default for nginx.

5

Then please show the entire output of

sudo nginx -T

If you can, upload the config.txt resulting from

sudo nginx -T >config.txt

The 404 error is usually pretty easy to diagnose. Certbot places a file in the webroot directory you tell it. Which we see is /var/www/html from its logs

The Let's Encrypt server sends a request to the server at the public IP in the DNS. That server must be able to find the file in the same place Certbot placed it.

That's how it should work and the 404 means your server said it could not find that file for that domain and IP.

By the way, the nginx default for root, per its docs, is simply html not /var/www/html. See: Module ngx_http_core_module

1 Like
6

Hi Bruce, thanks for the welcome.
Regarding the commands:

certbot certificates

Saving debug log to /var/log/letsencrypt/letsencrypt.log

No certificates found.

nginx -T

The result is very extensive, so it's better to compare the results between the old and new servers:

diff nginx_old nginx_new

232a233

root /opt/www/well_known;

234,235d234
< access_log off;
< log_not_found off;
237d235
< #root /var/www/html;
570,571c568,578
< # Redirect all insecure http:// requests to https://
< return 301 https://$host$request_uri;

# Allow ACME challenge to be served over HTTP (don't redirect to HTTPS).
location ~* ^/.well-known/acme-challenge/ {
    root /opt/www/well_known;
    try_files $uri =404;
    allow all;
}

# Redirect all insecure http requests to https.
location / {
    return 301 https://$host$request_uri;
}

Is that enough information?
From what I see, it seems to be an error in the nginx route.

1 Like
7

File contents on the new server:

cat /etc/nginx/sites-available/00-default.conf

Note: This file must be loaded before other virtual host config files,

HTTP
server {
# Listen on ipv4
listen 80;
listen [::]:80;

server_name _;

# Allow ACME challenge to be served over HTTP (don't redirect to HTTPS).
location ~* ^/.well-known/acme-challenge/ {
    root /opt/www/well_known;
    try_files $uri =404;
    allow all;
}
# Redirect all insecure http requests to https.
location / {
    return 301 https://$host$request_uri;
}

}

8

It really would be more comprehensive to show the entire nginx -T output
People make mistakes of all kinds even like having an include in their base nginx.conf for sites-enabled but only setting up conf files in sites-available, as just one example.

But, assuming the below conf file is actually part of your new server active conf:

It has this for the root folder for HTTP Challenges

That folder does not match what you told Certbot (which was /var/www/html)

With the above server block you would use

sudo certbot certonly --webroot -w /opt/www/well_known -d correo.asistp.com

BUT, I note that this server block uses a default server_name value. Normally it is best practice to have a server block that explicitly names the domain(s) it applies to.

3 Likes
10

I already did. For your nginx config you should try the below command. What was the output of that command?

The -w path must match what you have for your HTTP server block which is

server {
    # Listen on ipv4
    listen 80;
    listen [::]:80;

    server_name _;

    # Allow ACME challenge to be served over HTTP (don't redirect to HTTPS).
    location ~* ^/.well-known/acme-challenge/ {
        root /opt/www/well_known;
        try_files $uri =404;
        allow all;
    }

    # Redirect all insecure http requests to https.
    location / {
        return 301 https://$host$request_uri;
    }
}
4 Likes
11

Thanks for your help, that was the solution

2 Likes
12

Sure, no problem. I should have also suggested using a --deploy-hook with --webroot. This will make sure your nginx is reloaded whenever you get a fresh cert (on renewal).

You can add one now with this.

sudo certbot reconfigure --cert-name correo.asistp.com --deploy-hook "sudo systemctl reload nginx"

If that isn't the correct reload command on your system change it to the correct one.

The reconfigure will ask if you want to run the deploy hook with "dry run". For this reload just choose "D" for "Do not run deploy hook". You could also choose R for "Run Deploy Hooks" it just isn't helpful for a simple reload like this.

This won't affect anything else about your certs or nginx system. It will just add the reload of nginx the next time your cert is renewed (in about 60 days).

2 Likes