Boy, what a rabbit hole I just went down. Brace yourself for a story. I pulled one simple thread and woke up two weeks later with a brain full of learning and experience. Time to tell you about it.

It all started when I pushed a message on Twitter. I advertised a weird website I had created: www.sabotagethatproject.today. The site gives you a new idea on how to undermine your project, product or even company at each refresh of the page. And of course you can suggest new ideas on the Github repository.

Twitter announcement of the sabotagethatproject.today website with a picture of DrEvil

Soon after my Tweet, Daniel Marbach created an issue on Github. He told me that I should activate SSL and how. And he was very right in doing so.

Setup SSL issue from Daniel Marbach on Github

SSL ist the encryption mechanism used by Websites. It makes sure that when you request a site, you get that site without anyone messing with it. That’s the “S” in “HTTPS”. That's also the small padlock or shield on the left of the address bar of your internet browser.

Daniel linked an article of the security expert Troy Hunt. There you will find 4 videos, that make switching SSL with Cloudflare awfully easy. Switching SSL-ON had been on my todo-list for months if not years already. So I decided to finally give it a try.

At first, it was easy. I created a Cloudflare account, swapped the DNS on my registrar (OVH). And “voila”, 24h later, my sabotagethatproject.today website had SSL. Indeed it was easy. I was thrilled. I had pushed that task for so long, and finally it was working. NICE! So I decided to roll that change for my other domains, I was on a high:

Half way through, I realized that my email redirections were not working anymore. I rely on emails for timbourguignon.fr, SeeCFP.com and DevJourney.info. So I rolled back the changes. I then concentrated to troubleshooting that issue on the sabotagethatproject.today domain first.

It took me a week emailing back-and-forth with OVH, to pinpoint the problem. They had no idea where the problem came from. They claimed the configuration was fine on their end. They kept pushing the blame on Cloudflare. I finally stumbled upon a website that explained the problem. The default mail server from OVH doesn’t allow such a redirection when using external DNS. The workaround is to activate a free package OVH provides. This comes with 10Mb hosting & email support and gives you access to a different mail servers. This alternative mail servers supports such a redirection.

I tried it on the sabotagetatproject.today domain, and for some reason that I still ignore, it worked. In hindsight, given the configuration I was running, it shouldn’t have worked. But hey, it did.

Waiting in line to donate blood on Tuesday, I had nothing better to do. I went through the dumb steps of activating it, for all my other domains from my smartphone. By the time I came home, I had a Twitter DM waiting for me. Someone was asking if I had pulled the plug on SeeCFP.com, because the website was down. Damn! When activating this package, OVH rewrote the DNS rules telling the domains where the website is. Why it wasn’t the case for the sabotagethatproject.today site, I still don’t know. But here's the result: all my websites were down. They were all displaying a “nice” “under construction” banner 🤮. I had to face it, my sites were already all down, time to get to the bottom of it. I decided to clean things up hosting-wise as well in the process.

First, I reactivated the Cloudflare DNS for all my domains. This change takes 24 hours to replicate, so I had to do it soon early on. Then I created a Github Pages repository for each site. Those are static websites running Jekyll. They auto-deploy when you push changes to a Github repository. For this, I had to create one "Github Organization" for each of my sites. I added my Github account as owner of those organizations. Finally I created a repository called "<organisation_name>.github.io" in each organization. After that, I stopped using the hosting I bought on OVH almost 15 years ago with the domain timothep.net.

Then came the DNS tweaking on OVH to reflect those changes. That meant adding 4 x A records pointing to the Github pages servers (185.199.108-111.153). Then adding one CNAME record pointing the "www" subdomain to *.github.io. I then removed all TXT records. I removed the remaining A and AAA records that pointed the root domains. I also removed the eventual CNAME records pointing the "www" subdomain somewhere. Finally, I added the new MX records to point to the new mailservers OVH provided. Least to say, it took me a while to find the correct configuration. And to complete this changes marathon, I had to replicate all the changes made in OVH on Cloudflare. Then activate forced HTTPS there. I finally activated custom domains and force HTTPS in the Github repositories.
Websites back online!

So what did I learn?

  • I now really understand how A, AAA, CNAME, TXT and MX records really work. And I now have a way better understanding of how SSL works.
  • DNS Records are not a good place to play trial-and-error. When OVH says “the changes will be effective in 24 hours” they sometimes mean it, but sometimes they don’t. Sometimes the changes are effective right away. Sometimes it takes 24 hours. Thus it renders any trial-and-error process more than a pain-in-the-ass. The DNS activation takes exactly 24 hours to replicate. DNS record changes & redirections are available in minutes. Yet the info messages for both is: “the changes will take up to 24h”.
  • Cloudflare is very smart. It sucks the configuration of your registrar upon creation. This is awesome. But it sets very high expectations. It took me a while to realize that it then does NOT update itself anymore. After creation you’re down to manual changes only.
  • Cache are fun, but sometimes they sucks. Testing SSL means testing the 4 configurations: "http://", "https://", "http://www" and "https://www" again and again. Doing their job, your network, your machine and your browser cache some requests. When they realize you have called this URL before, they serve you the old result instead. I had some weird effects where I was getting the new results on my phone and the old on my laptop. And clearing the browser cache and ipconfig cache didn't always do the trick.
  • I'm still unsure what I can and cannot see with the Linux "dig" command. It helped me troubleshoot some changes. But now that everything works, the dig output still don't match my expectations. But I haven't taken the time to explore further.

What is still to be done?

  • For whatever reason, 2 domains still don't let me put the checkmark for "Force HTTPS" in Github. The UI says: " Unavailable for your site because your domain is not properly configured to support HTTPS". Sofar I could not spot any difference. Probably a DNS propagation & cache problem. But Cloudflare force HTTPS anyway.
  • For whatever other reason, I cannot push changes to the Github repos from my machine. I can pull changes. I can make changes in the UI with my "timothep" account. But I cannot push with my "timothep" account. I opened a support request with Github for that. -> Solved. I deleted the credentials associated with Github in the git credential-manager and after re-entering my credentials, it worked.

But hey, it's done! All my domains now run with SSL. All the HTTP requests are redirected to HTTPS. All pages run on Github Pages. And the Github.io domains are correctly masked. Isn't that great?

Thanks Daniel for the push. I am glad it is now done. And I am thrilled I learned so much in the process.

Photo by Fred Rivett on Unsplash