Certbot fails to issue certificate for my dockerized backend api

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: pdfchatterapi.largent.org

I ran this command: sudo certbot certonly --standalone

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): pdfchatterapi.largent.org
Requesting a certificate for pdfchatterapi.largent.org

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: pdfchatterapi.largent.org
Type: connection
Detail: 129.154.250.228: Fetching http://pdfchatterapi.largent.org/.well-known/acme-challenge/xBCBsxdgUHYw0gjQiAaTKliwavChbZcXCX0TJ9-mxg4: Error getting validation data

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections 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.

My web server is (include version):

The operating system my web server runs on is (include version):

Ubuntu 20.04.6 LTS (GNU/Linux 5.15.0-1068-oracle aarch64)

My hosting provider, if applicable, is: oracle cloud

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 3.0.1

Additional information:

My backend api is dockerize and when I run the docker image, I can accessed the backend api everywhere.

Here's the working link: http://129.154.250.228:8000/

I have stopped running the docker for now and the domain above may not work.

My goal is to simply port :
"http://129.154.250.228:8000/" to "https://pdfchatterapi.largent.org:8000/"

But don't really know why the let's encrypt's certbot is spitting errors.

The security ingress rules have also been set for 80, 8000, 443, 22 with CIDR: 0.0.0.0/0.

I access my ubuntu os by SSHing using PuTTY.

If the public IP isn't working, how can I successfully SSH into Ubuntu using the said IP then?

Thanks.

2

That will make it difficult for us to look at then :slight_smile:

The --standalone option uses an HTTP Challenge. This requires the Let's Encrypt authentication server to reach you using a request like this:

http://(domain)/.well-known/acme-challenge/(token)

This uses port 80. You can setup your container to listen on other ports. And, use the option to tell --standalone to listen on an alternate port.

BUT, the original request comes to port 80. You would have to map that to your alternate port and still reply to the original request properly.

Debugging the standalone is more difficult than other methods because there is only a listener for the challenge when that is running. I am not sure if the below helps with a container but if Certbot was running in the host you could:

=============================

The --standalone method is difficult to debug because you need to keep Certbot running to test connection from the public internet.

A way to test this easier is to use these command options

certbot certonly --standalone --dry-run --debug-challenges -v -d (domain)

This command will show you the challenge URL to try from the public internet and the proper response. After showing you this it will say "Press Enter to Continue". DO NOT PRESS ENTER.

Leave it paused like that and use a different device to test connection. You can use a mobile phone with wifi disabled so use your carrier's network.

You do not have to use the full URL. Just try http://(yourdomain)

If the connection works this shorter URL should see a response like below. Otherwise, continue to adjust your local comms setup until it works.

ACME client standalone challenge solver
2 Likes
3

Hello Mike.

I've tried your suggestions and it is not working still. Take a look at the commnad I ran on ubuntu through PuTTY.

certbot
certbot827×523 17.5 KB

After doing this, tried accessing the link from my smartphone connected to the internet using mobile data and the response is:

"This site can't be reached".

Also, try the backend api link now, it's up.

Any other solutions. Please ask if more details are required.

4

I can reach your server using the IP address and port 8000. But, you need to get inbound HTTP requests working that use your domain name and port 80.

This is not just a Let's Encrypt issue. Even requests to your "home" page fail.

There are many ways to configure container systems. You may need to consult a Docker or uvicorn forum for help.

# HTTP requests to home page fail
curl -i http://pdfchatterapi.largent.org/
curl: (7) Failed to connect to pdfchatterapi.largent.org port 80 after 261 ms: 
No route to host

# This is sample URL that needs to work too for HTTP Challenge
curl -i http://pdfchatterapi.largent.org/.well-known/acme-challenge/Test404
curl: (7) Failed to connect to pdfchatterapi.largent.org port 80 after 215 ms: 
No route to host

# This test works
curl -i http://129.154.250.228:8000/
HTTP/1.1 200 OK
server: uvicorn

If you can't sort out the HTTP flows you could consider a DNS Challenge. But, many people use HTTP Challenge and containers. You just need to set your comms and port routing up properly.

You might consider running Certbot in the host and just share the cert folder as a volume with your container. That might simplify the comms/port routing.

2 Likes
6

By the way, do you think the following could be the culprit as I'm using port 80 in my docker file:

Tell uvicorn to start spin up our code, which will be running inside the container now

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "80"]

Since certbot uses port 80 by default, I suspect running my image on port 80 could cause conflicts but I'm not sure.

I also spotted that the following test works:

curl -I http://pdfchatterapi.largent.org:8000/
HTTP/1.1 405 Method Not Allowed
date: Tue, 07 Jan 2025 15:11:43 GMT
server: uvicorn
allow: GET
content-length: 31
content-type: application/json

Thanks.

7

Just to be clear ... Certbot isn't using port 80. It makes outbound HTTPS requests on port 443 to the Let's Encrypt API server.

But, the Let's Encrypt authentication server(s) make the HTTP request to you on port 80. That is what Certbot --standalone is listening for and should reply properly.

You can change the port Certbot --standalone listens on. But, you still need to route the original request from the LE server on port 80 to this alternate port.

--http-01-port HTTP01_PORT
Port used in the http-01 challenge. This only affects the port Certbot listens on. A conforming ACME server will still attempt to connect on port 80. (default: 80)

1 Like
8

I also spotted that the following test works:

curl -I http://pdfchatterapi.largent.org:8000/
HTTP/1.1 405 Method Not Allowed
date: Tue, 07 Jan 2025 15:11:43 GMT
server: uvicorn
allow: GET
content-length: 31
content-type: application/json

Running the certbot command after confirming this, still does not work.

9

Now, this test you tried earlier works, Mike:

C:\WINDOWS\system32>curl -i http://pdfchatterapi.largent.org/
HTTP/1.1 200 OK
date: Tue, 07 Jan 2025 15:59:43 GMT
server: uvicorn
content-length: 25
content-type: application/json

"Welcome to PDF Chatter!"

Does that mean I'm in the right direction?
10

That depends. Do you still plan to use --standalone method. If so work on getting this to work: Certbot fails to issue certificate for my dockerized backend api - #2 by MikeMcQ

Or, do you now plan to use --webroot and have your uvicorn server handle the incoming HTTP Challenge?

1 Like
11

Using method #2 doesn't work, I tried several times.

Can you enlighten more on how to use --webroot. I'll try this as well.

12

You could start here: User Guide — Certbot 3.1.0.dev0 documentation

And, if you have a specific question then ask. I don't wish to re-state what is already covered there.

If you describe what you tried and showed the error you got we may be able to help. Just saying it did not work is not helpful.

1 Like