Wednesday, 19 December 2012

Self-signed SSL certificates and Windows Azure

I am new into the world of Azure. What I like is the supposed ease of deployment directly from Visual Studio and also the fact that we got a very generous free trial for 2 years!
Anyway, making things easier has its downsides. It has to invent new ways of doing things that I already know how to do the long-winded but well-known old-fashioned way. One of these is handling TLS/SSL certificates for secure web-sites - something I personally think should be enabled on all sites in this day and age.

Anyway, I had a site deployed onto Azure which was working fine on http but not enabled on https. Once I have https enabled, I will modify the deployment to rewrite all non-ssl requests to redirect to the ssl one (something I'm sure will warrant a future article).

Anyways, I am personally testing this system and the urls will change at some point soon so I didn't want to buy any proper ssl certs just yet. Making self-signed certs is easy enough but when I tried, I deployed and got an error attempting to access the SSL endpoint even though it worked locally, the reason being I hadn't created the self-signed cert properly and I think locally, the system detects this and uses the built-in Azure testing certificate instead.

I had used a guide from a blog post which was obviously not too accurate, so anyway, I eventually found this blog post: www.theworkflowelement.com which correctly stated the way to create these certs, in this case directly into the local certificate store. So here are the steps from start to finish to self-sign and deploy an SSL binding to your web site into Azure.

Following the blog post (from the Start Menu: Visual Studio 2012->Tools->Command Prompt), first create a certificate using:

makecert -a sha1 -n "CN=lkhjasd908d0iqdaljds.cloudapp.net" -pe -r -sky exchange -ss My -sr LocalMachine  

(Note that the My and the LocalMachine relate to the local certificate stores and should stay as-is. Make the common name equal to whatever your site url is in the staging area of the azure portal)

 

Run up mmc.exe from the start menu and choose File-Add/Remove Snap In. Double-click "Certificates" in the left hand list and choose Computer Account (which is where you just told makecert to put the certificate it created). Choose next and then leave Local computer selected and press finish. Press OK to close the Add/Remove dialog and browse to Certificates->Personal->Certificates

Find the certificate you just added which will have IssuedTo set to the common name you set earlier (xxxxxxxxx.cloudapp.net) and right-click it choosing All Tasks-> Export... Click next and choose that you DO want to export the private key and click next. Use the .PFX selection and include all certificates in path if possible then click next. Enter a password for the private key - best to make it strong. Repeat the password and click next and then choose a filename to export to. Click next and finish at the summary screen - hopefully you will get a success message.

Go back into the azure portal and choose the correct instance for the common name you created the key for (don't get site/key confusion!) and then choose the certificates 'tab':

 
My screen shot shows the certificate I have already uploaded (suitably obscured!) whereas yours won't show anything yet. Choose Upload at the bottom of the screen and browse to the .pfx file you just created and type in the password you set for the private key. This should upload and do nothing else particularly interesting.

Next you have to setup your cloud project. I assume you already have a cloud project that has already been deployed and tested over http. I ask because I had problems with https and then realised I had broken my site locally!

Find the relevant role for your project (e.g. your web role) and double click to open the configuration.

 

Start in the certificates tab and click Add Certificate. You can use any name here to refer to it. Leave the dropdowns at LocalMachine and My (where you put the original certificate) and then click the ellipses button next to the thumbprint text box.  This opens a funny looking dialog which lists the certificates you have in this location and allows you to choose one and press OK:

 

This should have filled in the thumbprint field for you. It is worth quickly checking this against the Azure portal certificates tab for the site you are working on and make sure the two thumbprints match. If not, you might have mucked up the certificate creation or more likely have got certificate confusion and either uploaded the wrong one to Azure or selected the wrong one locally.

Then you can click on the endpoints tab and add a second endpoint which is basically the same as the first but with https and port 443 selected. You should also select your newly added certificate for this ssl binding.

Click on the configuration tab and tick the box for "Launch browser for" and https. Build the solution in release mode (since I hope this is what you will be deploying) right-click your cloud project and "Set as Startup Project" if not already done. Press Debug (F5 for me) and ensure that both pages open in your browser, an http one and an https one. You should see a browser warning since your self-signed certificate both doesn't match the local URL and is not part of a trusted chain to a root authority (no worries - this is for test only).

If that is OK, deploy your web site to Azure in the normal way and after the few minutes it takes to upload, open up the URL in your browser and change the http to https. You should see a browser warning that the certificate is not part of a trusted chain but this time, the certificate URL SHOULD match the actual URL. If it doesn't work, you might have produced an incorrect type of certificate (it needs to be "exchange") and if you get a warning about the URL, you might have typed this incorrectly in the original makecert call. Other than that, it should all work.

Once you are all done and into production, you should get proper certificates for the sites either from a public root authority or otherwise if it is a private network, you should use your corporate certificates which will/should be trusted on all of your internal machines. 

 


Post a Comment