Making an Azure static website secure

7 years ago

One thing that’s been niggling at the back of my mind for a little while, is that of making my various domains secure. Getting and installing a certificate. Making HTTPS the default. Using SSL. All that jazz, mostly triggered by the news that Chrome and Firefox are going to start shaming – er, sorry, indicating in the address bar – those sites that are not secure.

But, OK, I admit it, all the stuff I’ve read just seems to point out how deeply involved it all is, how expensive, and so on. This ain’t a flick of a switch. Finally, though, it was time to bite the bullet. I decided it was time to do at least one, to find out the problems (and how to resolve them), and then to apply that to my other domains. For simplicity, I chose my preferred landing site, jmbucknall.com, which is a static website (no server code or config files) that is hosted on Azure. Even simpler, I didn’t have to worry about subdomains: there’s just the bare domain and www.jmbucknall.com which I don’t really use.

Buying an SSL certificate

The first step then is to acquire an SSL certificate. For this I decided to use Cheap SSL Shop, since they provide a simplified access to the major SSL certificate providers, and, should I need it, some support. I chose a Comodo certificate mainly because it was the cheapest option and I was experimenting. I went for a two-year “Comodo Positive SSL” certificate and it came to about $15.

The weird thing about this step is that Cheap SSL Shop don’t ask for the domain name, which threw me a bit. Instead what happens is you buy a “generic” certificate (if I might call it that), and then after it’s paid for, you then go on and “configure” the certificate for a particular domain.

Configuring the SSL Certificate

Now the fun starts. Once the payment has gone through, you display the order and there’s a “CONFIGURE SSL” button. Click that, go through a “I’m not a robot” test, and then we’re into the Comodo site and it’s asking for a CSR (Certificate Signing Request). Wut? What’s that when it’s at home?

This one threw me for a while. After a bit of research, I decided to follow a recommendation on the Azure blog and use a freebie app called the DigiCert Certificate Utility.

I downloaded it (no need to install, it’s just an EXE in a ZIP file), ran it, clicked on the SSL tab, and then clicked the Create CSR link. It shows a dialog where you enter the Common Name (the domain name), various other bits of info, a key size (go for the max), and a provider (leave this as the default).

Once you click on the Generate button, it’ll think for a while, and then show another dialog with the CSR as a text blob that can be copied to the clipboard.

Back to the browser and the page asking for the CSR. Paste it in. Click Continue.

The site decodes the CSR and shows the info that was encoded. Check it. The page then asks for a method to approve the CSR. I chose email, and then chose an email address for Comodo to use for approval (I went for the email I’d used to create the domain name, the one WHOIS knows about; the others were all made up ones like admin@, postmaster@ and so on). It then asks for the Server Type: bit weird this, there’s no Azure option so I just chose “OTHER” and entered the same email I’d just chosen. Click on Continue.

Next page requires a bunch of contact information to be entered. After that it’s a summary page, from which you can place the order for the certificate.

What’s happens then is Comodo sends an email to the approval email address with a link to verify the domain name and validate that you are in control of it. After that validation is complete, and some time passes, you’ll get an email with the certificate. Even better, the certificate is valid for the bare domain, as well as the www subdomain.

Installing the SSL Certificate

Onto more wacky stuff, now. Log into Azure and make sure the App Service that is your website is of a sufficiently high pricing plan/tier to accept an SSL certificate. Change it, if necessary.

If you then click on the “SSL certificates” setting, you’ll see that there’s an option to upload a certificate. If you do so you’ll get a dialog asking for a PFX Certificate File and its password. WTF is a PFX file? All you have is a CRT certificate file that was emailed to you. Where do you get this PFX file?

Enter our old friend, the DigiCert Utility. Run that, and this time click on the Import link. A dialog is shown where you can enter the name of your domain’s CRT file. Give the imported certificate a Friendly Name (I just used the domain name), and import it. From the main window, select the certificate, and then click on the Export Certificate button.

The Certificate Export dialog is shown. Leave the defaults (that is, export the private key, pfx file, include all certificates), click Next. Now type in a (long, randomized) password for the export.

Once this done and you have the PFX file, you can go back to the Azure dashboard and import the certificate PFX file, using the password you created for the export.

Completing the SSL binding process

And we still haven’t finished! Yes, Azure has your certificate, but now you have to “bind” it to the domain. Just below on that SSL certificates Settings page is where the Bindings are made. Click on Add binding, a dialog is shown, choose the domain and the certificate, then click Add Binding. Do it for the www subdomain too.

Done? Not quite. There’s one final step to make: forcing HTTPS only. Go to the Custom domains Setting page, and under the Custom Hostnames panel is a toggle labeled “HTTPS Only”. Click it on. At this point, your static site should be secure and always using SSL.

Time to verify your HTML

Done? Well… at least that was what I thought, however when I navigated to jmbucknall.com Firefox warned me of a couple of issues. First of all, in my HTML for the site, I’d explicitly used http://jmbucknall.com/ in a couple of places (HTTP!) instead of a relative URL. Fixed that.

The next one was that I’d been using a stylesheet link with a non-HTTPS URL in the <head> element (in other words, using a non-secure link to something to render the secure page), and Firefox was having none of it (“Firefox has blocked parts of this page that are not secure”), and that was just as easy to fix.

After that, all was well. A secure static site on Azure. Shown with a locked padlock icon on Firefox and Chrome.