InnerWorks Logo
Return to main siteReturn to main site
Blogs

Generate Free SSL Certificates and Bind It to Azure Webapp With Devops

Greg Margol

15 Oct 2020 • 3 min read

A mini Cogtutorial for those who have multiple Azure Web Apps with custom domains and would like to automatically bind SSL certificates to their Web Apps domains (for free).

Innerworks is coming soon...

This blog was originally published on our previous Cogworks blog page. The Cogworks Blog is in the process of evolving into Innerworks, our new community-driven tech blog. With Innerworks, we aim to provide a space for collaboration, knowledge-sharing, and connection within the wider tech community. Watch this space for Innerworks updates, but don't worry - you'll still be able to access content from the original Cogworks Blog if you want. 

It was at the end of 2019 when I decided I wanted to play with Azure DevOps and create a custom extension we could use in our deployment pipeline to make things easier!

Our team had already been using Let's Encrypt for some time to generate SSL certificates for our development and UAT environments, but the idea was to automate it instead of using manual certificate binding.

This mini tutorial is for those who have multiple Azure Web Apps with custom domains and would like to automatically bind SSL certificates to their Web App domains (for free). 

 

What you will need.

  • Azure WebApp Service

  • Azure DevOps

How to get started.

Add SSL Azure WebApp Certificate Generator task to your agent job on pipeline configuration. To set this up, you will need to ensure you have an Azure subscription attached to your DevOps instance.

Next, fill in this form using the steps below:

 

Fill in the form.


1. Select the attached Azure subscription
2. Select your website App Service name
3. Select the resource group name
4. Select the domain name you'd like to attach the certificate to
5. Insert issuer email -  use [Let's Encrypt](https://letsencrypt.org/) to identify the user creating the certificate
6. Set the root path for public files on the web app. For regular .NET applications with standard configuration, it's root folder -> */*
7. Add certificate password - this will be used to generate a pfx file

The extension uses an internal HTTP certificate validation method, which means the Let's Encrypt certificate issuer will try to request a specific path on your website to validate if you own it and have access to it. 

This path is /.well-known/acme-challenge/, and you need to make sure that your application will let Let's Encrypt access files in this path. For instance, the URL for the domain. example hostname might look something like this... 

For .NET, depending on our setup (of your application configuration), you have to create a .well-know directory in the root of your public path and create the following web.config file there to give access to generated files:

<?xml version="1.0"?>

<configuration>

  <system.web>

    <!-- Make directory public. Allow anonymous users access to everything in this directory. -->

    <authorization>

      <allow users="*"/>

    </authorization>

  </system.web>  

  <system.webServer>

    <!-- Directory only contains plain text files. -->

    <staticContent>

      <mimeMap fileExtension=".*" mimeType="text/plain" />

    </staticContent>    

    <!-- Only static files are allowed, so remove everything but the StaticFile handler. This also solves the issue with extensionless files returning a 404 Page Not Found. -->

    <handlers>

      <clear />

      <add name="StaticFile" path="*" verb="*" type="" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" scriptProcessor="" resourceType="Either" requireAccess="Read" allowPathInfo="false" preCondition="" responseBufferLimit="4194304" />

    </handlers>

  </system.webServer>  

</configuration>

 

 

Considerations with generating SSL Certificates.

 With this feature, there are, however a couple of things to consider: 

- The certificates are only valid for three months

- In Azure DevOps, it's not possible to schedule certificate generation for a specific timeframe.

Nevertheless, this approach has helped us to focus on the things that are important to us, such as time and quality of work.

As always, our team is continuously working on ways to automate as many processes as possible, including building and publishing packages, deployments and managing GIT responses! We hope you found this tutorial useful! :)

 

Cogworks

 

 

Community tech aid

Innerworks and Cogworks are proud to partner with Community TechAid who aim to enable sustainable access to technology and skills needed to ensure digital inclusion for all. Any support you can give is hugely appreciated.