# 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)](https://docs.oracle.com/en/learn/oracle-linux-nginx/index.html) but diverted a bit to also apply the security settings described in [NginX and PHP-FPM what my permission should be (www.getpagespeed.com)](https://www.getpagespeed.com/server-setup/nginx-and-php-fpm-what-my-permissions-should-be).

---

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](https://vivaldibrowser.com) 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](https://www.reddit.com/r/oraclecloud/comments/11ck3pg/curl_works_browsers_dont_ol87nginx/?utm_source=share&utm_medium=web2x&context=3)) 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 HTTP*S* request...

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1677434569904/d7da7ea0-54d9-4310-8a16-f23eecec2855.png align="center")

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*:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1677435746110/31ffda37-d77a-4bfc-87d6-14f43d0adfe1.png align="center")

So, while the old server itself (`jochenvandenbossche.dev`) can't serve anything anymore, it is still capable of requiring the usage of HTTP*S* 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.