Now it’s time to get serious. After adding an App Registration in step 1, giving it access to the Web App resource group in step 2, and preparing the Storage Account in step 3, we are now ready to finish the process by installing and configuring the Let’s Encrypt extension.

Let us head over to the web app where we will install the SSL certificate. Choose the relevant app from the App Service plan menu as shown here:

Inside the app itself, click on the Custom domains menu:

And proceed by clicking the + Add custom domain button. Fill in your domain name.

In order to add the domain name, you first have to prove that you actually own the name. I will not go into the details of buying the domain name and forwarding it to Azure in this post, but here I show one way to claim the domain ownership by using a CNAME record:

The green checkmarks indicate that the domain was verified successfully. At this point, we should also be able to notice that the newly added domain name is not secure.

It is time to fix this and conclude the tutorial! While still inside the web app, scroll down until you find the extensions menu and click it:

Then click on the + Add button:

Search for the Azure Let’s Encrypt extension by SKJP from the marketplace.

And accept the legal terms:

After accepting the legal terms, the OK button is enabled and you can click it to start the installation process.

You will get a notification of the installation status:

Once ready you will be presented with the Let’s Encrypt configuration wizard. Here you need to fill in the information of the resources that we created earlier.

The information that you need to enter is obtained as follows:

• Tenant id was shown on the last screenshot of part 1.
• Subscription id is shown on the last screenshot of part 2.
• Client id in the same last screenshot of part 1.
• Client secret on the screenshot before it.
• Resource group access was described during part 2. This is the same resource group that we configured there.
• WebAppName we also saw during this post.
• For both of the connection strings, refer to the last screenshot of part 3.
• Finally, tick the checkbox for updating the application settings.

After some time, an information screen about the existing and available custom domains shows up.

Click next to go to the final step. Here you need to pick up the domain name that the certificate will be bound to. Enter an email address where you will receive future expiry warnings and click on the Request and install certificate button.

After this, the extension will generate and install the SSL certificate for you.

We should now be able to see this new certificate in the Certificates page inside theTLS/SSL settings menu.

Back in the custom domains page, refresh to see that the domain name associated with the new certificate is now secure.

To confirm that the website is really secure, just hit it through the browser and click on the padlock icon. I’m using Chrome here so other browsers will display a different icon and have a slightly different behaviour.

Great! We have an encouraging message that the connection is secure. Clicking on the Certificate icon shown above will open the detailed certificate information window. Just like what the rest of our website visitors will see, here we can also read that the certificate was issued by Let’s Encrypt.

While we are still on the Azure portal one final thing. Since our HTTPS connection is now secured, we can switch on the option to force the secure connection. This is done again from the TLS/SSL settings page as shown here:

Now if anyone tries to access the site through the unsecured HTTP connection, they will be redirected to the secure site. We can observe and confirm this behaviour in the network headers.

So that concludes our journey to install a free SSL certificate to an Azure website through the Let’s Encrypt extension. Many thanks to SJKP for sharing this useful extension with the rest of us. If you have any further questions feel free to comment below.

After setting up the app registration and role assignment, now it is time to look into obtaining some storage.

The Let’s Encrypt application will run as a Web Job, and as a web job it needs a storage account to store the required information. So head over to the Storage accounts menu and click on the + Create button.

The storage account can be set with the cheapest configuration since the job will just run in the background without affecting the performance of your web site visitors. It can be set to standard performance, locally redundant storage, and hot access tier.

Once filled in, click on the Review + create button, and the review screen will come up. Go ahead and click on the Create button.

Wait until the new storage account is deployed, then hop over to the Access keys section and make a note of the storage account connection string.

We will then use all of the connection settings that we have collected so far in the last step. Just be patient and keep them safe.

In the previous post, we have configured an app registration to give us the means to identify the Let’s Encrypt app during automatic jobs. Now we will give access to the app so that it can manage the resources inside the web application for us.

Go to the resource group that contains the web app where the SSL certificate will be installed. Click on the Access control (IAM) menu:

On the right-hand side of the page, you should be able to see the role assignment widget. Click on the Add button inside it:

And in the role assignment window, add the Let’s Encrypt app registration as a contributor to the resource group as shown below. To find the correct app registration, use the search functionality inside the Select field. When searching for the app name, the search results will be shown below the Select field. Once clicked in the result, the app registration will then also be shown in the Selected members list.

Click the save button to finalise granting the rights to the application. Now technically, the Let’s Encrypt app has the necessary rights to modify our resources inside the selected group.

Before we conclude this step, since we are already inside the Resource group page, take note of the subscription ID as indicated above. We will also need this later, together with the client secret and client ID which we had copied during the first step. Then in the next step, we will set up a storage account.

As reported in Microsoft’s Identity Platform Blog, the user experience for Azure App Registrations has changed, and the choice to use the legacy editor will not be available after March 1st. The end result is that some things in Azure Active Directory(AAD) have been moved around. So I decided that it’s time to do another series of blog posts to describe how to configure your Azure Web App with a free Let’s Encrypt certificate because AAD is an essential part of the process.

In this first post, I will go through the process of creating an App Registration inside Azure Active Directory. By the end of the series, we will have a Let’s Encrypt extension running beside our web app. Since the generated certificates will expire every three months, this extension will renew SSL certificates automatically for us.

We need a way to give the Let's Encrypt extension access to our Azure resource group so that it can manage the resources automatically for us. An Azure App Registration will enable us to create an authentication account that the extension will use to log into our Azure Active Directory.

So without further ado, let’s start our journey to make our site secure. From the Azure Portal dashboard, click on Azure Active Directory:

Then further down look for the App registrations menu, and click the + New registration button:

This will open a new window to register the app. Here we need to provide any name which we will use to identify the application (I opted to name it Let's Encrypt). The supported account type should be ‘Accounts in this organizational directory only (Default Directory only - Single tenant)’ and the redirect URI filled in with the web app’s URL.

Click the Register button and wait for the app registration to be created.

Now we need to create the actual login. Once back to the app registrations page, click on Certificates & secrets, and then + New client secret:

Give it a descriptive name and the desired expiry time.

After the secret store is created, its value will be displayed. Make sure to copy the value by hovering on the field and clicking on the copy icon as shown below. For security reasons, this value will be hidden when you try to view it in a future session (otherwise it wouldn't be a secret anymore). We will then use this secret once when configuring the Let’s Encrypt extension during the last step and dispose of the information immediately after.

Back inside the app registration window, we also need to make a note of the application id for later.

In the second step, we will give the Let's Encrypt account that we just created access to our Azure resources.

In this tutorial, we will see how to create a YAML build pipeline from an existing pipeline built with the classic editor. Creating a YAML build pipeline from scratch may be intimidating for novice users, but if you have an existing one in the classic editor, switching over is easier. You don’t need to be a YAML guru.

Once logged in Azure DevOps, head over to your existing pipeline. This can be accessed from the build pipelines section as shown below.

In my case, I have a pipeline to build this website’s code. Click on the job name, then we will have the option to view it in YAML form.

This will open a popup window showing the existing job in the YAML format. Click the ‘Copy to clipboard’ button. We will need to paste this code into a new file soon.

We now need to copy the code and store it inside a text file in our repository. This can be done directly from the Azure DevOps portal. From your repository, create a new branch and then a new file right afterwards. Put this new file in the Pipeline folder, so that it will not be stored directly beside your code.

Paste the copied YAML into the new file.

Before you commit, it is important to check if you need to specify the image name of the build agent. When you run your build on an Azure-hosted agent, you need to add the vmImage parameter, as I did with windows-2019 below. If you have a private agent instead, just the name of the agent is enough.

Now we can go back to the build pipelines page and click on the button to create a new pipeline.

On the next step, click on the repository name.

And on the Configure step, we will select an ‘Existing Azure Pipelines YAML file’.

Then choose the filename that we just saved a few steps back.

On the final review step, we can now add the required variables. The generated YAML file contains comments about the variables that the build expects so that it can run successfully.

Click on the Variables button so that we can add them and then just add each one individually. We can look the existing classic pipeline if we need to verify the values of the variables.

We can now click the Run button to test the pipeline.

Once the job finishes, we can check the outcome.

So now we now that the build has run successfully, we can set it to be triggered automatically whenever any code is committed into the master branch. Go back to edit the YAML file and add the trigger as shown here.

And there’s no better way to test it than creating a pull request on the YAML file so that it can be integrated into master and automatically trigger the build. Create a new pull request and choose to merge the new branch into master.

If this triggers the build, then we have confirmed that we have really managed to set up everything successfully.