Help with standalone certbot: "Failed to bind to :80 using IPv4"

I am having problems obtaining a certificate on a fresh raspbian installation using certbot-auto. I keep running into a timeout error (see full output below). Upon checking the debug logs, the only thing that looks out of the ordinary is the following line, which appears as certbot attempts to spin up its standalone server:
DEBUG:acme.standalone:Failed to bind to :80 using IPv4

I’m fairly confident that both DuckDNS and port forwarding have been set up correctly; I spun up a quick “hello world” server in python on port 80 and was able to access it via my duckdns domain (in between attempts, of course).

Port 80 is not otherwise in use, and certbot does not complain of it being in use.

Any ideas?


Please fill out the fields below so we can help you better.

My domain is: dwelch.duckdns.org

I ran this command: sudo ./certbot-auto certonly --standalone --preferred-challenges http -d dwelch.duckdns.org

It produced this output:

saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for dwelch.duckdns.org
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. dwelch.duckdns.org (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://dwelch.duckdns.org/.well-known/acme-challenge/mdldbzgh0xVaxx6lQDkyDGW3RqWMaA-oIbUmT4TVUCs: Timeout

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: dwelch.duckdns.org
   Type:   connection
   Detail: Fetching
   http://dwelch.duckdns.org/.well-known/acme-challenge/mdldbzgh0xVaxx6lQDkyDGW3RqWMaA-oIbUmT4TVUCs:
   Timeout

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Debug Log: DEBUG:acme.standalone:Failed to bind to :80 using IPv4

My web server is (include version): standalone

The operating system my web server runs on is (include version): RASPBIAN JESSIE LITE version July 2017, kernel version 4.9

My hosting provider, if applicable, is:

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

hi @dwelchmd

I can see that you have a dns thats accessible however nothing bound on any ports (from an external scan anyway)

Test any firewall interactions as they may be blocking outside traffic

Andrei

Thanks for the reply.

Based on the time of your scan, I think the reason for that result is simply that I had my RPi off the network. I’m trying this same process on a RPi 3 now (previously using RPi 1 model B), but I’m running into the same problem.

Here’s the output I get running nmap outside of my network:

→ nmap dwelch.duckdns.org

Starting Nmap 7.50 ( https://nmap.org ) at 2017-07-08 09:32 EDT
Nmap scan report for dwelch.duckdns.org (72.196.102.176)
Host is up (0.055s latency).
rDNS record for 72.196.102.176: ip72-196-102-176.ga.at.cox.net
Not shown: 997 filtered ports
PORT    STATE SERVICE
21/tcp  open  ftp
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 6.81 seconds

Turns out the problem may have been with my ISP blocking port 80. I came across this piece of advice in a HomeAssistant tutorial:

and used the tls challenge without issue.

I was thrown off because I mistakenly accessed dwelch.duckdns.org:80 from within my network. When trying to access from outside my network… no response.

Only problem now is that I’m not sure how to automate renewal without using port 80 or 443, since 80 is apparently not an option and I am using 443. Looks like I’ll have to manually renew and change my port forwarding every time, which is not ideal. I’ll read more about this to see if there’s a work around.

(edited) This is a little strange, because people are routinely able to use Let’s Encrypt client software to automate renewals using port 443. It would be great to know why people think that it can’t be done in this case.

In particular, certbot-auto renew should still be able to renew via port 443 just as it could with port 80. And if you can run it from a cron job, it should still be able to do so automatically!

For what it’s worth, here’s my output when I just ran certbot renew --dry-run

Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/dwelch.duckdns.org.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for dwelch.duckdns.org
/usr/lib/python2.7/dist-packages/OpenSSL/rand.py:58: UserWarning: implicit cast from 'char *' to a different pointer type: will be forbidden in the future (check that the types are as you expect; use an explicit ffi.cast() if they are correct)
  result_code = _lib.RAND_bytes(result_buffer, num_bytes)
Waiting for verification...
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/dwelch.duckdns.org.conf produced an unexpected error: Failed authorization procedure. dwelch.duckdns.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data. Skipping.
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/dwelch.duckdns.org/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: dwelch.duckdns.org
   Type:   connection
   Detail: Error getting validation data

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

Public port 443 is forwarded to private port 8123, for HomeAssistant access.

Oh, I see. Do you have commands that could temporarily stop and restart HomeAssistant?

Yes, which could be automated, but still have to change the port mapping temporarily right?

Nope! It would probably work with

--pre-hook "command-to-stop-home-assistant" --standalone --preferred-challenges tls-sni-01 --tls-sni-01-port 8123 --post-hook "command-to-start-home-assistant"

Certbot doesn’t really care which port it has to bind internally, but the Let’s Encrypt CA does care which port it connects on externally!

Beautiful, that port option is the piece I was missing in my mental model. Thanks so much for the help.

Great! If it works, maybe you should let the people who wrote that tutorial know. :slight_smile:

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