Determine if there's a justified reason to block/cancel an HTTPS request (but not HTTP)

I've recently found out that a microservice I've been using (worldtimeapi.org) isn't accessible via https (but is via http) on networks other than my home network (I've tried a university's public network, which has no password, and using my mobile network, both on the phone and via a hotspot).

On firefox on my laptop, I get PR_CONNECT_RESET_ERROR when using my mobile phone's network.

However the security certificate seems to be valid- my browser doesn't complain when entering the site on my home network via HTTPS, and random websites I found by googling "website security verification" say it's secure.

Which leaves me wondering - is my ability to access the site on my laptop an indication of a security problem in my own network, or... what?

How can I find out more about why a certain website might be blocked?

Edit: While Jonathan gave good suggestions on what to look at (and I followed some). In this specific case, I managed to resolve the issue by adding www. after the https://. the same networks which wouldn't let me browse to the website via https allow it when I add www.. I've gone back and forth to make sure it's not a coincidence, and it seems not to be.

Solution 1:

This is troubleshooting to isolate the error by testing each intermediate component.

Generally it looks like this:

Browser -> (local name resolution) -> internet -> dns Browser -> internet -> server Browser -> root-certs

First you need to make sure you’re always resolving the same up address.

Make sure all the devices you use have the same root certificate for verification.

Find out if you have a man in the middle intercepting your traffic. Difficult to do and that’s why they have tls and why sites should set hsts. Mitm is common and often leverages a downplay attack. That is convincing your client that the server doesn’t support higher encryption so the client falls back to insecure protocols like http.

Use a vpn like expressvpn or a digital ocean instance with openvpn installed.

Try different devices over the same network to determine if the fault is with your device or the network.

If the fault persists across networks, then it’s the server.