Website down
Someone told me my website was down. He was probably the only one using anything there: it isn't anything critical. That is why up to then I was unconcerned that it was running on an Always Free instance that was never updated since it was set up.
But now it is throwing connection refused errors. (PS this blog is a subdomain of that website, but blog.jochenvandenbossche.dev is just a CNAME DNS-record pointing to hashnode.network, so that still works.)
I kind of guessed the Let's Encrypt certificate wasn't renewed for some reason. I can still connect with SSH etc. When I tried to force a refresh from the command line, there was some kind of message regarding an outdated version of OpenSSL (the python package). When I tried to update that, I noticed all of this was still using Python 2.7... That is when I decided to start a new webserver from scratch.
So, I stopped an instance that I wasn't really using and spun up a new one. Apparently, the Always free instances are Ampères these days? The 6GB of RAM won't hurt. I created some users (one in my name, one called webserver).
I installed NginX, according to Install the NginX webserver in Oracle Linux (docs.oracle.com) but diverted a bit to also apply the security settings described in NginX and PHP-FPM what my permission should be (www.getpagespeed.com).
I added a separate /etc/nginx/conf.d/jochenvandenbossche.dev.conf, setting up a separate server to handle requests for dev.jochenvandenbossche.dev, www.jochenvandenbossche.dev and jochenvandenbossche.dev. My DNS was already pointing www.jochenvandenbossche.dev and jochenvandenbossche.dev to the old server (the one that started refusing connections recently); I added a new A-record pointing dev.jochenvandenbossche.dev to the public IP address of the newly created Ampère.
From the server itself, curl 127.0.0.1 and curl 141.*.*.* (the public IP) both resulted in the default NginX page, as expected: the separate server only serves domain name-based requests. And, lo and behold, curl dev.jochenvandenbossche.dev resulted in the separate little index.html that I set up. great!
On my laptop, I have WSL running an Ubuntu. Doing curl dev.jochenvandenbossche.dev from there also resulted in the expected html. Nice, everything works! Joy, joy joy!
So eventually I opened a browser (Vivaldi in my case) to surf to http://dev.vandenbossche.dev and I got a connection refused error. Bummer.
At first, I thought it was a DNS problem. Doing an nslookup from both Ubuntu (under WSL) and a command prompt indeed showed my ISPs DNS being used from Ubuntu and Google.dns from Windows. But both returned the same correct IP address.
After calling out on Reddit (see this topic) it turned out to (probably) be SHTS, a browser (+webservder) security feature. The Network tab of the Developers Console in Chrome showed my HTTP request resulting in a 307 Internal Rederect to an HTTPS request...
And since nothing regarding HTTPS is set up on that NginX yet, it will be blocked.
Opening the chrome://net-internals/#hsts "page" and querying jochenvandenbossche.dev (the top-level domain) shows that SHTS is being applied, including for subdomains:
So, while the old server itself (jochenvandenbossche.dev) can't serve anything anymore, it is still capable of requiring the usage of HTTPS on all its subdomains, even on dev.jochenvandenbossche.dev, which didn't exist when it was set up.
So, now I hope that when I set up Let's Encrypt it will take into account the other two domains as well. I guess/hope that changing the DNS-records for the existing domains (pointing them to the new server) should do the trick.