I’m running letsencrypt in webserver mode, and I get the error:
FailedChallenges: Failed authorization procedure. cloud.mydomain.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://cloud.mydomain.net/.well-known/acme-challenge/F5t_DGzKjz3kTY23z7TAVjPqTiEQXqIHsFPMGBV04KI, nas.mydomain.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://nas.mydomain.net/.well-known/acme-challenge/Y7W8yRDOlzdT7evf2rivDaxuaIvg_nYrOnzyvUWD3yU, router.mydomain.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://router.mydomain.net/.well-known/acme-challenge/C3NjDwFxPlS022HDDsdAMT0mXiNVzfZcQ-U502RJT-Y
The strange thing that if I create those paths manually on my web server, and then try to access them in the browser or via curl, they download just fine. I’m at a loss for how to further debug this.
My setup is as follows:
- The domain names above are configured in ZoneEdit as Dynamic DNS entries
- My router has a DDNS daemon that makes sure this is always pointing to my public IP address
- I’m running a VirtualBox container on a Mac on my network, which was created with docker-tools. This has a bridge network and so is reachable from the router.
- nginx is running in a Docker image on this VirtualBox, mapped to ports 8080 and 8443 on the VirtualBox host.
- In the router, I’m port-forwarding ports 80 and 443 to the VirtualBox host, ports 8080 and 8443 respectively.
I did manage to get letsencrypt-auto on the Mac to work in standalone mode at one point (I then had port forwarding pointing to the Mac, not the VirtualBox host) and generated certs that are working.
What I’m really trying to do now is to automate renewals. I’d like to run letsencrypt via the Docker image. This is my docker-compose.yml that I’m using to run this:
letsencrypt: image: quay.io/letsencrypt/letsencrypt:latest volumes: - ./certs:/etc/letsencrypt - ./certs-lib:/var/lib/letsencrypt - ./certs-log:/var/log/letsencrypt - ./html:/webroot command: certonly --debug --renew-by-default --webroot --webroot-path /webroot --domain cloud.mydomain.net --domain router.mydomain.net --domain nas.mydomain.net --email firstname.lastname@example.org --agree-tos
The salient bit here is that the
certs directory is mounted to
/etc/letsencrypt in the nginx container, the
html directory is mounted as the webroot in the nginx container.
When letsencrypt is running with the above command, I can briefly see the
.well-known/acme-challenge/* files being created. They get cleaned up, but if I manage the save them before letsencrypt deletes them and then put them back in the folder, then the URLs that letsencrypt is complaining about work from curl and even my phone over a cellular connection (i.e. not on my home network).
I’ve also tried running it with
--standalone --tls-sni-01-port 8443 --http-01-port 8080 instead of
--webroot --webroot-path /webroot with nginx stopped. This also fails with a similar error message, though in this case it’s harder to verify “manually” in the browser what may be going on because the server stops very quickly.
How can I debug this? It’s very hard to know why “The server could not connect to the client to verify the domain”.