Migrating NOVALISTIC.com to HTTPS

Last November, it was my domain NOVALISTIC.com’s sweet sixteen!

As a birthday gift, I got my site its very own SSL certificate, courtesy of DigiCert through their Microsoft MVP offer, and as of this week my site has now been fully transitioned to HTTPS!

SSL (Secure Sockets Layer) is an Internet security standard that enables encrypted communication between your browser and a website, preventing attackers from eavesdropping on or even tampering with information. This is more important for sites that collect sensitive information such as government and e-commerce sites, and less so for personal sites, but as SSL certs become more accessible and affordable I don’t see any reason for me not to secure my site, so, here I am!

In this entry I’ll be sharing my personal experience of obtaining and signing a certificate, setting it up on my server, and migrating both static and dynamic content on both the main domain and its subdomains.

As this is about my own experience, this will not be a comprehensive how-to covering all the various ways of setting up HTTPS on your site (though I’ll cover some ground in the overview), but I hope you learn something about the process in general. This being my first ever experience with SSL certificates as a server administrator, I certainly learned a whole lot!

Table of contents

1. Overview of SSL certificates
2. Obtaining my SSL certificate
3. Setting up my SSL certificate
4. Setting up redirects
5. Migrating content

Overview of SSL certificates

As mentioned above, SSL is a technology that enables encrypted communication over the Internet. A website lets browsers know with an SSL certificate that connections are encrypted and it can be trusted.

Until a couple of years ago, SSL certificates cost money. A lot of money.

But not anymore. For a personal site such as mine, realistically, Let’s Encrypt is all that’s needed — Let’s Encrypt SSL certificates are completely free of charge, and automated so once you set them up you don’t have to worry about renewing them unless something unexpected crops up. (More on renewal in a bit.)

The main reason I chose DigiCert over Let’s Encrypt is because I’m an MVP and of course I’d take certificates from one of the largest commercial certificate authorities (CAs) in the world with enterprise-grade customer support who’s willing to offer them free of charge to MVPs. (Also, if I’m honest, it was seeing their offer in my list of third-party MVP perks, as well as my domain’s then-imminent sweet sixteen, that motivated me to finally set up HTTPS, so my mind was already made up by then.)

Alright, now that that’s out of the way… there are a few kinds of SSL certificates to choose from depending on your needs:

• Single domain certificates secure one domain name per certificate.

• Multi-domain certificates secure up to a certain number of domains and subdomains. This number is entirely dependent on the CA.

• Wildcard certificates secure one domain, as well as an unlimited number of subdomains of that domain. This is useful for sites that have dynamic subdomains.

There are also different validation levels for certificates: domain-validated (DV), organization-validated (OV) and extended-validated (EV), but they’re outside the scope of this entry; mine’s domain-validated. The reason I went out of the way to explain the different kinds of certificates is because mine’s currently a wildcard certificate, but I realized in hindsight that what I actually needed was a multi-domain certificate, and now I understand why. Oops. I really should be talking to DigiCert about getting a new certificate but I’m lazy, heh.

Obtaining my SSL certificate

But yes. How did I procure an SSL cert from DigiCert? Since they offer certs directly to MVPs, I applied for one separately, providing my details, and before I knew it I was on my way to the order form. Ordering an SSL certificate was just like ordering any other subscription: choose the kind of certificate I wanted, enter my details, enter the domain name(s) I wanted to associate the certificate with, and place the order.

As I said above, mine’s a DV certificate, so one of the steps involved in verifying my domain was getting me to confirm I was in fact the owner of the domain based on my WHOIS records. No biggie. I also needed to provide the DigiCert team with some identification information. And it was a pleasant experience! It was straightforward enough that I didn’t need to ask questions, but they were friendly and helpful, and at no point did I feel like I wasn’t interacting with a human being.

And finally I needed to generate a certificate signing request (CSR) on my server with which to sign my certificate. A Small Orange shared hosting servers are managed using cPanel, which DigiCert happens to have a guide for, so this was easy enough, too: just enter the domain name(s), my details, and bam. 2048-bit CSR ready to go.

In just a couple of hours, my DigiCert SSL certificate was issued and ready for use.

Setting up my SSL certificate

I don’t often need to manage my server using cPanel, but given that I’ve been using it on and off for over 15 years (yes, I’ve known and used cPanel since I was 10!) across four hosting providers, I never take it for granted. That said, while DigiCert also has a guide for applying ready-made SSL certs to Apache servers using cPanel, I didn’t need it; I figured it out on my own. All you cool kids with your SSH terminals can probably skip this as none of it will be relevant to you.¹

I downloaded the certificate (itself a .crt file) and uploaded it to cPanel’s SSL certificate manager. Then I went to the host manager, browsed for my certificate, picked my main domain, and installed it. One by one I repeated these steps with my subdomains (including dev.NOVALISTIC and blog.NOVALISTIC).

Immediately, I could navigate to my site by entering https://NOVALISTIC.com in the address bar, and my certificate details were proudly displayed on my browser, verified by DigiCert:

All that’s left now was to update existing references to my site to point to HTTPS. Since I have links to my site from my profile on many sites, this will probably take forever, so I cast a convenience net by setting up redirects for each of my main domain and my subdomains.

Setting up redirects

Since you basically want HTTPS all the time on your site, it makes sense to redirect all HTTP traffic to HTTPS. It’s a good idea to do this as early in each server response as possible, so the server doesn’t have to think about anything else as soon as it realizes the request is not secure.

On Apache, this is easily accomplished with a mod_rewrite rule. Here’s what my top-level .htaccess looks like:

RewriteEngine on

# Canonicalize to https://novalistic.com
RewriteCond %{HTTP_HOST} ^www.novalistic.com [NC,OR]
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://novalistic.com/$1 [R=301,L]

It’s no different for my subdomains. Here’s dev.NOVALISTIC’s:

RewriteEngine on

# Canonicalize to https://dev.novalistic.com
RewriteCond %{HTTP_HOST} ^(?:www\.)?novalistic\.com [NC,OR]
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://dev.novalistic.com/$1 [R=301,L]

(In case you’re wondering, the (?:www\.)? bit in the HTTP_HOST condition just forces both www.novalistic.com/dev and novalistic.com/dev to redirect to dev.novalistic.com.)

With the redirects set up, any request to my site, internal or external hyperlink or manually typed, is eventually going to be an HTTPS request. However, a page isn’t necessarily secure just because the request was over HTTPS. A page can still be insecure if it references external resources insecurely, such as images, stylesheets and scripts over HTTP. These need to be corrected, as a page with mixed content isn’t completely and truly secure, and browsers will emit warnings to that effect.

Migrating content

Needless to say, both static content and dynamic content need to be migrated. Fortunately, migrating simply entails changing all http:// URIs to https://. Yes, that’s it! Assuming you’ve set up HTTPS correctly, of course.

My main site runs on a completely custom CMS. Having said that:

• Most if not all of the static content lives in the template files, so it’s just a matter of performing an app-wide find-and-replace and reuploading the template files.

• Dynamic content is almost entirely powered by Markdown, despite comprising several custom content types stored in their own database tables, so this was just a matter of editing in-place with find-and-replace as well.

Most of this was done within the first day after I got my SSL certificate installed. What took much longer (read: what I sat on for much longer) were my blog posts, not because they’re much more complicated to migrate (seriously, it’s all Markdown), but because of the sheer number of attachments being referenced by my posts which all had to be updated, post by post. Which I finally sat down for an hour to get done this week.

Once that was finally done, though, blog.NOVALISTIC was finally fully migrated, and with that, my transition to HTTPS is complete.

That’s it! I hope you enjoyed, and perhaps learned something from, reading what I’ve shared.