I am currently having issues with the challenges on my docker configuration

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:

I ran this command:
docker compose -f docker-compose.letsencrypt.yml run --rm --entrypoint "/bin/sh -c"
-e "CERTBOT_DEBUG=1" certbot "certbot certonly -v --debug
--webroot
--webroot-path=/var/www/certbot
--email 'REAL EMAIL'
--agree-tos
--no-eff-email
-d kinonight.com
-d www.kinonight.com"

It produced this output:
[+] Creating 1/1
:check_mark: Container kinoboard_app Running 0.0s
[+] Running 2/2
:check_mark: Container kinoboard_app Healthy 0.5s
:check_mark: Container kinoboard_nginx Started 0.0s
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Requesting a certificate for kinonight.com
Performing the following challenges:
http-01 challenge for kinonight.com
Using the webroot path /var/www/certbot for all unmatched domains.
Waiting for verification...
Challenge failed for domain kinonight.com
http-01 challenge for kinonight.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: kinonight.com
Type: connection
Detail: HOME IP: Fetching http://kinonight.com/.well-known/acme-challenge/MsDepYnKERaYbHvCfmKPp-0qQp8FyrkT8iHa1NAxdo4: Connection refused

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.

Cleaning up challenges
Exiting abnormally:
Traceback (most recent call last):
File "/usr/local/bin/certbot", line 10, in
sys.exit(main())
^^^^^^
File "/opt/certbot/src/certbot/src/certbot/main.py", line 18, in main
return internal_main.main(cli_args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/certbot/src/certbot/src/certbot/_internal/main.py", line 1850, in main
return config.func(config, plugins)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/certbot/src/certbot/src/certbot/_internal/main.py", line 1562, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/certbot/src/certbot/src/certbot/_internal/main.py", line 141, in _get_and_save_cert
lineage = le_client.obtain_and_enroll_certificate(domains, certname)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/certbot/src/certbot/src/certbot/_internal/client.py", line 526, in obtain_and_enroll_certificate
cert, chain, key, _ = self.obtain_certificate(domains)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/certbot/src/certbot/src/certbot/_internal/client.py", line 427, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/certbot/src/certbot/src/certbot/_internal/client.py", line 505, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/certbot/src/certbot/src/certbot/_internal/auth_handler.py", line 104, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
File "/opt/certbot/src/certbot/src/certbot/_internal/auth_handler.py", line 208, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: 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.
/bin/sh: -d: not found
My web server is (include version):
nginx/1.29.1
The operating system my web server runs on is (include version):
Docker:Alpine3.20
My hosting provider, if applicable, is:
Epik
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):
certbot:latest

2

Hmm. HTTP requests to your domain (port 80) get a reply from an nginx v1.24 (not 1.29.1) which says its on Ubuntu.

Can you explain the mis-match?

HTTP request to: kinonight.com,port 80, Address Type=IPv4,Server=nginx/1.24.0 (Ubuntu),HTTP Status=404]

I get a successful connect on HTTP. Not a "Connection Refused".

2 Likes
3

I was running it on an alpine-based container and those were the results I got from the running the version commands.

4

So, is that nginx 1.24 (Ubuntu) running in your host rather than a container?

If you explain more about the web servers you have and your container configuration maybe we can help. Here is some background about how this works. Maybe this will be enough for you to know what you need to do.

When you run Certbot to get a cert using --webroot it makes a request to the Let's Encrypt server. The LE Server, in turn, makes a request to your domain name using HTTP on port 80. Your server must reply with the challenge token setup by Certbot. LE sends that request to the IP in the public DNS system.

The error indicates the request from LE to you was "refused" (by your system).

That is a little puzzling because right now requests to your domain do get answered. But, by this nginx 1.24 Ubuntu server.

People often make mistakes setting up containers. A common mistake is not routing inbound port 80 requests from your host to the correct container (or service). Your server that replies to the LE challenge request must have access to the --webroot-path you used in the Certbot command. It needs that so it can find the correct challenge token to send back to LE. If that nginx is not in the same container as Certbot then you must share the volume so that nginx can see it.

3 Likes