After certbot, site not reachable

kescobo · January 12, 2024, 8:55pm

I am trying to run a nextcloud server from my home laptop. I use Hover for my DNS, and had the A records:

type	host	value	ttl
A	@	108.20.147.223	15min
A	www	108.20.147.223	15min
A	cloud	108.20.147.223	15min

I also have a CNAME for blog that points to my github pages site (I don't think it's relevant, but .

Prior to running certbot, my configuration was vanilla, except for vhosts.d/bonham-ch.conf:

<VirtualHost *:80>
    DocumentRoot "/srv/www/htdocs"
    ServerName www.bonham.ch
    ServerAlias bonham.ch
    # Other directives here
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/srv/www/htdocs/nextcloud"
    ServerName cloud.bonham.ch
    # Other directives here
</VirtualHost>

With this setup, I was able to go to http://www.bonham.ch, http://bonham.ch and get my root page (just an index.html with "Hello, World!", and to http://cloud.bonham.ch which opened my nextcloud installation login page.

After running certbot (see below for outputs), my vhosts.d/bonham-ch.conf was modified to

<VirtualHost *:80>
    DocumentRoot "/srv/www/htdocs"
    ServerName www.bonham.ch
    ServerAlias bonham.ch
    # Other directives here
RewriteEngine on
RewriteCond %{SERVER_NAME} =bonham.ch [OR]
RewriteCond %{SERVER_NAME} =www.bonham.ch
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/srv/www/htdocs/nextcloud"
    ServerName cloud.bonham.ch

    # Other directives here
RewriteEngine on
RewriteCond %{SERVER_NAME} =cloud.bonham.ch
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

The 3 urls above now re-route properly to https, but I get "this site can't be reached" ERR_ADDRESS_UNREACHABLE (chrome) or "Unable to connect" (firefox).

I added

<VirtualHost *:443>
    DocumentRoot "/srv/www/htdocs"
    ServerName www.bonham.ch
    ServerAlias bonham.ch
    # Other directives here
</VirtualHost>

<VirtualHost *:443>
    DocumentRoot "/srv/www/htdocs/nextcloud"
    ServerName cloud.bonham.ch
    # Other directives here
</VirtualHost>

To bonham-ch.conf, and I added 443 to port forwarding on my home router, but I'm still getting the same response.

I'm quite a newb on this stuff, so no consideration is too stupid, any help would be appreciated!

PS I read through this thread and some other threads here with similar problems, but didn't immediately see a relationship. bonham.ch - Make your website better - DNS, redirects, mixed content, certificates gives:

My domain is: bonham.ch

I ran this command:

certbot --apache -d cloud.bonham.ch
certbot --apache -d bonham.ch -d www.bonham.ch

It produced this output:

certbot output (success)

$ certbot --apache -d cloud.bonham.ch
Saving debug log to /var/log/letsencrypt/letsencrypt.log
ssl_module is statically linked but --apache-bin is missing; not disabling session tickets.
Requesting a certificate for cloud.bonham.ch

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/cloud.bonham.ch/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/cloud.bonham.ch/privkey.pem
This certificate expires on 2024-04-11.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for cloud.bonham.ch to /etc/apache2/vhosts.d/bonham-ch-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://cloud.bonham.ch

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ certbot --apache -d bonham.ch -d www.bonham.ch
Saving debug log to /var/log/letsencrypt/letsencrypt.log
ssl_module is statically linked but --apache-bin is missing; not disabling session tickets.
Requesting a certificate for bonham.ch and www.bonham.ch

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/bonham.ch-0001/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/bonham.ch-0001/privkey.pem
This certificate expires on 2024-04-11.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for bonham.ch to /etc/apache2/vhosts.d/bonham-ch-le-ssl.conf
Successfully deployed certificate for www.bonham.ch to /etc/apache2/vhosts.d/bonham-ch-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://bonham.ch and https://www.bonham.ch

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

My web server is (include version): Apache2

$ apachectl -v
Server version: Apache/2.4.58 (Linux/SUSE)
Server built:   2023-10-19 14:26:31.000000000 +0000

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

$ cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20240109"
#...

My hosting provider, if applicable, is: None (home laptop)

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 2.8.0

MikeMcQ · January 12, 2024, 9:10pm

Welcome to the community @kescobo

And, thanks for thorough report.

I hope the answer will be simple. Looks like something is blocking port 443 on your end. I know you said you opened it but is there a firewall setting in your router that might be blocking it?

"filtered" usually means firewall blocking

nmap -p22,80,443 www.bonham.ch
rDNS record for 108.20.147.223: pool-108-20-147-223.bstnma.fios.verizon.net

PORT    STATE    SERVICE
22/tcp  open     ssh
80/tcp  open     http
443/tcp filtered https

MikeMcQ · January 12, 2024, 10:56pm

You might also check that Apache is listening on port 443

I think this works on suse

sudo ss -pant | grep -i listen | grep -Ei ':80|:443|httpd|apache'

kescobo · January 13, 2024, 1:26am

Could be! I'm using google wifi mesh, and the server is hooked up via ethernet cable to one of the mesh stations, in case that's relevant. Here's what it looks like in the app:

(wasn't sure if sharng MAC address is security issue so I blurred them, but they're identical).

Neither ssh nor http connections worked without these port forwards set, and now they do, so I gather this is doing something. A bit of googling didn't reveal anything else obviously related to a firewall.

There wouldn't be anything relevant on the ISP's modem would there (I'm on FIOS)?

This gives me

ISTEN 0      4096               *:80                  *:*     users:(("httpd-prefork",pid=20010,fd=4),("httpd-prefork",pid=18003,fd=4),("httpd-prefork",pid=18002,fd=4),("httpd-prefork",pid=18001,fd=4),("httpd-prefork",pid=16686,fd=4),("httpd-prefork",pid=16663,fd=4),("httpd-prefork",pid=16621,fd=4),("httpd-prefork",pid=16620,fd=4),("httpd-prefork",pid=16618,fd=4),("httpd-prefork",pid=16617,fd=4),("httpd-prefork",pid=16601,fd=4))
LISTEN 0      4096               *:443                 *:*     users:(("httpd-prefork",pid=20010,fd=6),("httpd-prefork",pid=18003,fd=6),("httpd-prefork",pid=18002,fd=6),("httpd-prefork",pid=18001,fd=6),("httpd-prefork",pid=16686,fd=6),("httpd-prefork",pid=16663,fd=6),("httpd-prefork",pid=16621,fd=6),("httpd-prefork",pid=16620,fd=6),("httpd-prefork",pid=16618,fd=6),("httpd-prefork",pid=16617,fd=6),("httpd-prefork",pid=16601,fd=6))

i

MikeMcQ · January 13, 2024, 1:42am

You have to inspect each piece. Sometimes ISP's block port 80 and 443 for residential accounts. It would be odd to block 443 and not 80 but who knows. Worth asking them.

Otherwise, just follow the wire. I have sometimes plugged a computer into the modem and tested that. Then add each piece of equipment until you find the cause.

The ss command shows Apache is listening so that rules that out anyway. Make sure you have checked your o/s for any firewall (not sure if suse has ufw but any others).

Oh, make sure to test HTTP and HTTPS at each step. Ensure HTTP works at each step to rule out some other problem.

Rip · January 13, 2024, 2:08am

This is what I see:

Host is up (0.13s latency).

PORT    STATE    SERVICE
22/tcp  open     ssh
80/tcp  open     http
443/tcp filtered https

Hope this helps somewhat.

kescobo · January 13, 2024, 2:15am

When you say

Is running this:

Sufficient?

From Internet search, it looks like opensuse uses firewalld, but I certainly haven't interacted with it. Again, seems weird that it would block 443 but not 80 (or 22) for that matter.

Thank you for your prompt responses, I'll probably have to wait until Monday to work on this again, but nice to have an idea of what to look for!

Rip · January 13, 2024, 2:35am

Not trying to interfere here. But I have used openSUSE in the past.

MikeMcQ · January 13, 2024, 2:40am

Probably but the test device should be outside your local network. A cell phone with wifi disabled so using the carrier network is an easy way to do that. And, HTTP and HTTPS requests are easily made from browsers just by explicitly stating so in the URL.

Rip · January 13, 2024, 3:18am

here is a cool tool to be run from the source IP:

https://www.grc.com/x/ne.dll?bh0bkyd2
It will show all exposed ports depending on the choices the end user makes.
It's like using an outside source, if one doesn't exist.

MikeMcQ · January 13, 2024, 3:33am

Yes, but nmap uses either udp or tcp to determine connectivity. It may be fair test for this particular case but using HTTP / HTTPS directly is more representative.

http/3 apparently uses udp although I do not know it well

Rip · January 13, 2024, 3:37am

I don't see anything relating to http/3 in this thread. (so far)
As far as I can see there's an issue with port 443.
Correct me if I am my normal wrong self... ;@)

MikeMcQ · January 13, 2024, 3:45am

No, HTTP/3 is not in play here. I only brought it up to point out that it uses udp whereas HTTP and HTTPS use tcp.

It's really a fine point regarding nmap. It's a fine tool for debugging but it isn't always definitive.

rg305 · January 13, 2024, 3:45am

Is this the directly external IP of your home network?:
108.20.147.223

OR
Are you using any type of VPN service?

Are there any systems along the way that might be able to do anything like?: GeoLocation blocking, IP blocking, IPS filtering, Fail2Ban, etc.

kescobo · January 13, 2024, 5:18pm

So, it was indeed OS-level firewalld setting. I just had to run

sudo firewall-cmd --permanent --zone=public --add-port=443/tcp

as suggested in the link from @Rip