Once I had my blog ported over to WordPress running as an Azure App Service, I knew I needed to figure out how to secure my site, both because I wouldn’t want to be logging into it, randomized unique password or not, and because I wanted to be a good web citizen and secure all the things.

I saw that my pal Jeramiah had used Let’s Encrypt to secure his site, so I did some Googling, and asked him if he’d used the Azure extension I’d seen mentioned in a few blog posts, and he confirmed he had.

I read a few guides on getting it done, and while I had a few issues along the way, I finally got everything working. In an effort to save people from the starting and stopping and Googling that I had to go through while working through it, I decided to document the entire process from start to finish on a fresh blog.

You’re going to need an Azure Storage Account

Once you’re logged into the Azure portal, look for Storage accounts on the left-hand menu.

As you can see here, I have no storage accounts. Click Create storage account.

You’ll need to fill out and select some options here. I like to name every account or aspect of an App Service based on the overall name of the App Service, so I went with geekfoodblog.

I left Resource Manager as the default, selected general purpose v1, located in East US, and selected Geo-redundant storage (GRS). That may be overkill for my needs, but based on the storage costs for this blog last month and the amount of MSDN credit I have, it’s moot.

I believe Secure transfer required was Disabled by default, and I left it that way. If you have more than one subscription, you can select that here.

I did choose to drop it into the existing geekfoodblog Resource Group, since I had already deployed WordPress as an App Service before setting up Let’s Encrypt.

I did not choose to configure  virtual networks, nor did I pin this account to my dashboard, and with that, I clicked Create.

Click on Access keys and copy your primary Connection String into a secure note somewhere for later use.

Now you need a Service Account (or App Registration)

You may see this referred to elsewhere as a Service Principal. Azure calls it an App Registration. So click on Azure Active Directory, then App registrations, and then New application registration.

You can see how I named mine. You’ll make use of auto-complete later, so using a few memorable letters as a prefix helps.

Also, as noted below, the Sign-on URL doesn’t matter in the sense that it doesn’t have to be something you own or are working with, but it does has to be something that is recognized as a legitimate URL.

Now you’ll need to create a client secret or key.  Click Settings, then Keys.

Give your key a description – I used letsencrypt, and I selected Never expires as the duration. That’s probably terrible, but it’s a huge key, so sue me.

When you click Save, you will be warned to copy the key value, as you won’t be able to retrieve it later. Stick that in the same secure note with your Storage Account connection string from above.

You’ll also want to copy and paste the Client ID of your Service Account / App Registration.

As you can see below, and as you’ll notice in the screenshot I saved with the Client ID error I left in, the Client ID is not what you named the App Registration, but rather the Application ID.

You can copy and paste this into your secure note, or you can go grab it later as I did.

Time to assign permissions for your Resource Group to your Service Account

Now you need to make sure your Service Account has permissions to your Resource Group, in particular so it can access the Storage Account you created above.

Click on Resource groups, then on the Resource Group of which your Storage Account is a member.

Click on Access control (IAM), then click Add. For Role, select Contributor.

Start entering the name of your Service Account in the Select field, and select it, then click Save.

Now let’s install the Let’s Encrypt Extension

But first, so you can avoid an issue I noticed when I first set this up, let’s ensure your App Service is configured to always be on.

Click on App Services, then click on your App Service.

Now click on Application Settings, and scroll down to Always On and make sure it is set to On.

Mine was not for some reason, and I noticed an error at one point.

Now click on Extensions, then Add.

Look for Azure Let’s Encrypt by SJKP. Click on it, then OK to accept legal terms, then OK again.

Before proceeding, to help you avoid an issue I’ll show with a screenshot later, go ahead and restart your App Service.

Scroll up to click Overview, then click Restart. Then scroll back to and click Extensions.

Click on Azure Let’s Encrypt, then click Browse.

If you didn’t restart your App Service, you might get this error below.

Now fill out the Let’s Encrypt Authentication Settings

First you’ll enter your Tenant URL, which will be unique to your Azure tenant.

You’ll then add your Azure SubscriptionID – also unique to you.

Next, for ClientID, you’ll enter the Application ID of the Service Account / App Registration you created above. Did you copy and paste that into your secure note? If not, you can find it under Azure Active Directory > App Registrations > Name of your Service Account.

For ClientSecret, enter the Secret / Key from your Service Account / App Registration.

Enter your ResourceGroupName and ServicePlanResourceGroupName – which for me are the same thing.

Be sure to check Update Application Settings, as this is required for the web job that will renew the certificate later.

At this point, assuming you already have your hostnames configured, you should see something similar to what I did below. So click Next.

Select the hostname, enter your email address, and click Request and Install certificate. 

I’d already done this once before, so I was fairly sure it would work, so I didn’t bother checking the UseStaging box.

Now you’ll need to add the SSL binding to your Azure-hosted domain. So go to App Services > Your App Service > Custom Domains.

While you’re here, if you haven’t already done it, switch HTTPS Only to On.

Scroll down and click Add binding next to your domain

Select your custom domain under Hostname. Select the new SSL certificate under Certificate. Click Add Binding.

Time for some Azure WebJobs goodness

If you stopped right now, your site would be secured until the Let’s Encrypt SSL certificate expired in 3 months. Let’s ensure that doesn’t happen by connecting your Let’s Encrypt WebJob to the Azure Storage Account you created above.

Go to App Services > Your App Service > Application Settings.

Scroll down to Connection Strings and create AzureWebJobsDashboard and AzureWebJobsStorage.

Both of these should have a value of, you guessed it, the Connection String you copied from your Azure Storage Account above.

You can confirm your WebJob is running by going to App Services > Your App Service > WebJobs

And once you’ve done all this, fire up your web browser, go to your custom domain, and check your your shiny new Let’s Encrypt SSL certificate.

I’ve blogged on the WordPress platform for years, starting way, way back when I had what I thought of at the time as a shell account at Pair Networks. Since then I’ve installed and run WordPress on other web-hosting accounts, as well as on virtual private servers and, for a short period of time, even on a spare Linux box under the desk in my office. I’ve spent most of my career doing Windows system administration and a goodly bit of it using a Mac as my primary desktop/laptop computer, but I learned just enough Linux to install and keep Apache, PHP, MySQL, and WordPress running. At some point I grew tired of caring and feeding for WordPress itself, so I just imported my blogs into WordPress.com, paid for domain mapping and their “no ads” service, and let the folks at Automattic worry about it.

Will This Be Hard? No.

My first thought about running WordPress on Azure was that I would rather not go back to managing WordPress the old fashioned way involving managing the entire stack from the OS (Linux or Windows) on up. Turns out, as Jeramiah alluded to in his recent post, I don’t have to. There’s certainly more opportunity (and need, especially since I wanted to make my Azure-hosted blog secure) to fiddle with nerd knobs running an Azure App Service, but when it comes to getting WordPress up and running, it took about the same amount of time on Azure as it did at WordPress.com. Want to see how easy it was? Let’s build another one together.

1. Log into the Azure Portal and click on App Services, then click Add.

2. You may be tempted to select one of the WordPress options you see right away. Resist that urge, unless of course you want to run WordPress on Linux or something else.

3. Instead, type WordPress into the search and hit enter. Select just plain WordPress as shown below, then click Create.

4. This next step is important for a few reasons. First, whatever App name you choose here will become your hostname in the domain azurewebsites.net. Second, you will choose whether to create a new resource group or (if you have one), use an existing one. Most importantly, and it may not be obvious at this step (it wasn’t to me), you’re choosing whether you want to run and pay for a separate database service to run MySQL. I went that route at first, but after conferring with Jeramiah, I decided I’d rather save the money/credit and just run MySQL inside the App Service plan. I’ve included the disclaimer Azure shows you below as well.

5. Click Create. I chose to pin my new App Service to my dashboard.

So five steps (maybe a couple more total clicks) to deploy. It takes Azure a minute or two to deploy the new App Service, and once it’s finished, it is fully live, as shown here:

And just a minute or two after filling out the basic info for the WordPress Setup, I had a working install up and running, and even prompting me to update to the latest version.

Back in the Azure Portal, I was presented with a nice data-rich view of my new App Service, along with lots of options, some of which I’ll go into when I detail how I used Let’s Encrypt to secure my new Azure blog.

 

And once I finished taking the screenshots I needed for this post, deleting the App Service was just as easy as creating it. Just click Delete, confirm by typing the App Service name, and click Delete again.

 

So Why Do This?

That’s a fair question. As I mentioned in my previous post, this blog was being neglected over at WordPress.com, but I could have simply fired up MarsEdit and kept posting to it there. But I want to learn more about Microsoft Azure, maybe get outside my comfort zone a little bit, and I figure one way to encourage me to do that is to port this blog over and set myself a challenge to document the experience. So that’s what I’m doing.

If I didn’t have an MSDN subscription with a monthly Azure credit, would I pay to host my blog here full time? I don’t know – maybe, maybe not. But I do, so I am. I figure hosting my blog is the least interesting thing I can do in Azure, but it’s a start.

If you have suggestions for other stuff I can try in Azure, let me know via Twitter, where I’m @mikestanley. 

 

 

 

I love to write. Heck, my email address at work is poet@nospamplz.edu. And yet, somehow, I haven’t written a single blog post for more than a year and a half. The reasons why don’t matter. What does matter is that I’m tired of not writing, and I recently received what was almost certainly an unintentional kick in the behind from my buddy Jeramiah Dooley. Jeramiah published a post entitled “Who Needs Some Lab Gear” on his blog. I was intrigued that Jeramiah, a guy I met when my former employer was considering the vBlock, had started a new job at Microsoft in the Azure engineering group, and was divesting himself of a ton of “home” lab gear and moving his blog over to Azure.

That got me to thinking. I don’t really have a ton of lab gear… in fact, what little I do have, shown here, hasn’t been powered on since we bought our current house 13 months ago, so I should probably get rid of it as well.

What I do have, however, is an MSDN subscription with a healthy monthly Azure credit. I’d played with Azure a bit over the years, spinning up a virtual machine for a few hours until I did the math and realized I couldn’t keep it running all month, but that’s about it. I’ve been using it to test Microsoft Intune for a project at work recently, but when Jeramiah mentioned he “moved everything over to an Azure App Service, so no need for servers at all,” my curiosity was piqued, and I figured I could at least try to do the same thing.

Azure’s Pretty Cool, and Easy to Work With

I’ll detail this in another post, but it turns out, getting something up and running in Azure is crazy easy. I even messed up a few times, selected the wrong option without considering the consequences, but that wasn’t a big deal – I just deleted the App Service and started over. Once I decided what I wanted, it took me far less time to get the basic service up and running than it did for me to decide which photo I wanted to use as the header image for this blog. Here’s my current Azure dashboard:

Since this was a learning experience for me, my next post will detail the process of getting a blog (on WordPress, in my case) up and running in Azure. For now, here’s a a meme: