Windows Azure Web Sites: SSL Support and configuration

Finally in the first week of June 2013, it has been announced that Windows Azure Web Sites will provide native support for SSL, which includes both SNI SSL and IP based SSL for custom web site domain names. This feature was one which took some time to be implemented and finally has been introduced. Before this the only way of doing SSL was via Cloud Service & Rewriting the URL. Refer this article: https://www.bradygaster.com/running-ssl-with-windows-azure-web-sites 

The users can view and configure this feature on the CONFIGURE management page. Below is a snapshot of what the users would view:

The certificates and the ssl bindings section are the ones which were incorporated into the portal. Before we discuss further we need to understand there are certain pre-requisites which has to be acknowledged.

• This feature is not available to sites which are running in either Free or Shared mode. (SSL support for Shared mode maybe added later, but there is not time frame provided for this.)

• ssl bindings section is enabled when the user has a valid custom domain name added for that site. which also implies that in order for the Choose a certificate drop down to work the user should configure a custom domain name for the website.

Adding a SSL Binding to the Windows Azure Web Site

Once the site has the provided pre-requisites, the user is ready to configure a SSL binding for the site. Lets ensure the web site is scaled to RESERVED before we proceed.

Uploading the Certificate

• Go to the Windows azure Portal and select Web Sites.
• Select the site (running in RESERVED mode) for which we need to configure this binding.
• Go to the CONFIGURE management page.
• Scroll down to the certificates section.
• click on upload a certificate. This would pop-up a window as shown below:

• Browse to the location of the file and select the file.
• Enter the private key password.
• Click on to upload the certificate. If the upload is successful the portal would reflect the change.

Adding a custom domain name

Follow the instructions in the following URL to configure a custom domain for your site: Configuring a custom domain name for a Windows Azure web site.

I added a custom domain on one of my Web Sites for the demo. Here is the snapshot:

Adding the SSL Binding

On WAWS, the user can configure the following 2 types of bindings:

1. IP based SL binding.
2. SNI SSL binding.

SNI SSL Binding

• Go to the ssl bindings section on the CONFIGURE management page.
• Click on the Choose a domain name drop down to select one of the domain names configured for the site.

• Click on the Choose a certificate drop down to select a certificate from the list of certificates uploaded for this site.

• SNI SSL is the default option, so no changes has to be done.
• Click Save to commit the changes. The user will get a warning notification regarding the impact this may have on billing for the site.

• click on YES to proceed. Upon success the below message will be seen.

IP based SSL Binding

• As specified in the earlier steps, the user has to upload a certificate and configure a domain name for the website.
• Once done, he could choose it for the corresponding drop downs as we showed earlier.
• Now select IP Based SSL from the third drop down to configure the IP based SSL bindings for the site.

• Click Save to commit the changes. The user will get a warning that this may impact the billing for the site.

• Click on YES to proceed. Upon success, the below message will be seen.

• Once IP Based SSL binding has been added, the site is assigned a new IP Address by WAWS. This IP Address is displayed as Virtual IP Address on the DASHBOARD page. We need to use this IP address and update the DNS records to point to the new VIP.

• The above VIP is different from the one seen in the CONFIGURE management page. The website will be pointing to both the IP addresses. The difference is that when domain name points to the default IP Address it is equivalent to SNI binding and when the domain name points to the newly assigned VIP it uses the IP Based SSL. To notice this difference, access the URL over HTTPS from a XP client running IE 8.

• The A record for the domain name needs to be updated to point to the new IP Address. If there was a CNAME pointing to <sitename>.azurewebsites.net, then it has to be removed.

*******IMPORTANT*******

Pricing for the SSL Connections for Windows Azure Web Sites

The users have to shell out more money when they configure the website to use IP Based SSL. This is very obvious, as this requires a dedicated IP (a resource) to be allocated for the website. This is also an expensive resource.

SNI SSL is comparatively cheaper as it doesn’t need a dedicated IP Address. However, it has own limitations as the non-SNI compliant browsers will not be able to access the site.

Windows Azure Pricing Calculator for Web Sites: https://www.windowsazure.com/en-us/pricing/details/web-sites/

Comments

• Anonymous
  March 26, 2014
  When I've run this for my website. It has the following error on Google Chrome (and other browsers as well). You attempted to reach pandomi.com, but instead you actually reached a server identifying itself as *.azurewebsites.net. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of pandomi.com. How to solve this problem?

• Anonymous
  May 04, 2014
  The comment has been removed

• Anonymous
  July 23, 2014
  Is there anyway once you have an SSL certificate installed on a Website to have it require SSL/HTTPS and disable HTTP access?

• Anonymous
  December 03, 2014
  Are there any plans now to roll out SNI SSL to Shared websites?

• Anonymous
  December 03, 2014
  @Ian: There is no option currently in the portal to enforce only HTTPS access for your site. However you may use URL Rewrite rules to achieve this functionality. @Graeme: As of now there are no plans to roll out SNI SSL to shared websites If this is a must requirement then you may pass the feedback here: feedback.azure.com/.../169385-websites

• Anonymous
  December 17, 2014
  @teerachi - perhaps your SSL issuing authority uses intermediate certificates and the pfx you uploaded didn't contain the intermediate certificate