Moving My Site to Azure: DNS & SSL
This part 3 of a multi-part series on taking a real-world web site (mine) written to be hosted on an ISP (securewebs.com) and moving it to the cloud (Azure). The first two parts talked about moving my SQL Server instance to SQL Azure and getting my legacy ASP.NET MVC 2 code running inside of Visual Studio 2013 and published to Azure. In this installment, we’ll discuss how I configured DNS and SSL to work with my shiny new Azure web site.
Configuring DNS
Now that I have my site hosted on http://sellsbrothers.azurewebsites.net, I’d like to change my DNS entries for sellsbrothers.com and www.sellsbrothers.com to point to it. For some reason I don’t remember, I have my domain’s name servers pointed at microsoftonline.com and I used Office365 to manage them (it has something to do with my Office365 email account, but I’m not sure why that matters…). Anyway, in the Manage DNS section of the Office365 admin pages, there’s a place to enter various DNS record types. To start, I needed to add two CNAME records:
The CNAME records needed to be awarded an IP address by Azure
A CNAME record is an alias to some other name. In this case, we’re aliasing the awveryify.sellsbrothers.com FQDN (the Host name field is really just the part to the left of the domain name to which you’re adding records, sellsbrothers.com in this case). This awverify string is just a string that Azure needs to see before it will tell you the IP address that it’s assigned to you as a way to guarantee that you do, in fact, own the domain. The www host name maps to the Azure web site name, i.e. mapping www.sellsbrothers.com to sellsbrothers.azurewebsites.net. The other DNS record I need is an A record, which maps the main domain, i.e. sellsbrothers.com, to the Azure IP address, which I’ll have to add later once Azure tells me what it is.
After adding the awverify and www host names and waiting for the DNS changes to propagate (an hour or less in most cases), I fired up the configuration screen for my web site and chose the Manage Custom Domains dialog:
Finding the IP address to use in configuring your DNS name server from Azure
Azure provided the IP address after entering the www.sellsbrothers.com domain name. With this in hand, I needed to add the A record:
Adding the Azure IP address to my DNS name servers
An A record is the way to map a host name to an IP address. The use of the @ means the undecorated domain, so I’m mapping sellsbrothers.com to the IP address for sellsbrothers.azurewebsites.net.
Now, this works, but it’s not quite what I wanted. What I really want to do, and what the Azure docs hint at, is to simply have a set of CNAME records, including one that maps the base domain name, i.e. sellsbrothers.com, to sellsbrothers.azurewebsites.net directly and let DNS figure out what the IP address is. This would allow me to tear down my web server and set it up again, letting Azure assign whatever IP address it wanted and without me being required to update my DNS A record if I ever need to do that. However, while I should be able to enter a CNAME record with a @ host name, mapping it to the Azure web site domain name, Office365 the DNS management UI won’t let me do it and Office365 support wasn’t able to help.
However, even if my DNS records weren’t future-proofed the way I’d like them to be, they certainly worked and now both sellsbrothers.com and www.sellsbrothers.com mapped to my new Azure web site, which is where those names are pointing as I write this.
However, there was one more feature I needed before I was done ported my site to Azure: secure posting to my blog, which requires an SSL certificate.
Configuring Azure with SSL
Once I had my domain name flipped over, I had one more feature I needed for my Azure-hosted web site to be complete — I needed to be able to make posts to my blog. I implemented the AtomPub publishing protocol for my web site years ago, mostly because it was a protocol with which I was very familiar and because it was one that Windows Live Writer supports. To make sure that only I could post to my web site, I needed to make sure that my user name and password didn’t transmit in the clear. The easiest way to make that happen was to enable HTTPS on my site using an SSL certificate. Of course, Azure supports HTTPS and SSL and the interface to make this happen is simple:
Azure’s certificate update dialog for added an SSL cert to your web site
Azure requires a file in the PKCS #12 format (generally using the .pfx file extension), which can be a container of several security-related objects, including a certificate. All of this is fine and dandy except that when you go to purchase your SSL cert, you’re not likely to get the file in pfx format, but in X.509 format (.cer or .crt file format). To translate the .crt file into a .pfx file, you need to generate a Certificate Signing Request (.csr) file with the right options so that you keep the private key (.key) file around for the conversion. For a good overview of the various SSL-related file types, check out Kaushal Panday’s excellent blog post.
Now, to actual dig into the nitty gritty, first you’re going to have to choose an SSL provider. Personally, I’m a cheapskate and don’t do any ecommerce on my site, so my needs were modest. I got myself a RapidSSL cert from namecheap.com that only did domain validation for $11/year. After making my choice, the process went smoothly. To get started, you pay your money and upload a Certificate Signing Request (.crs file). I tried a couple different ways to get a csr file, but the one that worked the best was the openssl command line tool for Windows. With that tool installed and a command console (running in admin mode) at the ready, you can follow along with the Get a certificate using OpenSSL section of the Azure documentation on SSL certs and be in good shape.
Just one word of warning if you want to follow along with these instructions yourself: There’s a blurb in there about including intermediate certificates along with the cert for your site. For example, when I get my RapidSSL certificate, it came with a GeoTrust intermediate certificate. Due to a known issue, when I tried to include the GeoTrust cert in my chain of certificates, Azure would reject it. Just dropping that intermediate cert on the floor worked for me, but your mileage may vary.
Configuring for Windows Live Writer
Once I have my SSL uploaded to Azure, now I can configure WLW securely for my new Azure-hosted blog:
Adding a secure login for my Azure-hosted blog
You’ll notice that I use HTTPS as the protocol to let WLW know I’d like it to use encrypted traffic when it’s transmitting my user name and password. The important part of the rest of the configuration is just about what kind of protocol you’d like to use, which is AtomPub in my case:
Configuring WLW for the AtomPub Publishing protocol
If you’re interested in a WLW-compatible implementation of AtomPub written for ASP.NET, you can download the source to my site from github.
Where are we?
Getting your site moved to Azure from an ISP involves more than just making sure you can deploy your code — it also includes making sure your database will work in SQL Azure and configuring your DNS and SSL settings as appropriate for your site’s new home.
At this point, I’ve gotten a web site that’s running well in the cloud, but in the spirit of the cloud, I’ve also got an aging comment system that I replaced with Disqus, a cloud-hosted commenting system, which is the subject of my next post. Don’t miss it!