Certbot not working anymore behind pfsense? Firewall issue?

I run a small webserver with a nextcloud instance.

Before I ran it behind my ISP router and all was well. I used the certbot script to renew the certificates.

Then I switched to Pfsense. All ran fine until the certificate ran out.

When I run the Certbot script I get a warning that I have an issue with my firewall.

Pfsense is set to default, the only thing I changed was the NAT to forward to my webserver on HTTPS and HTTP. (this is working fine).

I am using a no-ip dynamic updated domain. I don't have access to any DNS records.

I tried to generate the certificates on Pfsense itself but that seems to give the same issues.

Any tips on how to troubleshoot this?

Many thanks!
Karel.

My domain is:editoor.ddns.net

I ran this command:

sudo certbot --apache

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: editoor.ddns.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for editoor.ddns.net
Performing the following challenges:
http-01 challenge for editoor.ddns.net
Waiting for verification...
Challenge failed for domain editoor.ddns.net
http-01 challenge for editoor.ddns.net
Cleaning up challenges
Some challenges have failed.

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

   Domain: editoor.ddns.net
   Type:   connection
   Detail: Fetching
   http://editoor.ddns.net/.well-known/acme-challenge/H5u2Y9IINzRysZx1V5PGiXXxDOY99rfFUqdhUcOQT14:
   Timeout during connect (likely firewall problem)

   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): Server version: Apache/2.4.6 (CentOS)
Server built: Nov 16 2020 16:18:20

The operating system my web server runs on is (include version): CentOS 7

My hosting provider, if applicable, is: no-ip.

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 1.11.0

1 Like

I think you should start with PFsense. It is likely blocking port 80

Your last certbot cert was July 4. crt.sh | editoor.ddns.net

Since then, certbot would not have needed to access your server on port 80 until a cert renewal was actually needed. Based on your previous patterns it looks like you may have tried that just in the last day or so.

You say your site worked fine since pfsense. I believe you. But, could it just have been working right with https? That is port 443.

Your port 80 is being blocked. pfsense was a recent change so is a good candidate for being the cause.

Use this to check access after making changes:

Click re-run test on the top of that page to try a fresh connection

Other things could be involved. Let us know if you dont find anything wrong with pfsense.

3 Likes

I just tried telnetting into port 80 on editoor.ddns.net and I get no connection. Your port 80 is being blocked. Are you sure your pfsense firewall is updating your dynamic dns provider with the correct IP address?

2 Likes

Hi @heloha

There is a problem with port 80 access:

curl -Iki editoor.ddns.net
curl: (56) Recv failure: Connection reset by peer

@Ted
The IP is correct, port 443 returns:

openssl s_client -connect editoor.ddns.net:443 -servername editoor.ddns.net
CONNECTED(00000005)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = editoor.ddns.net
verify error:num=10:certificate has expired
notAfter=Oct  2 17:53:18 2021 GMT
verify return:1
depth=0 CN = editoor.ddns.net
notAfter=Oct  2 17:53:18 2021 GMT
verify return:1
---
Certificate chain
 0 s:CN = editoor.ddns.net
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
4 Likes

Yup... I see it too..

PORT    STATE    SERVICE VERSION
22/tcp  open     ssh     OpenSSH 7.4 (protocol 2.0)
80/tcp  filtered http
443/tcp open     ssl/ssl Apache httpd (SSL-only mode)

Take a look at ufw too.

ufw status

It will list the current configuration and if you don't see port 80 in the allow list try

ufw allow 80/tcp

Might help... Worth a peek.
Oh and you can scan your ports from outside your network with this "nifty tool"

5 Likes

Thanks everyone,

Did myself a facepalm. I redirected port 80 to 443 because I didn't want to allow HTTP. I did not know that certbot and lets encrypt need port 80 for their verification...

Thanks for the many replies!

4 Likes

See Best Practice - Keep Port 80 Open - Let's Encrypt

3 Likes

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