Error during certificate challenge: Nginx + Docker + Certbot

Hello, I've been having difficulty configuring the SSL certificate for a few days, despite having carried out the same configuration in other applications.

It is worth mentioning, the purpose of the certificate is to be installed in a docker container, whose subdomain is pointed to the host server that docker is on.
The main domain is pointed to another hosting and has another SSL certificate.

Which stack?
Docker + Certbot + Nginx

I ran this command:
Certonly --webroot -w /var/www/certbot --force-renewal --email [redacted] -d --agree-tos

It produced this output:
letsencrypt.log > 2023-09-16 05:36:01,838:DEBUG:certbot._internal.main:certbot version: 2.6.0202 -

My web server is (from docker compose):
image: nginx:latest

The operating system my web server runs on is (include version):
Host system: Debian GNU/Linux 10 (buster)
Docker: Docker Engine - Community 24.0.2 (Docker Compose version v2.18.1)

My hosting provider, if applicable, is: > hostinger (keep on this hosting provider) > hostinger (dns type "A" set name to api and content to, which is the ip address of the docker host from, other provider)

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
image: certbot/certbot

My docker compose file:

    container_name: nginx
    restart: unless-stopped
    image: nginx
        - 80:80
        - 443:443
        - ./nginx/nginx.conf:/etc/nginx/nginx.conf
        - ./certbot/conf:/etc/letsencrypt
        - ./certbot/www:/var/www/certbot
          - budesk
    image: certbot/certbot
    container_name: certbot
      - ./certbot/conf:/etc/letsencrypt
      - ./certbot/www:/var/www/certbot
      - ./certbot/log:/var/log/letsencrypt
    command: certonly --webroot -w /var/www/certbot --force-renewal --email -d --agree-tos

Nginx conf:

http {
    server_tokens off;
    charset utf-8;

    server {
        listen 80 default_server;

        server_name _;

        location ^~ /.well-known/acme-challenge/ {
            allow all;
            root /var/www/certbot;
            index index.php index.html index.htm;

        location / {

Folder structure (host)

|- cerbot
|- nginx
     |- nginx.conf
|- docker-compose.yml

I actually tried many methods, and they all point to this error, I'm thinking it might be something related to the lets-encrypt challenge validations.

The files in the subdirectories are created, including in certbot/www, but the application is not successful.

Do NOT use this option of you don't know what it actually does. What is does NOT do is magically give you a certificate while there are still validation issues. And adding this option also won't magically fix the validation errors.


Without --force-renewal the same error occurred, i don't understand how your answer could help.

certbot  | Requesting a certificate for
certbot  | 
certbot  | Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
certbot  |   Domain:
certbot  |   Type:   unauthorized
certbot  |   Detail: 2a02:4780:1:548:0:3b0c:b174:8: Invalid response from 404
certbot  | 
certbot  | 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.
certbot  | 
certbot  | Some challenges have failed.
certbot  | Ask for help or search for solutions at See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
certbot exited with code 1```

Of course it wouldn't help you fixing the issue (thus proving my point you don't understand the meaning of that option), I was merely informing you you're not using that option correctly and should not use it at all. Mis-use of the --force-renewal option can lead to other issues such as hitting rate limits. Another thing to consider with regard to hitting rate limits is that using the production environment for testing is a bad idea and you should use the staging environment until that works. Only then switch back again to the production environment.

With regard to the actual issue at hand: I might come back to that after breakfast. Until then, perhaps some other volunteer can chip in.

It seems your IPv6 address for is pointing to a different host compared to the IPv4 address. Using IPv4 nginx is replying, but using IPv6 an LiteSpeed server is responding.

Another thing that caught my eye is that you're proxy passing to the IP address, which is owned by the Bank of America. Which I find curious, as I don't have the feeling your website is associated with the Bank of America? You're not using a PUBLIC IP range as your internal PRIVATE IP range by any chance, are you? :thinking:


I was really following the tutorials on the internet and not worrying about the flags, we are in transition, this configuration will return.

But the important thing is that it worked! The problem was actually with the IPv6 address, I updated the data on the subdomain provider and now everything is fine.

Thank you very much!

I dont!! :sweat_smile: I changed it on purpose, my proxy is pointed to a service instantiated within docker.


There are unfortunately a lot of terrible, TERRIBLE guides out there.. That said, personally I would never copy/paste ANY command, especially as root, unless I've read the function of ALL the options used.

Ah OK, glad to hear that. I already thought it was very strange, as there are a lot of private IPv4 spaces to choose from.

That indeed is the important thing, for now. But rate limits are always there and if you're not careful, you'll hit one of those. So: please be careful and read the purpose of all options. And use the staging environment for testing.


Hi Osiris,
I have the same configuration as @josegabrielc, but it doesnt work. I use this command too:

command: certonly --webroot -w /var/www/certbot --email -d **** --agree-tos

Letsencrypt tries to connectet to the real Server, not the nginx server in the docker container. I can see it in the error message, with the IP:

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
certbot-tdm-c2 | Domain:
certbot-tdm-c2 | Type: unauthorized
certbot-tdm-c2 | Detail: Invalid response from 404

@Adolf1 Please open a new thread in the Help section and fill out the questionnaire. While often issues seem to be the same, the underlying issue might be completely different. And currently we lack info which is requested by the questionnaire.