18 June 2013
To start June 2013 off, Windows Azure Web Sites released in preview form custom SSL hosting options for Windows Azure Web Sites.
Last night I flipped the switch (CNAME DNS updated) to redirect traffic directly to my Azure Web Site vs using a reverse proxy solution I had in production use before. Things are working great and later today I will spin down and delete the cloud service that was providing the SSL capability for me in the past.
The https://www.4thandmayor.com/ secure site and underlying web services are now being hosted by Azure Web Sites with my custom certificate.
Previously, the CNAME resolved to
4thssl.cloudapp.net, a Cloud Service Web Role that I was running that sat between clients and my Azure Web Site.
In the spirit of showing how much easier things are now, I wanted to show the certificate upload process, describe some differences and options, and then follow with general information about how I host my site on Azure today.
Note that SSL bindings require the paid Web Sites options. For 4th & Mayor and its app traffic of hundreds of thousands of mobile phones, I'm using multiple Small reserved instances.
This change has a financial impact on my mobile application as I'll be able to cut out the 2-instance Small (A1) Cloud Service deployment that was costing me $60 per instance x 2 = $120 US per month in base compute cost on top of the standard Web Sites costs.
Removing the workaround is a solid win for me and I believe Azure is providing a very good value with its custom SSL service, especially when I compare it to the former costs I had on Amazon with ELB.
I'm going to be using SNI SSL support with Web Sites which currently costs $6/month (this price includes a 33% preview discount) as of 6/18/13. So my savings now will be $112 per month or $1,344 yearly.
When I was using Amazon Web Services with multiple EC2 instances and an elastic load balancer (I had the load balancer do the SSL work with my custom certificate), the load balancer cost me $18/month plus data transfer - a clear win over the Cloud Service workaround, but also a comparable value to the SNI SSL pricing. In general Windows Azure provides load balancing for free as a valuable service on top of the underlying cloud or web site services.
My custom SSL wildcard certificate runs me about $199/year, so ~$17 per month. This is through a 3rd party SSL reseller service.
Basic SSL is available at no cost with Azure Web Sites, but custom certificates (in preview form) are an additional cost. Custom SSL certs were not available prior to 6/2013 without going through workarounds such as reverse proxies.
You can offer a secure connection between your Web Site and your customers today: Microsoft produces a wildcard
*.azurewebsites.net certificate and built-in SSL server support. This is often enough for a secure application on the simple scale, mobile apps, or web services.
However clearly providing a custom SSL certificate is a professional feature for a professional web presence, application or corporate deployment. Let's look at these options that are in preview form as of mid-June.
The Windows Azure Management Portal now exposes SSL certificates within the 'Configure' tab for your web sites.
From the Configure tab you can set properties such as environment variables, associated domain names, connection strings, .NET and PHP runtime versions, etc.
Under the new "certificates" section you first off need to upload a passcode-protected PFX certificate (PKCS12 package). Select the "Upload a certificate" option, find the file on your machine, and then provide the passcode.
If you're new to this process, you can follow my previous post about SSL certificates in general when it comes to the CSR, creating the PFX file, etc.
Once uploaded, you should see the certificate appear along with its thumbprint and other information.
Once the certificate is uploaded there's still a few more things to do:
Make sure that your domain name is setup for the Web Site. In the Configure tab this is done with the "Manage Domains" button. You may need to create CNAME or other verification DNS entries for this to work properly and prove that you control the domain.
This is pretty easy and just involves your DNS provider.
Two options exist in preview form for Web Sites right now. You can find current pricing information on the Windows Azure site at http://www.windowsazure.com/en-us/pricing/details/web-sites/ under the "SSL Connections" tab.
There is currently a preview pricing discount of 33% as of 6/18/2013. Reproducing this list here:
|SNI SSL||$6/month per certificate||Modern browsers|
|IP SSL||$26/month per cert||All browsers|
Briefly let's go over what SNI is: yes, more affordable and modern, but why?
Per Wikipedia's page about SNI, Server Name Indication (SNI) is effectively the protocol-level support for secure server certificate exchange for virtual hosts and servers. It is to SSL what HTTP 1.1 was for basic HTTP traffic: an excellent enabler.
It is well-supported today in a variety of modern browser and operating system implementations but SNI is not universal.
SNI helps effectively reduce the price and implementation complexity of SSL because you no longer need dedicated virtual IPs (VIPs) per host name that is being served by a web server, load balancer, or other infrastructure component - these components can instead implement their SSL by performing a certificate lookup and then presenting that custom cert as part of the TLS handshake for that web site.
You can read up on the support notes of Wikipedia for SNI but the basics go like this. Do your own testing and research before you commit to your technical SSL implementation choice, of course.
For 4th & Mayor, I have decided that SNI SSL is perfect: my application targets Windows Phone, which supports SNI SSL; I also expose some management functionality through the web site, and for this, I'm expecting modern browsers only. The value is good for my business needs.
Not supported per Wikipedia on 6/18/13:
In the Configure tab for the Web Site, you can configure bindings for the paid SSL options. The free shared certificate for yoursitename.azurewebsites.net just works without a need for any configuration, fyi.
When creating a binding, you create a new entry and pick the underlying SSL technology option. I'm using SNI SSL:
Finally you select the certificate, associated domain name, etc.
This change should be fairly quick, just hit the Save button in the toolbar.
You should now be live on the hosting side.
Finally you need to update your DNS entries using CNAMEs to redirect your www (or other custom domain) traffic to the site - in my example this is
Before updating DNS, I tested by updates my machine's local
/etc/hosts file (or
%SystemRoot%\System32\Drivers\Etc\LMHOSTS on Windows) to redirect
www.4thandmayor.com to the new
This allowed me to use my browser to navigate to the HTTPS endpoint and make sure everything looked OK, certificate was being resolved properly, the cert chain was present, etc.
Once I was happy, I updated my DNS CNAME entry, initially with a short 60 second TTL setting - and since then I have now popped that up to a multiple-hour TTL since things are working great.
In the past I hosted this in the Amazon cloud, but during the month of April 2013, I worked to start moving it over to Windows Azure and have been very happy with the results. Full disclosure, I work on the team!
Windows Azure Web Sites is a really powerful hosting environment that lets me pay for reserved computing power with an easy deployment model (just Git pushes of Node.js JS source files). It is a lot easier than standing up my own EC2 or Azure VM instances, configuring software,
yum installs, etc.
My earlier workaround is detailed here: http://www.jeff.wilcox.name/2013/04/4thandmayor-azure-websites/
Hope this all helps. Happy secure web hosting!
Jeff Wilcox is a Principal Software Engineer at Microsoft in the Open Source Programs Office, helping Microsoft scale to 15,000+ engineers using, contributing to and releasing open source.