Certbot fails with "unauthorized" (NGINX)

Help
1

Hello,

I'm struggling with issuing a certificate using Certbot (v2.1.0) with the NGINX. I've tried both certbot --nginx and certbot certonly --nginx, but always get the following error:

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

Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: project.domain.ee
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Requesting a certificate for project.domain.ee

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: project.domain.ee
  Type:   unauthorized
  Detail: 109.235.247.86: Invalid response from https://project.domain.ee/.well-known/acme-challenge/BlVs6cuy03mTqUXWw9lEcs1wqWUACLlwx4y6U4EG0JU: 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.

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.

log:

2025-07-28 14:22:48,241:INFO:certbot._internal.auth_handler:Cleaning up challenges
2025-07-28 14:22:49,328:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 33, in <module>
    sys.exit(load_entry_point('certbot==2.1.0', 'console_scripts', 'certbot')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 19, in main
    return internal_main.main(cli_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 1736, in main
    return config.func(config, plugins)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 1440, in run
    new_lineage = _get_and_save_cert(le_client, config, domains,
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 138, in _get_and_save_cert
    lineage = le_client.obtain_and_enroll_certificate(domains, certname)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/client.py", line 516, in obtain_and_enroll_certificate
    cert, chain, key, _ = self.obtain_certificate(domains)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/client.py", line 428, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/client.py", line 496, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/auth_handler.py", line 106, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/_internal/auth_handler.py", line 206, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.
2025-07-28 14:22:49,330:ERROR:certbot._internal.log:Some challenges have failed.

Environment:

  • OS: Debian 12
  • Certbot version: 2.1.0

NGINX config:

server {
    listen 80;
    server_name project.domain.ee;

    location /api/ {
        include uwsgi_params;
        uwsgi_pass unix:///var/www/project/uwsgi.sock;
    }

    location /static/ {
        alias /var/www/project/backend/staticfiles/;
    }

    location / {
        root /var/www/project/frontend/dist;
        index index.html;
        try_files $uri /index.html;
    }
}
2

Welcome to the Let's Encrypt Community.

You need to use a valid domain. The one you have shared here does not exist. If you just made that one up, please don't do that. If you think it is important to hide your real domain, there are special reserved names (like example.com). Please use one of those, so it is obvious that you are not sharing the real domain. Do note that without the real domain, it becomes close to impossible for anyone to offer you assistance.

3 Likes
3

Fully agree with @linkp that by not using your actual domain it makes it very difficult to help

If that is your actual public IP that connects to an NPM (Nginx Proxy Manager) system. You should contact their support. Problems with that are almost always some kind of config problem within NPM

3 Likes
4

A post was split to a new topic: Error with Certbot --apache option

5

As a summary of how it should work:

  • You request a cert from Let's Encrypt for your domain x.y.com, using the default HTTP domain validation

  • Let's Encrypt checks your domain for the "challenge response" using an HTTP request, the response it's looking for should be populated by certbot.

  • For HTTP responses to work, the http request needs to reach your nginx server so it can respond.

  • They start a connection to the IP pointed to by your domain in DNS, on TCP port 80 (HTTP).

  • Whatever is on that IP will then decide whether to respond (usually a router with it's own firewall configuration), it will then decide what to do with the connecting and in most cases that involves forwarding it to the internal IP of your server and having that handle the response.

So basically your nginx is currently not able to respond to public HTTP requests and all of this won't work until it does. How you host nginx (on a VM, hardware, in containers etc) matters and you need to be pretty clued up on network administration.

1 Like
6

Thank you.
The domain we are working with is project.ampere.ee.