Problems running certbot in standalone mode on Docker

My domain is:

smartmonitoring.liebherr.com

I ran this command:

certbot certonly
--dry-run
--standalone
--agree-tos
--force-renewal
--cert-name ssl
-d stable.supportapi.smartmonitoring.liebherr.com
-m sxxxx@liebherr.com

It produced this output:

2021-05-27 06:36:45,843:WARNING:certbot.auth_handler:Challenge failed for domain stable.supportapi.smartmonitoring.liebherr.com
2021-05-27 06:36:45,843:INFO:certbot.auth_handler:http-01 challenge for stable.supportapi.smartmonitoring.liebherr.com
2021-05-27 06:36:45,843:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: stable.supportapi.smartmonitoring.liebherr.com
Type: connection
Detail: Fetching http://stable.supportapi.smartmonitoring.liebherr.com/.well-known/acme-challenge/WXMLGJpXr2GKNUgLQBihnZcjsP136_BbuhJH-tmONKg: Timeout during connect (likely firewall problem)

My web server is (include version): Well, standalone. Using package python3-certbot-apache

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

Ubuntu 20.04

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

yes

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

certbot 0.40.0

The domain name is fine, the IP (v4) is fine.

Seeing a

2021-05-27 06:51:17,127:DEBUG:acme.standalone:Successfully bound to :80 using IPv6
2021-05-27 06:51:17,127:DEBUG:acme.standalone:Certbot wasn't able to bind to :80 using IPv4, this is often expected due to the dual stack nature of IPv6 socket implementations.

Not sure if that's an issue.

In the end I get a

"challenges": [
{
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:connection",
"detail": "Fetching http://stable.supportapi.smartmonitoring.liebherr.com/.well-known/acme-challenge/WXMLGJpXr2GKNUgLQBihnZcjsP136_BbuhJH-tmONKg: Timeout during connect (likely firewall problem)",
"status": 400
},
"url": "https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/56698959/9oh8jA",
"token": "WXMLGJpXr2GKNUgLQBihnZcjsP136_BbuhJH-tmONKg",
"validationRecord": [
{
"url": "http://stable.supportapi.smartmonitoring.liebherr.com/.well-known/acme-challenge/WXMLGJpXr2GKNUgLQBihnZcjsP136_BbuhJH-tmONKg",
"hostname": "stable.supportapi.smartmonitoring.liebherr.com",
"port": "80",
"addressesResolved": [
"52.166.67.166"
],
"addressUsed": "52.166.67.166"
}
],
"validated": "2021-05-27T06:51:17Z"
}
]

I think that port 80 is open on 52.166.67.166.

I am hoping that someone sees what's wrong. I am out of my wits. Thanks in advance.

Regards,

Sascha

Hi @SaschaAusUlm,

I think it's not, because when I try to connect to it I see a timeout, rather than a connection refused error. If you didn't have a firewall restricting incoming connections—but did have a server running at that IP address—I would expect to see a connection refused error.

So I think the CA's speculation

is probably correct. Sometimes there can be more than one place where you have to adjust firewall policies (for example, on the host itself, with something like ufw, as well as on the network where it's connected, using some other device or interface).

I should add to this that since you said you're running inside of Docker, you should also make sure that port 80 is properly mapped from the Docker host to this Docker instance. You might want to try, in order to help with debugging, temporarily running a simple web server on port 80 (in the same or a similar environment), and figuring out what you have to adjust so that you can connect to that server from a web browser outside of the network where it's hosted. You could use lightttpd or even python3 -m http.server 80 for this purpose.

Thanks for your reply.

Well, typically I would run my real server (either a Spring Boot app on one server, or an nginx on the other server) after I got the certificate.

Now, to keep the deployments running I am specifying:

CMD /usr/share/configureEnvironment.sh $ENVIRONMENT; /usr/share/handleCertificate.sh $ENVIRONMENT; tail -f /dev/null

So there is nothing running there on that port after certbot has failed.
Is there a way to prevent certbot from stopping its server ... at least for some time?

So that I could execute the call to port 80 myself?

You can prevent Certbot from stopping its server with the --debug-challenges option. In this case you can try it for yourself before the certificate authority tries to connect.

Thanks, I will

I adopted your suggestion. I let a pythons3 web server run (hopefully correct, I am not a Python guy).

I see

root 14 0.0 0.2 24200 16496 ? S 07:59 0:00 python3 -m http.server 80

but I cannot access the server on port 80 ... which I should be able to do ..... right?

So I will look on why the port is not coming through.

Thanks for your help,

Sascha

Exactly! So I think the problem is somewhere in the network/firewall configuration here.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.