The Ops Community ⚙️

Xavier Mignot
Xavier Mignot

Posted on • Originally published at

TLS with Terraform and Azure: generate self-signed certificates

We all love starting pet projects, so we tend to buy custom domains as it can be fairly cheap. SSL/TLS certificates on the other hand used to be pricey, but today there are several solutions to get these for free.

And this is for the good cause as every website should be secured by certificates nowadays.

This post is the first of a series where I will share 3 ways to automate the generation of certificates with Terraform for your Azure projects.

This one introduces the common workflow around an Azure Web App, and shows the first level of certificate generation using self-signed certificates.

The second post is using Let's Encrypt and the last one managed certificates.

Presentation of the context for the whole series

Let's say we have the following architecture as a starting point:

Starting architecture Let's start with a Web App bound to a custom domain

So we have the following components:

  • An App Service running in a plan with in the Basic tier at least
  • A DNS zone with at least the following records:
    • A CNAME record pointing to the default App Service hostname (*
    • A TXT records to verify the domain ownership
  • These two records allow the creation of a custom hostname binding at the App Service level

Everything is created using Terraform CLI from my terminal, including the DNS records, that's why I'm using Azure DNS 😎

With this setup the App Service is accessible on the custom hostname using HTTP only, if we try to access it using HTTPS our browser displays an error as the only certificate it can find is bound the domain:

Browser error The browser displays an error as the certificate doesn't match the hostname... yet

In the Azure portal, the custom domain is added to the App Service but marked as unsecured:
Azure portal The Custom domains blade of the Azure portal displays this error on our custom domain

Now that we have our basic setup, let's see how we can secure this web app.

GitHub repository

All the code from this series of posts is available in the following repo:

GitHub logo xaviermignot / terraform-certificates

A repository showing how to generate certificates using Terraform

Certificate generation with Terraform for Azure App Service

This repository contains sample code to generate TLS certificates using Terraform.
It uses an Azure App Service as an example of a website to secure.

The certificates are generated in 3 ways:

  1. By creating a self-signed certificate
  2. By requesting a certificate from Let's Encrypt
  3. By creating an Azure App Service managed certificate

Obviously the third example can only work with Azure. The two others are written to work with Azure as well but can be adapted or used as an inspiration to work on other platforms.

Getting started

Set the variables of the root module

If you want to run this against your Azure infrastructure you will need to provide values for the variables of the root module:

  • The dns_zone_name should contain the name of your DNS Zone managed in Azure
  • The dns_zone_rg_name should contain the name of the resource group containing…

The readme explains how to get started if you want to create the resources and generate the certificates in your own subscription.

Level 1: generating a self-signed certificate

As a very first step we will generate a self-signed certificate, something we will not do for production but can be handy for a quick test.

HashiCorp provides a tls provider to generate the certificate using Terraform just like we will do using openssl in Linux or PowerShell in Windows.

Here is the HCL code to do this:

# Creates a private key in PEM format
resource "tls_private_key" "private_key" {
  algorithm = "RSA"

# Generates a TLS self-signed certificate using the private key
resource "tls_self_signed_cert" "self_signed_cert" {
  key_algorithm   = tls_private_key.private_key.algorithm
  private_key_pem = tls_private_key.private_key.private_key_pem

  validity_period_hours = 48

  subject {
    # The subject CN field here contains the hostname to secure
    common_name = var.common_name

  allowed_uses = ["key_encipherment", "digital_signature", "server_auth"]
Enter fullscreen mode Exit fullscreen mode

It's just two resources: a private key and a certificate generated using this private key.

We could stop here but in an Microsoft context we need to export the certificate in PFX format to use it in an Azure service such as App Service or Application Gateway.

This is done by combining the use of the HashiCorp random provider (to generate a password) and the third-party provider pkcs12:

# To convert the PEM certificate in PFX we need a password
resource "random_password" "self_signed_cert" {
  length  = 24
  special = true

# This resource converts the PEM certicate in PFX
resource "pkcs12_from_pem" "self_signed_cert" {
  cert_pem        = tls_self_signed_cert.self_signed_cert.cert_pem
  private_key_pem = tls_private_key.private_key.private_key_pem
  password        = random_password.self_signed_cert.result

# Finally we push the PFX certificate in the Azure webspace
resource "azurerm_app_service_certificate" "self_signed_cert" {
  name                = "self-signed"
  resource_group_name = var.resource_group_name
  location            = var.location

  pfx_blob = pkcs12_from_pem.self_signed_cert.result
  password = pkcs12_from_pem.self_signed_cert.password
Enter fullscreen mode Exit fullscreen mode

And that's it, the certificate is ready to be used as an App Service certificate as you can see in the full code here.

As you have probably guessed this certificate will not make the browser happy as our machine is not recognized as a trusted authority:

Browser error The hostname matches but the browser still displays an error as the authority is not trusted

But at least the Azure portal is happier as it considers that the custom domain is now secured:
Azure portal The Azure portal seems less picky than the browser...

Wrapping up

That's it for this first step, which serves as an introduction to next posts. As I already mentioned the use of self-signed certificates is not recommended for production, and next you will see we can do much better than that.

If we take a look back to our initial diagram, we have made the following changes:
Generating self-signed certs Diagram of the generation and deployment of the self-signed cert

Stay tuned for the next post who will be about Let's Encrypt. If you already need it, you can go to my repo as the code is already there 🤓

Thanks for reading !

Top comments (0)