Beyond Spreadsheets: A Practical Guide to Infrastructure as Code for Certificate Management

In early 2023, a single expired internal TLS certificate brought down a swath of Microsoft Azure services, including Storage, SQL DB, and Cosmos DB. This wasn't a sophisticated cyberattack; it was a simple, preventable administrative failure. If this can happen to one of the world's largest cloud providers, it can happen to anyone.

The era of manually managing TLS/SSL certificates in a spreadsheet is over. The industry's shift to 90-day certificate lifecycles, driven by major browser vendors, has turned what was once a quarterly task into a constant, high-stakes operational burden. Combine this with the rise of ephemeral microservices and complex cloud environments, and the risk of a catastrophic outage due to a forgotten certificate has never been higher.

The solution isn't a better spreadsheet; it's a fundamental shift in philosophy. We must treat our certificates not as static assets to be tracked, but as dynamic infrastructure components to be coded, automated, and managed with the same rigor as our servers, networks, and applications. This is the world of Infrastructure as Code (IaC) for certificate management.

This guide will walk you through why IaC is now mandatory for certificate management and provide two practical, real-world tutorials for implementing it with Terraform and Kubernetes.

The Vicious Cycle of Manual Certificate Management

For years, organizations have relied on manual processes and shared spreadsheets to track certificate expiry dates. This approach is fundamentally broken in the modern IT landscape. A 2023 report from Keyfactor revealed a startling reality: 81% of organizations still use spreadsheets for tracking, and a staggering 73% experienced at least one certificate-related outage in the past year.

These outages aren't just minor inconveniences; they erode customer trust and can cost hundreds of thousands of dollars in lost revenue and recovery efforts. The core problems with manual management are:

• Error-Prone: Manual data entry, copy-pasting certificate signing requests (CSRs), and configuring web servers by hand are recipes for human error.
• Lack of Auditability: When a certificate is renewed manually, who approved it? Where is the private key stored? A spreadsheet can't answer these critical security questions. There's no audit trail.
• Inconsistent Security: Different teams may configure TLS settings with varying levels of security, leading to weak cipher suites, outdated protocols, and inconsistent policies across your infrastructure.
• Unscalable: Manually managing ten certificates might be tedious. Managing hundreds or thousands for a microservices architecture is impossible.

Infrastructure as Code solves these problems by codifying your entire certificate lifecycle—from issuance and renewal to deployment and revocation—in version-controlled, auditable, and repeatable code.

Tutorial 1: Automating Public Certificates with Terraform and Let's Encrypt

For public-facing services running on cloud infrastructure, Terraform is an excellent tool for managing the entire stack, including TLS certificates. In this example, we'll use the official ACME provider for Terraform to automatically issue and renew a certificate from Let's Encrypt for a website.

This setup assumes you are using AWS Route 53 for DNS, but the ACME provider supports many other DNS providers.

Step 1: Configure the Terraform Provider and Generate Keys

First, we need to generate a private key for our Let's Encrypt account and another for the certificate itself. We'll use the built-in tls provider.

# main.tf

terraform {
  required_providers {
    acme = {
      source  = "vancluever/acme"
      version = "~> 2.0"
    }
    tls = {
      source  = "hashicorp/tls"
      version = "~> 4.0"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Configure your AWS provider
provider "aws" {
  region = "us-east-1"
}

# Generate a private key for your ACME account
resource "tls_private_key" "account_key" {
  algorithm = "ECDSA"
  ecdsa_curve = "P256"
}

# Generate a private key for the website's certificate
resource "tls_private_key" "website_key" {
  algorithm = "ECDSA"
  ecdsa_curve = "P256"
}

Security Note: The Terraform state file will contain these private keys. It is critical to configure a secure remote backend like an S3 bucket with encryption and access controls, rather than storing state locally.

Step 2: Register an ACME Account and Request the Certificate

Next, we register an account with Let's Encrypt and then define the acme_certificate resource. This resource is the heart of our automation.

# main.tf (continued)

# Register an account with Let's Encrypt
resource "acme_registration" "reg" {
  account_key_pem = tls_private_key.account_key.private_key_pem
  email_address   = "devops@example.com" # Use a real email for expiry notices
}

# Request the certificate using a DNS-01 challenge
resource "acme_certificate" "website_cert" {
  account_key_pem           = acme_registration.reg.account_key_pem
  common_name               = "www.example.com"
  subject_alternative_names = ["example.com"]

  # Terraform will automatically create a TXT record in Route 53
  # to prove ownership of the domain.
  dns_challenge {
    provider = "route53"
  }

  # This is the magic! Terraform will trigger a renewal if the
  # certificate has fewer than 30 days of validity left.
  min_days_remaining = 30
}

The min_days_remaining argument is crucial. On every terraform apply, Terraform will check the expiration date of the existing certificate. If it's within 30 days of expiring, the provider will automatically handle the entire renewal process.

Step 3: Deploy the Certificate to AWS Certificate Manager (ACM)

Finally, we need to get the issued certificate into a service that our load balancer can use, like AWS Certificate Manager.

# main.tf (continued)

# Upload the provisioned certificate to AWS Certificate Manager
resource "aws_acm_certificate" "cert" {
  private_key      = tls_private_key.website_key.private_key_pem
  certificate_body = acme_certificate.website_cert.certificate_pem
  certificate_chain = acme_certificate.website_cert.issuer_pem

  # Use a lifecycle block to prevent Terraform from destroying
  # the certificate if the resource is removed from the code.
  lifecycle {
    create_before_destroy = true
  }
}

# Example: Attach the certificate to an Application Load Balancer listener
# (Assumes you have an ALB and listener defined elsewhere)
resource "aws_lb_listener_certificate" "https_cert" {
  listener_arn    = aws_lb_listener.https.arn
  certificate_arn = aws_acm_certificate.cert.arn
}

With this code, running terraform apply will:
1. Generate private keys.
2. Register a Let's Encrypt account.
3. Request a certificate, automatically solving the DNS challenge via Route 53.
4. Upload the new certificate and private key to ACM.
5. Attach it to your load balancer.

When you run terraform apply again 60+ days later, Terraform will detect that the certificate is nearing expiry and repeat the process seamlessly, ensuring zero downtime.

Tutorial 2: Cloud-Native Certificate Management with Kubernetes and cert-manager

For applications running on Kubernetes, the de facto standard for certificate management is cert-manager. It's a powerful Kubernetes operator that automates the entire certificate lifecycle using native Kubernetes resources called Custom Resource Definitions (CRDs).

Step 1: Install cert-manager

You can install cert-manager into your cluster with a single kubectl command using its official Helm chart or YAML manifests.

# Install using Helm 3
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.14.4 \
  --set installCRDs=true

Step 2: Create an Issuer

An Issuer (or ClusterIssuer for cluster-wide scope) is a cert-manager resource that represents a certificate authority. Here, we'll create a ClusterIssuer that uses Let's Encrypt's ACME server with an HTTP-01 challenge, which is ideal for services exposed via an Ingress controller.

# cluster-issuer.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: devops@example.com
    # Name of a secret used to store the ACME account's private key
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          class: nginx # Or the class of your Ingress controller

Apply this manifest to your cluster: kubectl apply -f cluster-issuer.yaml.

Step 3: Request a Certificate for an Ingress

Now, requesting a certificate is as simple as adding a few annotations to your Ingress resource. cert-manager will monitor Ingress resources, find these annotations, and automatically create a Certificate resource for you.

# my-app-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: my-app
  annotations:
    # 1. Specify the ClusterIssuer to use
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  # 2. Define the TLS configuration
  tls:
  - hosts:
    - "www.example.com"
    # 3. cert-manager will create and populate this secret
    secretName: my-app-tls-secret
  rules:
  - host: "www.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

When you apply this Ingress, cert-manager's control loop does the following:
1. Sees the cert-manager.io/cluster-issuer annotation.
2. Creates a Certificate resource automatically.
3. Temporarily modifies the Ingress to solve the HTTP-01 challenge from Let's Encrypt.
4. Once validated, obtains the certificate and key.
5. Saves them into the Kubernetes Secret named my-app-tls-secret.
6. The Ingress controller automatically picks up the secret and begins serving traffic over HTTPS.

cert-manager will continuously monitor the certificate stored in the secret and automatically renew it before it expires, typically 30 days before the expiry date.

Best Practices for IaC-Driven Certificate Management

Implementing these tools is a great start, but adopting a true IaC mindset requires following a few key principles.

1. Git as the Single Source of Truth

Your certificate definitions, whether in Terraform code or Kubernetes YAML, should live in a Git repository. This provides a complete, immutable audit trail. When a security incident occurs, you can use git blame to see exactly who requested a certificate, when it was changed, and why (via the commit message). This GitOps workflow is the foundation of auditable, compliant infrastructure.

2. Never Store Private Keys in Code

Your IaC code defines how to get a certificate, but it should never store the resulting private key directly.
* For Terraform: Use a secure remote backend and immediately push the key to a dedicated secrets manager like HashiCorp Vault, [AWS