Brent's Software and Web Development Blog

Many cool new services are being rolled out in the Windows Azure platform, but there is one feature that has been in place since Azure went live that is still very valuable to me: the ability to quickly roll-out locally developed functionality to the web using Web or Worker roles. This “platform” offers a layer on top of a traditional cloud hosted virtual machine, and gives developers the ability to 1) provision a cloud hosted machine and 2) deploy code with the ease of a simple F5 from within Visual Studio. Okay, maybe not quite that simple, but close…

You can use this platform for all sorts of cool things; publishing complex web applications, provisioning utility services (think traditional Windows services with less configuration), publishing public facing web services using WCF or Web API, to name a few. I was recently working on a Windows 8 application, and needed to supply it with data using a web service. An Azure role seemed appropriate, so I got to work building my web service and publishing it to Azure. In no time I had deployed my service code to Azure, exposed an endpoint on port 80, and begun calling my new service from the application. A re-creation is shown below, testing the http service with IE directly:

After thinking about it a little more, I decided that I should secure the service calls a bit more and use HTTPS. Ok, no problem, change my configured endpoint to use port 443, associate a local certificate directly in Visual Studio, deploy, and there it is! My service is now accessible only using HTTPS calls. Another thing the platform makes easy…

But something is off…see the “Problem with the website’s security certificate”? When I test using a simple HTTPS GET with the browser, IE is having a problem validating the certificate I generated locally for a couple of reasons: 1) The certificate wasn’t issues by a valid CA, and 2) the web address Azure has issued my service doesn’t match the information (CN name) presented by the certificate. Now, this isn’t a problem if I am simply testing the functionality of my web service. However, if I am trying publish a production level service, one that can be consumed by applications reliably, I will want to fix this issue. Specifically in the case I mentioned before, I quickly found out Windows 8 apps have a serious problem consuming web services that present certificate validation issues.

So, how do we fix our certificate validation problems? We need a valid certificate from a trusted certificate authority, and we need to associate it to our cloud service.

There is some guidance on doing this by Microsoft here. Unfortunately I found that when I tried to do it, it wasn’t trivial the first time through. The rest of this post attempts accurately describe what I had to do to get it working.

If you have a valid certificate authority you can use to issue the certificate, and you know that your service consumers will trust this CA, you can use a certificate issued by this authority. I don’t have a valid CA I can call on, so I’ll need to purchase a certificate from a company that Microsoft trusts. You’ll have to navigate the steps of creating a certificate request locally (I used IIS7), validating the domain for the certificate, and downloading the certificate itself once its been generated.

There is one catch here: you won’t make it past the “domain validation” step of the certificate provisioning process without a domain that you own or manage. This is a tough one for an Azure site / service because there is no way you’ll be able to request a cert for the “cloudapp.net” domain your service is currently running under. So, how to get past this? Use a domain you own, that you can reserve for use by your Azure service. One thing to be aware of is that you will be redirecting all traffic to your domain over to your Azure service, so make sure you are not already using it for something else (I registered a new domain for this post). Assuming you don’t already have a domain readily available, here is the list of steps I followed:

Register the new domain you will use for your Azure site or service. Test to make sure it is registered properly before going forward.
Purchase an SSL certificate from a trusted CA. I’ve used GoDaddy, Network Solutions, a few others. Once you have purchased the certificate, you will normally see something equivalent to a “credit” on your account for an SSL cert.
Create a Certificate Signing Request (CSR) locally. I used IIS 7 for this, your process may vary. Important: the common name value in the request must match the domain you will use for redirection.
Upload your CSR and complete your certificate request. Once your certificate has been issued, you should be able to download the certificate locally (we will add it to the Azure cloud service soon!).
Add a CNAME record to your domain’s DNS configuration to point the desired subdomain to your Azure service. In this case, I added a CNAME record for the “www” subdomain with the value “brentblogdemo.cloudapp.net” which is the location of my Azure service. Depending on the registrar, the way to edit DNS varies slightly but most companies provide DNS services with your registration. If not, companies like ZoneEdit.com can help. Once complete (depending on who is taking care of your DNS, it can take up to 24 hours for the setting to take effect), traffic will be routed over to my Azure service. So using my alternate domain, I am now hitting my Azure service, but I am still seeing the certificate validation error, we will fix that now:
Upload the valid certificate to your Azure cloud service in the Windows Azure management portal. The file must have a .pfx extension, which is not necessarily what your CA will provide. To generate the .pfx file, first import the certificate in the form you were provided, then export again using the Certificate snap-in in the local Management Console.
Associate the uploaded certificate in the “Configuration” tab of your service. You should see the thumbprint of the self signed certificate you have been using beside the “Certificates” label. Copy the thumbprint of the newly uploaded cert (it will be visible in the Portal once uploaded), and replace the existing value.
Test again and you should have a valid and secured Azure service.