CertBot Renewal Issue (Connection Refused)

Help
1

Hey guys, the issue is that the renewal keeps failing due to connection refused. I know the biggest issue is typically port forwarding, but I have both 443 and 80 forwarded.. I can even go to 51.222.10.97:80 with no issues so... here goes nothing!@@!#!@

My domain is:
51.222.10.97 (https://maplecitizens.com/)

I ran this command:
certbot renew --dry-run

It produced this output:

Processing C:\Certbot\renewal\www.maplecitizens.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for www.maplecitizens.com and maplecitizens.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
** Domain: maplecitizens.com**
** Type: connection**
** Detail: Fetching http://maplecitizens.com/.well-known/acme-challenge/PG6YRS7TzfAo9YVYsHyNXOMU6dE5OkPr1Ob_hYzssGI: Connection refused**

** Domain: www.maplecitizens.com**
** Type: connection**
** Detail: Fetching http://www.maplecitizens.com/.well-known/acme-challenge/oZwSHsTX9R1bFcn2spWXfZhtkf0ujNanmSDJQuHbsHo: Connection refused**

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Failed to renew certificate www.maplecitizens.com with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
** C:\Certbot\live\www.maplecitizens.com\fullchain.pem (failure)**
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile C:\Certbot\log\letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):
Apache

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

My hosting provider, if applicable, is:
OVH Cloud

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):
Kind of? Using OVH cloud's dedicated server. Have admin access to all.

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

1 Like
2

Hi @ninjatuna, welcome to the LE community forum :slight_smile:

Please ensure you have a working HTTP site before trying to secure it (via HTTP authentication).
Something is preventing HTTP requests from reaching your webserver (but HTTPS gets through).

curl -Iki http://maplecitizens.com/
curl: (56) Recv failure: Connection reset by peer

curl -Iki https://maplecitizens.com/
HTTP/1.1 200 OK
Date: Sat, 11 Sep 2021 21:22:03 GMT
Server: Apache/2.4.46 (Win64) OpenSSL/1.1.1j PHP/8.0.0
Content-Security-Policy: upgrade-insecure-requests;
X-Powered-By: PHP/8.0.0
Set-Cookie: PHPSESSID=55bb2odt2qc08v3ju3umv6npm1; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Type: text/html; charset=UTF-8
2 Likes
3

Welcome. I am not able to see your port 80 as you are. I can reach 443 just fine.

curl -LI https://maplecitizens.com
HTTP/1.1 200 OK
Date: Sat, 11 Sep 2021 21:08:00 GMT
Server: Apache/2.4.46 (Win64) OpenSSL/1.1.1j PHP/8.0.0
Content-Security-Policy: upgrade-insecure-requests;
X-Powered-By: PHP/8.0.0
Set-Cookie: PHPSESSID=v39cjmhrfe43grso13rj7856ck; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Type: text/html; charset=UTF-8

curl -LI 51.222.10.97:443
HTTP/1.1 400 Bad Request
Date: Sat, 11 Sep 2021 21:16:56 GMT
Server: Apache/2.4.46 (Win64) OpenSSL/1.1.1j PHP/8.0.0
Content-Length: 469
Connection: close
Content-Type: text/html; charset=iso-8859-1

curl -LI http://maplecitizens.com
curl: (7) Failed to connect to maplecitizens.com port 80: Connection refused

curl -LI 51.222.10.97:80
curl: (7) Failed to connect to 51.222.10.97 port 80: Connection refused

Maybe try using a mobile phone cellular connection (not wifi) to test port 80 to your server. I can only guess some routing in your local net allowed that to work for you.

Or, try a site like Lets Debug. My result from that is seen here:

You will need to start at the Lets Debug home page for a fresh attempt

3 Likes
4

Ah yes I know http will not working - is there any way to have the renewal go through HTTPS instead of H TTP?

5

LE will follow redirects from http to https but I do not believe you can start with https.

But, can you use a DNS challenge instead? The OVH instructions are here:
https://certbot-dns-ovh.readthedocs.io/en/stable/

1 Like
6

Only if your HTTPS path supports TLS-ALPN.

4 Likes
7

@rg305 Does Certbot support TLS-ALPN yet? I thought not. So, they would also have to use a different client. Agreed it is a way though :slight_smile:

1 Like
8

@MikeMcQ, although I'm not a fan of the implementation/requirements... I know firsthand that acme.sh, via nginx, does support TLS-ALPN for new issuances and renewals.

[and I suppose eventually all web servers will support TLS-ALPN directly - but who wants to wait]

4 Likes
9

AFAIK mod_md, the ACME-client-mod of Apache, also supports the TLS-ALPN challenge.

5 Likes
10

How would I check this?

1 Like
11

For a web server port 80 and 443 are both used. HTTP traffic on my site is automaticaly forwarded to HTTPS but the WGET may have been on port 80.

12

The Internet is filled with information - all you have to do is look for it.
I'm not fluent enough with apache to make any recommendations to you.

3 Likes
13

@ninjatuna I apologize for this aside.

@osiris and @rg305
As I researched TLS-ALPN since your comments I saw the Lets Encrypt TLS-ALPN docs are stale. For example, in the cons section it says:
It’s not supported by Apache, Nginx, or Certbot, and probably won’t be soon.
From: Challenge Types - Let's Encrypt

I went to submit correction feedback but saw it was requested some time ago. Seems to correct it just needs an update to the git for the docs. You both have the expertise and credibility to make those updates. Just sayin' :slight_smile: Cheers

3 Likes
14

Frankly all these responses kind of made me even more confused that I was. All I know is the following:

  • Forwarded port 80 (TCP) both via my Windows Firewall and OVH's network firewall
  • Going to my domain:80 works fine (using a machine on a completely different network)
  • my HTTP vhost has a permanent redirect to https, so this should not be an issue either

What am I missing here?

1 Like
15

@ninjatuna Well, if port 80 was open to 'the world' then so many others would not fail trying to use it. Certbot response failed, Lets Debug failed, Rudy failed, and I failed to reach your site on port 80. If you get Lets Debug to find you - it should be fine. Until then, port 80 is a no go. Maybe your firewall is blocking all these outsiders - I do not know.

Also, you said Ah yes I know http will not working and then asked about using port 443. So, TLS-ALPN can do that as Rudy and Osiris said but I do not have sufficient knowledge of it (looks messy to me but so do many things at first).

The DNS challenge looks promising as an alternative to port 80 (http-01) challenge as there is a Certbot OVH plugin for that. But, I cannot help beyond pointing it out as I have no experience with it. I personally use http-01 challenge so know that the best.

2 Likes
16

@ninjatuna So I see you got your cert. Just curious. What did you do?

2 Likes
17

How were you able to check? Because I realized if my ports are open, and my HTTP is being redirected to HTTPS, then why not DELETE the old cert, and create a new one. It went through!

So what I did was create a new certificate via Certify the Web. Then deleted the old one using CertBot. I'm not sure if I have to do anything else... how did you know it went through? I'm looking at the cert on my remote machine and its still saying I have my old one that expires on 9/20

1 Like
18

This is what I am seeing

PORT    STATE  SERVICE VERSION
21/tcp  open   ftp     FileZilla ftpd
22/tcp  closed ssh
80/tcp  closed http
443/tcp open   ssl/ssl Apache httpd (SSL-only mode)
4 Likes
19

@ninjatuna With crt.sh | maplecitizens.com

3 Likes
20

@ninjatuna Well, as they say, there is a lot to unpack here.

Certify the Web will start its own http listener on port 80 to receive the challenge requests from Lets Encrypt server. That is why it worked - I surmise because your Apache is not actually listening on port 80. This would explain why so many of us (now 5) cannot see your Apache server on port 80.

You could run netstat -a on your Windows server to see if Apache is actually using port 80. I am not certain of this command as I don't have a Windows server. So, you may need to use other options. I think you will find that port 80 is not being used by Apache.

Now, you can have certbot do what you just did with Certify the Web.
Which is to create its own http listener on port 80 by using:

certbot --standalone renew --dry-run

--dry-run is just to test. If it says it worked then remove --dry-run to get renewed certs. Restart Apache and you are done. The --standalone option tells certbot to create its own http listener (and only works when port 80 is not in use by someone else).

If --standalone does not work you will need to start debugging / changing your Apache configuration. Certify the Web created good certs but your Apache server is still referring to the certbot cert which is expiring soon. So, you could replace all the certbot updates to your Apache config with ones for Certify the Web. Or, you could start serious debug to figure out why Apache does not work for http port 80 and continue with Certbot as you have been trying.

2 Likes