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!

Using Google and LinkedIn Accounts for Your .net MVC 5 Site’s Authentication: Tips and Tricks and the error externalLoginCallback?error=access_denied

Some months ago, Rick Anderson and Erik Reitan wrote a very good article in the asp.net website (http://www.asp.net/mvc/tutorials/mvc-5/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on)  to show how the ASP.NET Identity authentication / authorization framework can leverage external authentication providers as Google, Facebook, Twitter and LinkedIn.

These providers do frequent changes to their interfaces. I am writing this post to underline a couple of tricky errors that the Google / LinkedIn authentications can present to you even if you seemingly do everything by the books.

Authentication with Google: tricks

Google can give you: “externalLoginCallback?error=access_denied” if you don’t allow your application to use certain – not so intuituive – APIs. In particular, the API that must be checked so that Google gives the green light for authentication is the Google+ API, which is not pre-authorized.

This is documented in MSDN: http://blogs.msdn.com/b/webdev/archive/2014/07/02/changes-to-google-oauth-2-0-and-updates-in-google-middleware-for-3-0-0-rc-release.aspx, however, i thought it was a good idea to replicate the same concept on this site in order to make it easier to find it with a search on the redirect URI error.

Another error one can get for the Google authentication is that the Google “project” has to have a PRODUCT_NAME (however, this is easy to spot because it is Google’s page itself to tell you where the problem lies).

All in all, these are the steps to enable the Google + authentication in MVC 5 (highly suggested to use Visual Studio 2013 Release 2 or superior)

Steps in Visual Studio

Create a new MVC project with “Individual user” authentication

From Nuget, download the Microsoft.Owin.Security.Google package

Google authentication package in NuGet

Google authentication package in NuGet

Enable https for your site (project – properties – set SSL enabled to true)

Copy the location of the SSL site (https://localhost:port_number/, for instance: https://localhost:44302/)

Steps in Google Developer Console

Go to¬†https://console.developers.google.com/project. Click on “Create Project”.

Click on the project name, click on APIs in the left menu and select “Google+ API”. Set it to ON (default is OFF)

Screenshot of the Google+ API we have to check to authenticate users in an MVC project

The Google+ API to enable if you want external authentication to work

Click on “Credentials” – oAuth.

Set the “Authorized Javascript origins” to the localhost SSL root (https://localhost:your_port_number). Set the “authorized redirect URLs” to localhost SSL root + /signin-google: for instance,¬†https://localhost:43202/signin-google. No slash at the end of the URL!

Once you do this step, you have a ClientID and a Secret. You will need those for the Visual Studio application.

Configuring the ClientID in Google

Configuring the ClientID in Google

In the Consent screen, choose a contact email and give the PRODUCT a name!

Google Authentication: Consent screen

Google Authentication: Consent screen

Back to Visual Studio

In the folder App_Start, there is a file Startup.Auth.cs. 

Un-comment the lines releted to the Google authentication and fill the¬†ClientId and ClientSecret fields with those given out by Google (these below are examples, they don’t work.

app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()
{
ClientId = “xyzsdusidui2uo2380r787285780457284057804.apps.googleusercontent.com”,
ClientSecret = “Uhjhkjhk189r_iGAsMZdHz”
});

Now you should be good to use Google to register and authenticate your users.

 

Authentication with LinkedIn: tricks

Rick and Erik mention this good tutorial for authentication with Yahoo and LinkedIn (+ a set of other OAuth 2.0 providers)

http://www.beabigrockstar.com/blog/introducing-the-yahoo-linkedin-oauth-security-providers-for-owin/

The LinkedIn tutorial is a bit simplified: it does not take into consideration the Redirection URI for localhost.

How to work with Localhost?

As with Google, you need to write down the httpS address of your localhost, for instance: https://localhost:44302/

Beware: for the authentication to work, the OAuth 2.0 redirection URLs must be set to https://localhost:44302/signin-linkedin (or your port of course). 

You have to set this address here:

Linkedin-no-signin-error

In case you don’t append /signin-linkedin, you’ll end up with an “invalid redirect_uri” error:

invalid-redirect-uri-linkedin