Introduction

There are other longer guides to this but for many of us, we already know the basics and don't need screen shots just a simple list of items to enable SSL on Azure. It is pretty easy. I will mention commercial SSL certificates first and then self-signed certificates later - as you might imagine, there are lots of similarities.

Commercial Certificates


  1. Publish your site to Azure production so you know the IP address of the site. If you are using the Azure URL then write this down. If not, setup your own DNS to point your custom domain name to the relevant IP address of the Azure site. Note that this will cause the site to be online but you can either publish it with no endpoints or have some way of disabling access until SSL is setup (if required).
  2. Create an SSL certificate request in IIS7 by going into the Server Certificates and selecting Create Certificate Request. Fill in the details, the Common Name is the name of the URL you are securing like www.example.com. Although these fields are not all required by standard, IIS will insist you fill them all in.
  3. On the next tab, choose Microsoft RSA and a bit length of 2048. On the next tab, specify a file name for the request to be written to such as c:\req.txt
  4. Go to your preferred SSL certificate site (I like gogetssl.com) and perform the certificate request by pasting in the contents of the text file you just wrote.
  5. Once you get the certificate back, install it in IIS by selecting Complete Certificate Request in the same place. The friendly name is useful when adding it to your Azure project.
  6. You now need to add the fingerprint to your web application/service (note it does NOT add the certificate to the project, just its fingerprint). Do this by double-clicking the relevant role in the Azure project to open the config and go into Certificates. Choose a friendly name, select "My" as the store name and click the ... next to the thumbprint field. You then need to choose the correct certificate from the list (this is where the cert friendly name is helpful).
  7. Go into Endpoints and add the relevant endpoint for SSL (port 443 by default) and then select the certificate you just added. Optionally remove the non-SSL endpoint.
  8. Now you need to export the certificate from IIS with a password so it can be uploaded to Azure. In IIS, select the certificate you want to export and select Export on the right-hand side. Give it a file name (pfx extension by default) then type in a password to secure the certificate. You will tell Azure this password but anyone else who might be able to steal it cannot use it without this password.
  9. Once exported, go into Azure, select the web app, go to the Certificates tab and select Upload. Browse to the certificate and type in the password you already entered. Once this is uploaded, it will display the thumbprint in the Azure window - this should be the same as the one you can see in your project configuration. What Azure will do automatically now (once you re-publish your app with the SSL config included) is grab the certificate you uploaded by matching its thumbprint to that in the application config. The rest should work fine. Note that the SSL cert is tied to the URL not the IP address so if you want to access SSL by multiple URLs, you will need to either forward all of them to the same URL or buy multiple SSL certificates and add all of them to the project as above.

Self-signed Certificates

When you are first testing applications, buying a commercial certificate is not always an option. If, however, you know what the ultimate URL will be and it isn't currently used on another site, it is much easier to buy a commercial certificate rather than encountering the errors you get through lack of trust.
  1. Note that if you are performing communication using SSL between multiple applications on Azure, I could not find a way to enable the calling application to trust the self-signed certificate of the application being called. In this case, you might want to consider a commercial certificate for the application/service being called (about $5 for one year using gogetssl)
  2. You can easily generate a self-signed certificate, I won't go into details here but there is a previous blog post: http://lukieb.blogspot.co.uk/2012/12/etc
  3. Once this has been generated, you go through the same process as per the commercial certificates, that is, link the certificate to the Azure project in the Role configuration and then upload it to the Azure portal.
  4. Note that as expected, when you visit these sites, although the encryption will be secure, your browser (or other application) will warn you that the certificate is not trusted. In some instances this is important because anyone can self-sign a certificate and pretend to be your web site so a man-in-the-middle attack is possible when using self-signed certificates. If you want to nail this down some more, you can set the issuer of your self-signed certificate to be trusted on your local PC but this has potential implications for any viruses that can use your local machine to generate SSL certificates and then spoof web sites with them. Note you can always delete the trusted certificate after you have tested, otherwise, as mentioned, just buy cheap commercial ones and avoid the issue altogether.