Securing your Windows Azure Web Sites (WAWS) with HTTPS and SSL

With the rapid increase in identity theft and various forms of cybercrime, security your website with Secure Socket Layer, or SSL for short has become more important and more common. If you are hosting your web site on Windows Azure Web Sites (WAWS), you might be looking into setting it to use HTTPS, and in this guide, we will see how to do so.

The first step for this seems to be getting a digital certificate…right? Well, not necessarily. The first step is actually deciding whether you want to have your own custom domain, or to run your site using Azure’s default domain of Azurewebsites.net. The reason for this being the 1^st step is that Windows Azure Web Sites actually comes pre-configured to run on SSL, and if you don’t want your own domain, then you can use SSL immediately. All you have to do is simply browse to it! In your browser, change the prefix from HTTP:// to HTTPS:// and voila! Your site will respond and you will have a secure connection to it. However, we do not recommend using this to secure sensitive content or applications, because the wildcard certificate used is generic for all Azure Web Sites.

If you do want to use your own domain with SSL, setting up takes several additional steps. Before taking any action, it’s important to keep in mind that SSL with custom domains is only supported for sites on the Standard tier. If your site is current in the Free or Shared tier, you’ll have to switch to Standard, and that will incur additional costs. Please refer to our pricing guide or Azure Calculator to examine the expected costs.

Once you have chosen your domain and set your site to use it, the next step is getting a digital certificate to match your domain. When buying a certificate, you have 3 choices:

1. Buying a simple certificate to match your website URL. This is the cheapest option, which could be had for as little as $8 per year at stores such as https://www.thesslshop.com
2. Buying a SAN (Subject Alternative Name) certificate. These are certificates that match more than one URL under the same domain, and are an economic solution for companies with several websites. Instead of buying multiple certificates, each for a single URL, you buy one certificate that covers several, and pay less than you would have paid for the multiple certificates.
3. Buying a Wildcard certificate. This is a certificate that matches any subdomain under your domain, and even though it’s the most expensive type, it’s the most financially sound option for companies who have many sites. For example, if your company has 30 websites, paying $79 for a wildcard certificate is much cheaper than paying $240 for 30 single certificates.

To actually buy a certificate, you will need to choose a provider, and go through a certain process to generate the certificate in the form of a PFX file. We have outlined this process in this article.

Once you have your certificate, enabling SSL is quite simple. Here are the steps:

Stage 1: Switch your site to Standard.

Before making the switch, you might consider removing spending limits you might have configured. While this is not a requirement, running a commercial site with spending limits is usually not done, because once your limit is reached, your site will be taken offline until the next billing cycle. The steps for switching your site to Standard are:

1. Log into the Azure management portal
2. Click on your web site
3. Switch to the Scale tab
4. Under General, click on the Standard button to switch the site to Standard.
   
5. Click Save

Stage 2 – configure SSL

To configure SSL, you will upload your certificate and bind it to your site. The steps are:

1. Log into the Azure management portal
2. Click on your web site
3. Switch to the Configure tab
4. In the Certificate section, click Upload a certificate
   
   
5. Upload your certificate PFX file and specify the password for it (you would have created one when exporting the certificate to PFX)
6. Under SSL Binding, Select your custom domain from the dropdown. If you haven’t configured a custom domain yet, click here to read about doing so:
   
7. Select the relevant certificate from the drop down (right now, you have one, but in the future, you might have more
8. The 3^rd drop down allows you to enable or disable SNI. Normally, you would prefer to use SNI, but if you expect your site to be visited by very old browsers (Windows XP or older), select IP Based SSL. If you examine SSL pricing, you will also see that using SNI is also financially attractive.
9. Click Save

With any luck, you’re done, and your site will now respond to request sent to HTTPS.

Problems?

The most common issue you might run into is inability to upload your certificate to Azure. In a previous blog post we discussed how to obtain a certificate, and this is a good time to remind you that it has to be an exported PFX certificate, and not the file you got from your certificate provider (even if it’s a PFX file as well). The reason for this is that to assign the certificate to a website, Azure needs to have the private key that’s associated with the certificate. The certificate generation process starts off on your own computer, when it creates the private key, and that is then matched by your certificate provider. The file that the provider gives you back needs to be imported to the same computer that originally issued the request, and that makes a “complete” certificate. If you tried to upload the file given by the provider, it would not give Azure the private key, and that makes the certificate invalid.

Another variation of this is exporting the certificate to a PFX incorrectly. The export must include the private key (and that’s why you need to give a password as part of that process) and if you forgot to check that box when doing the import, it won’t work.

Another common question when using a certificate is related to browsers showing some kind of security warning when your users try to browse to the site. This happens when the browser doesn’t like the certificate, and different browsers are designed to react differently. Some would just show a warning, while others might completely block the site. The most common cause for an error is a mismatch in the URL. A certificate is issued for a specific URL, and if the actual URL is not a perfect match…that’s a potential security risk. A single misspelling could ruin your day, so that’s important to keep track of.

One more common issue for a security warning in the browser is an untrusted certificate. Certificates are typically issued and sold by commercial providers, and all modern operating systems come pre-configured with the root certificates of all major commercial providers. However, if you issued the certificate from a private certificate authority (such as a CA server owned by some private organization or your own company), it will not be trusted and would lead to errors. Using a private certificate is not supported by Azure Web Sites, so if you do want to use SSL without purchasing a certificate, you could use a self-signed one instead.

As we said above, all major commercial providers are supported by default, but occasionally, you might run into a provider that uses intermediate certificates in his trust chain. Some certificate providers have split up their certification path to 2 pieces, so instead of a root CA issuing your cert, it’s issued by a lower-level “intermediate” server, which is trusted by the providers root. In such a case, the certificate might cause the client browser to issue a warning, and this means that the publisher’s intermediate certificate will need to be uploaded with your certificate. When you export your certificate into a PFX, the entire chain should be included in it, and this option is enabled by default:

If, however, you unchecked it, or did the export in some other way that doesn’t include the certificate path, this could lead to problems with some providers. If unsure, we recommend performing the export again and making sure this option is selected.