Recently I’ve had cause to set-up a SSL secured site on Windows Azure. Never having worked with SSL before I thought I’d quickly blog about a few of the gotcha’s I experienced along the way.
You are here
Before I started, naturally, and as usual, I hit Google to find all Azure SSL wisdom. I found a great post by SondreB – Windows Azure: Secure Site with SSL certificate. This is a great guide and I urge you to follow it, however, as an SSL amateur I found it had a couple of gaps. Which I’ll expand on below.
.crt != .pfx
First off Azure expects to work with SSL certificates that are saved in the .pfx format. However, when you request a SSL from an authority like Verisign, it comes in .crt format. These are both valid X.509 formats but you need to convert the cert you receive from Verisign to a format readily understood by Azure.
Gotcha #1 – you have to create the Certificate Request from the same PC that you plan to generate the .pfx from. So if you were working with on-prem IIS you’d generate the Certificate Request from the IIS server that you’re planning to host the app on. However, when working with Azure do all SSL work on your dev PC that has both Visual Studio and IIS7 installed.
Creating a Certificate Request
Open IIS7 locally and double-click Server Certificates. In the left hand side you should have the option to Create Certificate Request. Complete the wizard as SondreB advises and save the .txt file to your local PC. If you open the .txt file you’ll see it contains a Certificate Request cryptographic key.
Creating a SSL Certificate
Verisign have a great free service to allow you to create multiple temporary SSL certificate which lasts for 30 days. Which is great, as if like me, you’ll probably create one or two before you get the process down. You can purchase a real one once you are happy you’ve got everything worked out.
Complete the contact form, then you’ll be invited to input your Certificate Request. Ensure you select Microsoft and IIS7 in the Platform details section, then paste in your Certificate Request key. Complete the process and you’ll be emailed your certificate shortly afterwards.
Importing your SSL Certificate
The email from Verisign will contain another cryptographic key. Copy it out of the email and paste it into a new file, ensuring you give it a .crt extension – ie myVerisignCert.crt.
Gotcha #2 – SondreB states in the blog you can right-click the .crt and import it into your PC. This didn’t work for me. Luckily, however, there’s a free tool that did. Download the DigiCertUtil.exe and run it. You should now be able to import the .crt into your certificate store on your local PC (nb – ensure you run as admin or you won’t be able to import the cert).
Export the .pfx
With your .crt successfully imported, you can export it in .pfx format again as SondreB outlines. You can then simply upload the .pfx to the appropriate host in Azure. The .crt should now also be available to your Azure cloud project within Visual Studio and again can be imported, as outlined by SondreB.
You looking at my endpoints?
The final gotcha to be aware of, is that you can’t VIP Swap a project that has more endpoints than the one you’re attempting to replace. If the solution you’re running only has the standard http endpoint you’ll have to delete the running live instance to swap in the package with the additional 443 endpoint.
This could be a major pain, as you’ll be assigned a new IP address etc, and in my experiments it’ll take around 30 minutes for your site to appear on line again, as the CName record seems to take a while to catch up to the new IP address.
So if you know you’re working on a site that will be SSL enabled it would be a good idea to create the 443 endpoint from the start, not at the end of the project, as I discovered.
Otherwise that should be it, SSL happiness awaits
Pingback: Windows Azure Community News Roundup (Edition #9) - Windows Azure - Site Home - MSDN Blogs
Pingback: Windows Azure Community News Roundup (Edition #9) - Windows Azure Blog
But DON’T purchase from Verisign. Their cheapest price for an ordinary SSL cert is like $400!!!!! Are you kidding me??!!! Go to GoDaddy and pay $70 for the same certificate. Even better: Search Google for “SSL Certificate” and see if GoDaddy pops up with a special offer. Note that if you find an SSL certificate on a special deal with GoDaddy that you can’t use any promo codes you may have to reduce the price further … just purchase the certificate separately from any other order you place where you want to use a GoDaddy promo code. If you try to use a promo code, the certificate price in the shopping cart will jump back to full price; therefore, checkout with the certificate in the cart all by itself. You might be able to get the same $400 Verisign certificate for a mere $13 from GoDaddy using this method! Luke Latham, CEO, SellRex Corporation, http://www.sellrex.com/
Pingback: De Olho no Azure – 24/03/2012 « Pensando Azure
Great article, but a ran into one major Gotcha that you have mentioned: Its’s about the short sentence: “Complete the process and you’ll be emailed your certificate shortly afterwards.” My ISP, or rather the SSL supplier, asks me to choose an e-mailadres where to send the certificate. I do not have an email …@cloudapp.net or …@mylsapp.cloudapp.net. How did you get past this issue?
You should be create a CName record for your site, rather than using the cloudapp.net address. So create a cname record, ie http://www.edgar.com pointing to edgar.clouldapp.net. You should get the SSL cert for edgar.com, and get it emailed appropriately.
Thanks for your reply!
Should I then apply the PFX file to edgar.cloudapp.net or to edgar.com?