Certificates and DNN as an Azure Web App Part 3

So, the DNN site has now been successfully tested with HTTPS and everything seems to work OK. However, just for a laugh, the great Gods at Google have decided that preference in search results will be given to sites that only use HTTPS. The marketing department, in between their long lunches, naturally declare this is essential – or the world may end – so that means that you need to redirect all incoming HTTP requests to HTTPS and issue a 301 permanent redirect so The Google will smile upon you and yours.

Incidentally, I thought I had made up the part about Google preferring secured sites in search results but, some 3 weeks after the site was converted to HTTPS, referral traffic to the site via Google had increased by about 25%. That might just be coincidence of course but you never know.

If you were using a conventional server then you would do a redirect at server (IIS Level) or some trickery in the web.config file but this is the brave new world of Azure and the job is, for once, easier than you might imagine and all that needed to be done was to deploy an Azure Extension – basically add ins to perform a specific function - to the Web App and that was that.

The Azure Extension used was “Redirect HTTP to HTTPS” by Greg J Hogan and it was even free and required no configuration (which was as a bonus as it was getting late). You can add extensions by selecting Extensions from the Development Tools section of your Azure Web App.

Notes

HTTP Strict Transport Security (HSTSC)

This is a very good thing as it can help reduce privacy leaks and downgrade attacks and there were even free Azure extensions to implement it so a bit of brief testing was undertaken to see if DNN on Azure would still work when so configured. Basically it did but there were a couple of things that may well require you to make some changes to your website before a production deployment.

At a medium setting for HSTS, the use of analytics tracking JavaScript and the Google Maps API were blocked by the browser. That’s not the end of the world as changing some directives would sort that but you should remember to test everything before switching to HSTS.

Another, fortunately easy to resolve, anomaly surfaced when the Persona Bar refused resolutely to load under HSTS – the Web Console in Firefox indicated that loading the Persona bar had been blocked by the security settings of the website- although it worked just fine under HTTPS. In my case, this was simply a CSS problem. The skin used by the DNN website running inside the Azure web app was just fine. This was verified by loading it onto a different test server. The test server used a base install while the production server was a migration to Azure so my attention was drawn to the base stylesheet used by DNN itself which can be found under Settings – Custom CSS. Sure enough, it had been changed at some time in the past while the installation on the test server had not. This style sheet contained nothing other than classes so hitting the Restore Default button and clearing the cache on the DNN portal got the Persona Bar working again.

That’s basically it. As always, make sure that you have worked out an extensive test plan – just because a website loads doesn’t mean that it will work - before undertaking the move to HTTPS and test as you go along but it was the Azure web app extension model made this part of the job a straightforward one.