This tip has been a very long time coming. Back in ToW 479, the subject of running WordPress on Azure was mooted, and it prompted an internal-to-MS conversation about the guidelines for publishing stuff externally.
The extended back story is that there were hundreds of employee blogs which had been published under the technet.microsoft.com and msdn.microsoft.com sites, both of which URLs could trace their birth back to the 1990s, and a project was underway to clean them up and rationalize somewhat.
Initially, guidance to MS bloggers was (basically) “unless you’re an official blog, you have <nn months> to move your stuff elsewhere before it gets deleted.” Certainly, there was to be no new content after the cut-off date.
That guidance relented somewhat and content from relatively active blogs was migrated to the Microsoft Docs archive though taking a trip through the final posts from the ToW host blog, The Electric Wand, shows that lots of graphical content was not carried across – more of a lift & dump than a lift & shift.
Anyway, the solution for Tip o’ the Week was to move to an external website – www.tipoweek.com – which is hosted in Azure and, like about a third of all websites, running under the content management system, WordPress.
Setting up a WordPress site is pretty straightforward, really – though you do have a variety of options on what kind of site you want to build. If you need a complex site with lots of control over it, then you might want to run it in a Virtual Machine or a container. For most of us, though, a simple App Service will suffice. From the home page of your Azure subscription, just Create a resource and search services and marketplace for WordPress, then select the WordPress App Service from the multitude of options you might get.
For more tips on how best to get up and running with WP in Azure, see here.
One retiring Microsoftie (not the shy type, but leaving the company, today in fact), emailed last week to point out that the tipoweek.com website was being flagged in Edge as Not secure. Oh Noes!
This has, in fact, been a niggling issue for a while, since Chrome (and Edge, given its diet of Chromium) instituted a policy of flagging any website that doesn’t use the secure HTTPS protocol & SSL by default.
Secure Sockets Layer, if you’re not overly familiar with it, relies on a way of encrypting data travelling between two points, using a previously-generated pair of mathematically-linked digital keys. If you have one key, you can use it to encrypt data which can only be decrypted by the other key in the pair (ie you can’t even use the same key that encrypted the data to decrypt it again). Typically, one of these keys is publicly accessible and the other is kept private.
One way of sharing a public key is to embed it in a site’s SSL certificate, which is in turn validated by a mutually-trusted third party (called a certificate authority). If you visit the website for an institution like a shop or a bank, then your browser will download the site’s certificate, validate that it’s still current and trusted, then use that public key to encrypt data sent to the site. Since that data can only be decrypted using the corresponding private key, we can validate that the site is not being impersonated.
The whole public/private key encryption process has something of a computational overhead associated with it, but once we have established a secure connection, we could use a faster encryption technique for data sharing by using a single key that can both encrypt and decrypt the same data.
In other words, if I go to a website that presents me a certificate specifically issued for that URL’s domain, I can be sure that the site handing out the cert is who they purport to be. This could be validated by me generating a random set of numbers, encrypting it with the public key and sending that to the site; it would decrypt the gobbledygook with the private key that only it has, and we now both have the same set of data that has been securely shared between us. That would form the symmetric key that we can use for the rest of the connection.
For more detail on these kinds of topics, check out the Cryptography 101 podcast on Hanselminutes.
In Edge, if you want to look at a secure site’s certificate, click on the padlock icon (or the handbag icon as some people once saw it – that meant it was safe to shop) – and click the “Connection is secure” banner, then click the little certificate icon in the upper right.
The trouble is, if you’re hosting a hobby or a community web site, paying for an SSL certificate might seem a bit of overkill; web hosting companies will try to bundle them into domain protection and other security features which might be no big deal for a commercial enterprise but a little stiff for a parish newsletter.
Fortunately, there are alternatives, though they do need a bit of spade work to get up and running. Hanselman (yes, him again) discussed using an extension and an organisation called Let’s Encrypt, whose goal it is to make the web 100% secure. They have issued over 225 million SSL certs, and will generate 3-month-validity certificates free of charge, as an alternative to paying anything from $60-200 a year to a commercial issuer. With a bit of practice, it doesn’t take long to create and manage the certs and if you only need to do it 4 times a year, then it could be time well spent and money well saved.
An alternative method was written up by fellow Microsoftie Andreas Pohl, using a slightly more manual method to create the certificate then import into Azure; if you’re looking for an excuse to get Windows Subsystem for Linux up and running, then this could be it.
Once you have the certificate exported to a file, it’s a matter of a few clicks to import it into the Azure App Service that is running WordPress, set up the bindings appropriately, and you can then flick the switch to make the site only service up content over HTTPS.