Connection refused with new letsencrypt http-01 challenge

Hi,

I have received an email notification a few days ago saying that I need to renew the certificates (which have been automatically renewing for two years). I got to find out that Letsencrypt had migrated from the usual TLS-SNI-01.
I have followed the recommended steps here: How to stop using TLS-SNI-01 with Certbot but I got into the same issue over and over again, that of the Connection refused.

Could you please help me?

I did an investigation on my side and found that:

  • https://[DOMAIN]/.well-known is blocked by Nginx
  • https://[DOMAIN]/.well-known/acme-challenge/ is blocked by Nginx
  • BUT any file under https://[DOMAIN]/.well-known/acme-challenge/xxx is totally accessible. I placed a file there and was able to retrieve it from a browser.
  • The challenge folders/files are generated in the right root /var/www/html

Here is the Nginx configuration, it is listening on both 80 and 443, with 80 redirected to 443:
server {
listen 80;
server_name bankslash.com www.bankslash.com;
return 301 https://$host$request_uri;
}

Default server configuration

server {
listen 443 ssl;
server_name [DOMAIN] www.[DOMAIN];

    ssl_certificate /etc/letsencrypt/live/[DOMAIN]/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/[DOMAIN]/privkey.pem;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS';

root /var/www/html;

index index.html index.htm index.php index.nginx-debian.html;

server_name localhost;

location / {
	proxy_set_header  Host $host;
	proxy_set_header  X-Real-IP $remote_addr;
	proxy_set_header  X-Forwarded-Proto https;
	proxy_set_header  X-Forwarded-For $remote_addr;
	proxy_set_header  X-Forwarded-Host $remote_addr;
	proxy_pass [LOCAL WEB APP];
	include /etc/nginx/mime.types;
}

location ~ /.well-known {
	allow all;
}

# deny access to .htaccess files, if Apache's document root
location ~ /\.ht {
	deny all;
}

}

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. https://crt.sh/?q=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: [DOMAIN]

I ran this command: ./letsencrypt-auto renew --dry-run

It produced this output:
Domain: [DOMAIN]
Type: connection
Detail: Fetching
https://[DOMAIN]/.well-known/acme-challenge/NdEmrsKx7nGSMuT7PX4exTnhD04Xhc7FpHFKlcphLlw:
Connection refused

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

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

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): letsencrypt-auto --version gives 0.33.1

When I curl this domain on port 80, it succeeds. Did you fix something recently?

My most likely guess, if this is still a problem, would be a host-based firewall like ufw.

UPDATE: Corrected typo in link below.

Hi jsha, thanks for your quick answer.

I have not fixed anything nor have I changed any configuration beyond what was described here: How to stop using TLS-SNI-01 with Certbot .

I’m actually using iptables as a firewall but everyhthing seems to be set correctly there.

In fact, you can try to ping https://bankslash.com/.well-known/acme-challenge/file and you should be able to retrieve it. I have put that file there manually, and I know challenge files are created at the same location. So, I don’t see why challenge files can’t be retrieved in the same way.

What do you think?

Hi @aboutblank

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

Host T IP-Address is auth. ∑ Queries ∑ Timeout
bankslash.com A 109.237.24.176 yes 1 0
AAAA 2a01:7e00::f03c:91ff:fe7b:9ab1 yes
www.bankslash.com A 109.237.24.176 yes 1 0
AAAA 2a01:7e00::f03c:91ff:fe7b:9ab1 yes

But your ipv6 sends a ConnectionRefused - Answer:

Domainname Http-Status redirect Sec. G
http://bankslash.com/
109.237.24.176 301 https://bankslash.com/ 0.043 A
http://www.bankslash.com/
109.237.24.176 301 https://www.bankslash.com/ 0.040 A
http://bankslash.com/
2a01:7e00::f03c:91ff:fe7b:9ab1 -2 1.047 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:fe7b:9ab1]:80
http://www.bankslash.com/
2a01:7e00::f03c:91ff:fe7b:9ab1 -2 1.063 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:fe7b:9ab1]:80
https://bankslash.com/
109.237.24.176 200 0.527 B
https://bankslash.com/
2a01:7e00::f03c:91ff:fe7b:9ab1 -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:fe7b:9ab1]:443
https://www.bankslash.com/
109.237.24.176 200 0.307 B
https://www.bankslash.com/
2a01:7e00::f03c:91ff:fe7b:9ab1 -2 1.066 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:fe7b:9ab1]:443
http://bankslash.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
109.237.24.176 301 https://bankslash.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de 0.043 A
Visible Content: 301 Moved Permanently nginx/1.10.3 (Ubuntu)
http://www.bankslash.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
109.237.24.176 301 https://www.bankslash.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de 0.044 A
Visible Content: 301 Moved Permanently nginx/1.10.3 (Ubuntu)
http://bankslash.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2a01:7e00::f03c:91ff:fe7b:9ab1 -2 1.057 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:fe7b:9ab1]:80
Visible Content:
http://www.bankslash.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2a01:7e00::f03c:91ff:fe7b:9ab1 -2 1.060 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:fe7b:9ab1]:80

Ipv4 + /.well-known/acme-challenge/unknown-file has a (correct) redirect http -> https. But Letsencrypt prefers ipv6, so your domain isn’t visible.

  • Fix your ipv6
  • remove the ipv6 entries, create a certificate, then fix your ipv6
1 Like

Thanks Juergen. Here is what I have done:

On my iptables, I have added the following line:

-A INPUT -p icmpv6 -j ACCEPT

And made sure it was taken into account, by running the following command:

iptables -L

On top of this, on my Linode Networking configuration, I have added the domain name to the reverse DNS configuration for the ipv6 address of type SLAAC.

I have also added the following lines to my nginx configuration where appropriate:

listen [::]:443 default ipv6only=on;
listen [::]:80 default ipv6only=on;

And restarted Nginx.

Could you please tell me if this is enough? Should I restart the server to have all these changes take place?

1 Like

There are new checks of your domain - https://check-your-website.server-daten.de/?q=bankslash.com

Now you have a Grade Q - http over port 443, but your ipv6 answers.

So this part is fixed.

If you use redirects http -> https, you have to fix the Grade Q, so port 443 sends https.

Thanks Juergen.

Yes, looks like we’re moving in the right direction. Now, I have grade O, with this comment:

Old connection: Diffie-Hellman Key Exchange with 1024 Bit is unsecure. Update to 2048 Bit Key Exchange.

I will check what I can do about that.

Now, I had a script doing the renewal automatically 30 days from expiry which failed due to these issues. Will it just pick-up sometime in the next 24 hours and do a renew? or should I do a renew manually?

1 Like

Yep, now your config works. Every single row from “Url Checks” has Grade A or B.

You should fix the Grade O. But that’s not critical to create a new certificate. That should now work.

Start a renew manual:

certbot renew

then you know if it works.

Done. The renew went through smoothly.

Thank you Juergen and jsha for all the quick and efficient help. Much appreciated.

3 Likes

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