I had decided to move one of my blogs to a self-hosted model to get more control over plugins and other things. After reading up a bit on different vendors I found Digital Ocean to be my choice. What’s not to like with a place that can spin up a complete Linux with WordPress installed and ready for me to use? Yes, it only takes them seconds and it is powered by SSD. Adding that it costs $10 per month ready to go and for $2 a month they include a preconfigured weekly backup. Seeing this and knowing it is lightning fast, I could not think of a reason to try someone else.

So I took my domain “mathiasmagnusson.com” that has just a couple of pages and no blog posts. All blogging is done on sub domains on that. This should be easy and let me test the move without interrupting the other blogs, right? It was easy, I imported the site from wordpress.com, set a new theme, and made a few different tweaks. Accessing it by ip-address worked great, it was everything it used to be and looked better. Yes, that is probably because it wasn’t a piece of art before the move (either).

Now all that was left was to point the DNS A-record to my new place. Or so I thought. I started with pointing the DNS at there using local name resolution (/etc/hosts) and a made up name “mywp” and it worked perfectly even after changing the name in WordPress for where it was located so all pages was linked to using mywp instead of the ip. Time to change GoDaddy to point to the ip of my new site. After doing that the site worked on ip, but failed on access with name. It reloaded using https and I got a connection refused message. As the tab showed the WordPress logo, I made the conclusion that it must be WordPress sending back a redirect on http when accessed with a public name.

I started a service ticket with Digital Ocean and we got to over 15 replies over the weekend where they did the best they could to get more and more info from me and why I think it is their server acting up and me trying as hard as I could to prove what was self evident to me – of course it had to be on their server or network, it was a connection refused and a reload with https. Nothing else in the chain would do that.

At this point I spun up server after server proving to myself that this could be proven without doing anything more than just getting the server created and then using local name resolution. At the same time I did a deep dive into the WordPress code, reading on ssl, certificates, how it should work. I found that it has snake oil certs installed and it really seems like the https stuff is half baked, but why is not the Internet littered with posts about it? As I depart on the SSL-stuff the discussion on why it even happens continues. I will explain that first and get to what I learned and did with SSL later.

It turns out that Chrome has a cache for sites/pages you have visited before that was serving https then. So it is nice enough to silently rewrite all such page requests for you. Normally this is a great function. But when you move from a place that used https (wordpress.com) to one that does not like my new site, it makes all accesses to pre existing pages fail. The exact opposite of what one wants, the intent is to make such a move transparent to all visitors.

Chrome even has a function to add sites/pages to the cache so you can try breaking things for yourself. Should you have this problem or want to play with this, go to chrome://net-internals/#hsts and add or remove. If you encounter the issue with automatic rewrites by chrome, you want to remove the site here.

There is a feature meant to help in that it lets sites tell chrome to always enforce https for it. That is a good thing, until it moves and the site still has the same exact name. Then it can make every reader of your site/blog unable to read it. Thus, moving from a https-capable site that uses HSTS – HTTP Strict Transport Security – to one only capable of http can make your readers lose access completely if they are not aware of this and most of them will not be.

This has become a very long post now, so the explanation for how I got my site https-capable will be written up in its own post.