12 Jan 2017
The time is (almost) here for painless static site creation and hosting, so I gave it a try. I’m documenting the steps I took to get this site running for future reference, or in case someone wants to take the same path.
I didn’t want to compromise on these points:
- The site’s canonical URL is https://www.viktorroytman.com/
- It’s a static site, with maintenance-free hosting, more or less.
- The site’s source code is available on GitHub (and it is!).
With these conditions, my first thought was to use GitHub Pages, but unfortunately that doesn’t allow the use of a custom SSL certificate (as discussed (quite fruitlessly) here (and yes, I know you can fake it with Cloudflare)).
So I settled on GitLab Pages… mirroring a repository on GitHub. It makes sense, I promise.
Buying the domain
Creating a repository on GitLab (and GitHub)
The GitLab Pages documentation walks you through creating a repository for your site. The only extra step for me was to make it a mirror of the GitHub repository. I want the site’s main repository on GitHub so that I can make use of GitHub Issues for comments. I’ll talk about this in another post…
Aside: Why GitHub?
I know, I know. The GitHub Monoculture. I do think it’s a problem, but it does have one benefit — newcomers have a generally-accepted “standard” when it comes to software development online, particularly with regard to free and open-source software and Git. I think of it a bit like Ubuntu; while I can’t stomach Ubuntu myself, I can’t deny the value in having a widely-used exemplar as a “beginner” Linux distribution.
Setting the DNS records
- An A record with host
22.214.171.124(from GitLab’s guide).
- A CNAME record with host
Adding an SSL certificate
GitLab has a long-winded (and somewhat out-of-date) guide here for serving your site via HTTPS. Hopefully GitLab will introduce better integration with Let’s Encrypt in the future… Here is my version of the instructions:
- On the “Pages” section of the GitLab repository settings, add the URL of your site. Assuming you have the right DNS records, this will serve your site via HTTP.
Install Let’s Encrypt’s Certbot tool and run it with the following command. Note that I had to specify both the
wwwversions of my URL.
$ sudo certbot certonly --manual -d www.viktorroytman.com -d viktorroytman.com
After agreeing to a few things and supplying a contact e-mail address, you will see a message like the following. It will tell you to host some content at a page on your domain in order to prove that you control that domain. If you take too long, you’ll get an error message about an expired nonce, but you can always try again by re-running the command.
Make sure your web server displays the following content at http://YOURDOMAIN.org/.well-known/acme-challenge/<long_string> before continuing: <another_long_string>
Create a file in your repository (I called it
acme-challenge) that contains the content that Let’s Encrypt wants to see. The
permalinkstuff is specific to Jekyll, the static site generator I used, but the same principles should apply to most static site generators.
--- layout: null permalink: /.well-known/acme-challenge/<long_string> --- <another_long_string>
Once you’ve confirmed that you are actually hosting this new file, go back to the terminal window where you ran the
certbotcommand and hit the
Enterkey to have Let’s Encrypt look for your file. If all goes well, you should have an SSL certificate valid for 90 days now. However, if you (like me) want to use both
wwwURLs, you will have to host a second file much like the first one. You can see for yourself at my repository: here and here.
Go back to the “Pages” section of the GitLab repository settings and delete the entry you made before (without an SSL certificate). Recreate the entry, but now fill in the “Certificate (PEM)” and “Key (PEM)” fields using the files generated by Certbot. I had to make two entries, one for
wwwand one for non-
www. For me, those files were at these locations:
The good: You have hosted your free static site with custom domain via HTTPS!
The bad: You will need to renew your certificate at least once every 90 days.
Redirecting “bad” versions of the URL to the good one
I’ve gone to all this trouble to get
https:// working, and I intend
to have people visit the correct URL. Ideally, I would be able set redirect
rules on the web server, but I can’t do that with GitLab Pages. Instead, I have
to make do with GitLab’s suggestions. You can see how I did it here.
Was it worth it?
I’ve written quite a few words here… What have I to show for it? Personal
satisfaction, I suppose. Plus,
http://viktorroytman.com just doesn’t look
right, does it?
Comments: View this post's comment section here.