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.