Certbot-auto "Connection refused"

My domain is:
hula-hoop.cz

I ran this command:
/usr/local/bin/certbot-auto renew

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/hula-hoop.cz.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for hula-hoop.cz
http-01 challenge for www.hula-hoop.cz
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (hula-hoop.cz) from /etc/letsencrypt/renewal/hula-hoop.cz.conf produced an unexpected error: Failed authorization procedure. hula-hoop.cz (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://www.hula-hoop.cz/.well-known/acme-challenge/XlBAZWnn-pVYD-VM8EHNT00uYwF8tCnY0DVwoDZQfH4: Connection refused, www.hula-hoop.cz (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://www.hula-hoop.cz/.well-known/acme-challenge/6hhKAXFBR_4XjcnMJShEUIEtc1Sj0q7MvReB1RgZuB8: Connection refused. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/hula-hoop.cz/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/hula-hoop.cz/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

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

   Domain: hula-hoop.cz
   Type:   connection
   Detail: Fetching
   https://www.hula-hoop.cz/.well-known/acme-challenge/XlBAZWnn-pVYD-VM8EHNT00uYwF8tCnY0DVwoDZQfH4:
   Connection refused

   Domain: www.hula-hoop.cz
   Type:   connection
   Detail: Fetching
   https://www.hula-hoop.cz/.well-known/acme-challenge/6hhKAXFBR_4XjcnMJShEUIEtc1Sj0q7MvReB1RgZuB8:
   Connection refused

   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.

My web server is (include version):
nginx/1.2.1

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

My hosting provider, if applicable, is:
Linode

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 0.31.0

This install and cronjob have been running happily for a few years. I recently upgraded certbot-auto as another installation of mine got the email about TLS-SNI-01. I thought it just a question of time before I got that same email so preemptively upgraded. Now the cert is due for renewal, the process is failing.

I am pretty sure this must be something to do with the TLS-SNI-01/http-01 switch. I’ve read a load of other threads which don’t seem to help. Port 80 is open, but redirected, and according to another thread that is enough.

If I manually run certbot-auto renew and in another terminal watch the contents of docroot, I can see the correct directories and files get created (and then removed). If I manually create those exact dirs/files (with mkdir and touch), I can access them via https or http (which just redirects to https). I’ve checked my DNS, everything looks fine AFAICT (and hasn’t changed in years).

Any help appreciated, thank you.

Hi @_jack

you have ipv4- and ipv6 - addresses ( https://check-your-website.server-daten.de/?q=hula-hoop.cz ):

Host T IP-Address is auth. ∑ Queries ∑ Timeout
hula-hoop.cz A 88.80.189.134 yes 1 0
AAAA 2a01:7e00::f03c:91ff:fe89:3695 yes
www.hula-hoop.cz A 88.80.189.134 yes 1 0
AAAA 2a01:7e00::f03c:91ff:fe89:3695 yes

But ipv6 has different answers:

Domainname Http-Status redirect Sec. G
http://hula-hoop.cz/
88.80.189.134 301 https://www.hula-hoop.cz/ 0.046 E
http://www.hula-hoop.cz/
88.80.189.134 301 https://www.hula-hoop.cz/ 0.053 A
http://hula-hoop.cz/
2a01:7e00::f03c:91ff:fe89:3695 -2 1.077 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it [2a01:7e00::f03c:91ff:fe89:3695]:80
http://www.hula-hoop.cz/
2a01:7e00::f03c:91ff:fe89:3695 -2 1.077 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it [2a01:7e00::f03c:91ff:fe89:3695]:80
https://hula-hoop.cz/
88.80.189.134 301 https://www.hula-hoop.cz/ 6.494 B
https://hula-hoop.cz/
2a01:7e00::f03c:91ff:fe89:3695 -2 1.067 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it [2a01:7e00::f03c:91ff:fe89:3695]:443
https://www.hula-hoop.cz/
88.80.189.134 200 5.867 B
https://www.hula-hoop.cz/
2a01:7e00::f03c:91ff:fe89:3695 -2 1.073 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it [2a01:7e00::f03c:91ff:fe89:3695]:443
http://hula-hoop.cz/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
88.80.189.134 301 https://www.hula-hoop.cz/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de 0.050 E
Visible Content: 301 Moved Permanently nginx
http://www.hula-hoop.cz/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
88.80.189.134 301 https://www.hula-hoop.cz/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de 0.043 A
Visible Content: 301 Moved Permanently nginx
http://hula-hoop.cz/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2a01:7e00::f03c:91ff:fe89:3695 -2 1.070 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it [2a01:7e00::f03c:91ff:fe89:3695]:80
Visible Content:
http://www.hula-hoop.cz/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2a01:7e00::f03c:91ff:fe89:3695 -2 1.070 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it [2a01:7e00::f03c:91ff:fe89:3695]:80
Visible Content:
https://www.hula-hoop.cz/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de 404 8.930 A
Not Found

If you use http-01 - validation, an open and working port 80 is required. Certbot creates a file under /.well-known/acme-challenge, Letsencrypt checks that file. And Letsencrypt prefers ipv6.

But your ipv6 doesn't work, there is something that blocks, perhaps a firewall.

Are your vHosts configured so they handle ipv6?

1 Like

Thank you @JuergenAuer, it seems to be my ipv6 vhost config.

2 Likes

I see, you have rechecked your domain. Now your ipv6 is ok. Same answers and redirects like ipv4.

And /.well-known/acme-challenge is redirected to https, that's ok, Letsencrypt follows these redirects.

So try to create a new certificate.

@JuergenAuer Yes thanks, I already had done. You were right, I simply did not have ipv6 vhosts configured. I didn’t see or missed that ipv6 is now required. Everything works fine now.

Thank you again for the fast and accurate help, very much appreciated!

1 Like

If an AAAA record is defined, the webserver should handle that request correct.

Happy to read that it works now. And there is a new Letsencrypt certificate:

CN=hula-hoop.cz
	03.03.2019
	01.06.2019
expires in 90 days	hula-hoop.cz, www.hula-hoop.cz - 2 entries

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