While Azure provides many tools, it doesn’t have everything. We will take a look at how you can configure a functional Let’s Encrypt SSL for any Azure Web App, in order to provide it with the necessary level of security for all standard online operations.
What Is Let’s Encrypt?
First things first, let’s get Let’s Encrypt out of the way. So, what is it? It’s an automated, free, open Certificate Authority. This means that you can acquire completely free SLL certs, and change your default URL structure from HTTP:// to HTTP://.
But what’s the catch? Can it really be that simple? Well, the SSL certifications only last 90 days, not multiple years like other certs can. Nonetheless, there is a reason for this. It is so automation is encouraged, and that you can make your SSL experience forgettable (as long as you have some scripts or background process that automatically renews and installs the certs).
Nowadays, there’s really no reason for not using Let’s Encrypt, and it is evident by the majority usage of it in a variety of industries and their consequential Web Apps.
Prerequisites for Configuration:
An active Azure account. (Students can get free Azure Resources. ) Any web application that is being hosted via the App Service. The stack does not matter. A custom DNS entry that points to the Web App.
In an ideal world, your App Service and App Service Plan are within the same resource group. But it is possible to do without this.
Step 1: Storage Account for WebJobs
Alright, so the first step is to create an Azure Storage Account, which is an extension that will allow us to renew the certification each 90 day period via Azure WebJobs.
The account should not be of BlobStorage, because it won’t work. It should be of either “Storage” or “StorageV2.”
Now that that’s done. You will add two separate settings: “AzureWebJobsDashboard” and “AzureWebJobsStorage” with a string that connects them to the formerly created Storage Account.
The string can look like this:
DefaultEndpointsProtocol=https;AccountName=[youraccount];AccountKey=[yourkey];
Step 2: Automating the Process
For the previous extension to work without our interference, we must create an “Azure Service Principal,” which works off the notion of delegation via an Azure AD entry.
Locate yourself toward the Azure Active Directory, in which you want to create the new application. Within the panel, select “App Registrations.”
Create a new application, and set it up as you can see in this image. Generate a client secret and save it somewhere safe. If you don’t, you won’t be able to access it again via clear text. Return to the Overview, and save the “Client ID. ” Now, you need to provide Contribute access to the Service Principal. It should be linked to the Resource Group of your “App Service Plan” and “App Service. ” In the next menu, select the “Contributor” role, and add it to the created “Service Principal. ” If you have any other services in the group, you can add the Contributor role to them as well.
You can tinker around with the settings as you like, but that’s about it for the Service Principal.
Step 3: Let’s Encrypt Extension
Now that you have all of the secondary prerequisites, you can finally install the extension and configure it accordingly.
Go to the “App Service,” and search for the Azure Let’s Encrypt extension by “SJKP.” After installing it, you can proceed with the configuration.
To set up the extension, you have to navigate yourself to the “Advanced Tools” page of the “App Service.” You can find it by searching for it in the search bar, and it will probably take you to a site like this: https://yourdomain.scm.azurewebsite.net.
To access the settings, you click the “Site Extensions” button and click on “Launch.” Now the configuration page should open up, and you will have the following options.
Tenant: the Azure AD director, in which your Service Principal was created. ClientID: the same client ID from before. ClientSecret: the same client Secret from before. ResourceGroupName: the name of the Resource Group of the App Service you are using. SubscriptionID: the ID of your subscription that you are using for the Resource group. Update Application Settings: always set it to True, so that all of your settings are saved. Otherwise, the settings will not be available for the WebsJobs to install the new certificates. ServicePlanResourceGroupName: If your App Service and Service Plan are in the same group, the name will be the same as the ResourceGroupName. Otherwise, you will enter the name of the Resource Group of the actual Service Plan location.
After configuring all of the options, you will be taken to an overview of Certificates, SSL Bindings & custom domains. Because you still need to generate them, you can select your domains for the request, and submit a “Get Request” for the SSL certificate.
But before you do that, you should add your email, so that you can get alerts in case anything goes wrong with the certificate (such as them being outdated or not renewed).
And that’s about it. Now everything is set up, and you can enjoy the reward of completing the task all on your own.
Potential Issues
Because the extension needs access to your pages in order for domain authorization, make sure the URL is accessible to the public via HTTP://yourdomain.com/.well-known/acme-challenge/.
If an error occurs and the URL is not reached, you probably have the rule-set on the web.config that’s preventing access or your HTTPS is enforced via the App Service Settings.
Also, because Let’s Encrypt uses the HTTP-01 mechanism in ACME, it will place a random token in the file on your web server, then it will attempt to retrieve it via HTTP. If you set the Web App to https only, the request will be denied, which is something you want to avoid.