SSL sites in Azure: get an inexpensive certificate, upload it to Azure and make it work

Why https?

SSL certificates have become very inexpensive.

There are at least three reasons why you may what to serve a secure (httpS) version of your site (or even serve only the httpS version of your site):

  1. with httpS, it is almost impossible that a “man in the middle” impersonates your website
  2. search engines reward sites that have an httpS version
  3. conversion rates are higher because clients take their money’s safety very seriously (as you)

In order to serve a secure version of your site, you need an SSL certificate granted by a Certificate Authority, or by a company that is trusted by a Certificate Authority.

Here are some suggestions to implement SSL in Azure, using a certificate issued by one of the most inexpensive Certificate providers (also the most commonly used as of March 2015, their site says): Comodo.

Comodo has lots of resellers. To use it with Azure, you should make sure that you get the certificate from a reseller that provides:

  1. the Certificate for your website (a file that will be called something very similar to www_yoursite_com.crt)
  2. the private key with which that certificate was created (a file that will have a name very similar to www_yourwebsite_com.key)
  3. the “chain” of certificates that will allow the browser to recognize that Comodo is a trusted Authority and it can guarantee the name of your site (this will will have a name very similar to www_yourwebsite_com.pem)

The KEY file is essential. Without the key file, you will not be able to create the .pfx file that Azure needs. If you have no key file, ask your reseller to re-issue the certificate (they might need your .csr request, depending on your provider) and give you also the .key file.

What is in the certificates files?
the CRT file has this format:

—–BEGIN CERTIFICATE—–

(a lot of digits and letters)

—–END CERTIFICATE—–

the KEY file has this format:

—–BEGIN RSA PRIVATE KEY—–

(a lot of digits and letters)

—–END RSA PRIVATE KEY—–

the PEM file has this format:

—–BEGIN CERTIFICATE—–
(a lot of digits and letters)
—–END CERTIFICATE—–

—–BEGIN CERTIFICATE—–
(a lot of digits and letters)
—–END CERTIFICATE—–

(i.e.: the PEM contains multiple certificates)

An example of this?

If you buy a certificate via dnsimple, they will get from Comodo all of the above mentioned files, in this simple format:

obtain certificate and keys from dnsimple

obtain certificate and keys from dnsimple

Are these SSL certificates ready for my Azure website?

Hold your horses. Two things must happen before you can upload.

  1. You have to have at least a “Basic” Azure website plan (“shared” will not do)
  2. You have to create a .pfx file, the Microsoft-peculiar format for SSL files (the main difference with .crt files is that it contains also the private key; plus, it is password-protected).

To satisfy condition (1), one thing is sufficient: pay. “Basic” websites are more expensive than “shared” websites and, of course, of “free” websites. If you want to upgrade from “Shared” to “Basic”, choose your site in the Azure portal and look for the “scale” button. The upgrade takes 30 seconds at worst.

Condition number (2) takes a bit more time. You have two options:

The easy way to convert a .cer file to a .pfx

Use an online tool. This is the fastest way. However, you have to trust the online tool, because you’re basically giving them the “id” of your site. This is a very cozy tool:

https://www.thesslstore.com/ssltools/ssl-converter.php

an online pfx converter

an online pfx converter

Another tool is this:

https://www.sslshopper.com/ssl-converter.html

Are these tools secure? WHO KNOWS. The second tool specifically tells you you’re not doing a very secure thing although these tools do use https [ 🙂 ]

The secure way to convert a .cer file to a .pfx

If you do not like to use a web tool to manage your SSL certificates (I cannot blame you), you need openSSL and be ready to do some command line writing.

OpenSSL for windows can be downloaded here, for example:

https://slproweb.com/products/Win32OpenSSL.html

Once you install openSSL, you open the command line tool as an admin, launch openssl and type this line

OpenSSL> pkcs12 -in www_yoursite_com.cer -in www_yoursite_com.pem -out www_yoursite_com.pfx -export -inkey www_yoursite_com.key -password pass:the_password_you_will_use_in_Azure

openssl to create pfx

openssl to create pfx

Pay attention: the .pem file is the one that includes your site’s certificate. If you use only the intermediate chain certificate files, you will get this error:

No certificate matches private key

Now let us upload the SSL certificate to Azure, shall we?

Now the easy part. This is done in two steps:

  1. upload your certificate to Azure
  2. tell Azure it should use the certificate with your site

To do (1), go to the “Configure” part of the “classic” Azure portal or to the “personalized domains and SSL” menu item of the new portal, then upload your .pfx

To do (2),  go to the SSL binding section of the same page where you uploaded the .pfx file and choose the name of the site you are linking the SSL certificate to.

Both steps are well shown in this MSDN article:

http://azure.microsoft.com/it-it/documentation/articles/web-sites-configure-ssl-certificate/

However, please note that the MSDN note underestimates the importance of linking the certificate to the IP of your Azure website rather than using the “SNI” attribution. 

The note says that only “older browsers” will have some difficulties accepting an SNI certificate as opposed to an IP-bound one. 

You will have issues not only with older browsers: if your pages are called by an http client (as is the case with most eCommerce services), it is very likely that that http client will not be able to interpret the SNI certificate (if the client is Java, they often get this error: javax.net.ssl.SSLHandshakeException)

This is why there are numerous cases in which SNI installation is not enough and you will have to:

1. Choose the IP based installation of your SSL certificate 

2. Check if Azure changed the static IP of your site after such installation 

3. Add/edit an A record in your DNS configuration to point to the new IP address of your Azure website

Good luck with SSL and Azure!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s