DNS
Intermediate 12 min read DNS

Custom Domains and Certificates

Your name, your cert, at the edge

Pointing a custom domain at cloud services means wiring DNS records (CNAME/alias) and provisioning TLS certificates verified via DNS or HTTP. ACM/Key Vault/Certificate Manager centralize issuance, renewal and rotation.

TLScertificateACMCNAMEACMEcustom domainHTTPS
Prerequisites: DNS Fundamentals
Before we start

What you will learn

  • Wire a custom domain to a cloud endpoint
  • Issue and renew certificates with ACME/managed CA
  • Satisfy DNS/HTTP validation flows
In 60 seconds

Custom domains: add a CNAME/alias record to the LB/CDN/Function URL, then prove ownership via a TXT/DNS or HTTP/ACME challenge and get a managed TLS certificate auto-renewed at the edge.

Introduction

What is this?

Cert issuance: AWS Certificate Manager (ACM) validates DNS/email and auto-renews; Azure Key Vault certificates + App Service binding (auto); GCP Certificate Manager with ACME/DNS challenge. Domain wiring: alias/CNAME/A records pointing to the endpoint DNS name; CDN (CloudFront/App Gateway/Cloud CDN) fronts the domain and terminates TLS with the cert. Validation flow: DNS challenge (TXT/_acme-challenge) or HTTP-01 file. Renewal is automatic for managed CAs when DNS/HTTP validation remains.

Motivation

Why do you need it?

  • A custom domain is what users remember and what you control on a migration.
  • Managed CAs auto-renew → the 'certificate expired' page becomes rare.
  • Terminating TLS at the edge centralizes certs and offloads handshakes.
  • DNS validation survives behind NAT and doesn't need a public webserver.
Think about it

Mental model

Imagine

Hanging your own business sign with a pre-approved building permit

Think of

Domain + certificate

The permit (certificate authority) verifies you really own the address (domain) via paperwork left in the mail slot (DNS challenge); once approved, the sign (TLS) stays up and renews automatically like the building auto-filing the permit.

Mechanics

How it works

  • Create a hosted zone; point the domain's NS to it (or keep the registrar's DNS and add records there).
  • Add the record: alias/CNAME to your LB/CDN/Func URL (works with any HTTPS-capable target).
  • Request a cert for the domain in the managed CA; choose DNS validation.
  • Add the CNAME/_acme-challenge record; the CA checks it and issues.
  • Attach the cert to the edge (ALB/Ingress/CDN); managed renewal keeps it fresh.

Domain + TLS wiring.

Registrar
DNS record
CA validation
Certificate
Edge terminates TLS
Hands-on

Examples

DNS validation flow on AWS

DNS validation flow on AWS
# 1) request cert
aws acm request-certificate --domain-name app.example.com \
  --validation-method DNS --region us-east-1
# 2) get the CNAME to publish
aws acm describe-certificate --certificate-arn <arn> \
  --query 'Certificate.DomainValidationOptions[0].ResourceRecord'
# 3) add the record to the zone, wait for 'ISSUED', then attach to the LB listener

Request → publish the validation CNAME → ACM 'ISSUED' → attach to the edge; renewal is automatic.

Real world

In production

  • A multi-tenant SaaS uses ACM wildcard *.app.example.com with DNS validation per env (prod/dev).
  • Azure App Service custom domains bound with a Key Vault cert that rotates automatically.
  • GCP Certificate Manager ACME issues for a Cloud CDN origin and auto-renews via DNS.
Guidelines

Best practices

  • Prefer DNS validation — automation-friendly, works behind NAT, no port 80 needed.
  • Use wildcards sparingly (wildcard + specific names); scope the smallest set that serves the service.
  • Keep the validation records until renewal succeeds, or breakage is silent.
  • Test renewal at least once before trusting 'this is automatic'.
Watch out

Common mistakes

  • Deleting the _acme-challenge record after issuance → renewal silently fails, cert expires.
  • Requesting the cert in the wrong region then wondering why the LB doesn't see it.
  • Pointing the domain at an endpoint whose cert covers a different name (patient SNI error).
  • Declaring 'we have TLS' while browsers show a mixed-content/invalid-chain warning.
Root cause analysis

Common issues

Error
Certificate status stuck 'PENDING_VALIDATION'
Root cause

Validation CNAME missing/mistyped or not propagated

Fix

Add the exact record from describe-certificate; wait TTL+; then request re-validation.

Error
Custom domain fails SNI
Root cause

Cert lacks the FQDN or the edge isn't serving that cert

Fix

Ensure the cert covers the exact domain (and www) and is bound to the listener serving it.

When things break

Debugging tips

  • Cert shows 'pending' — verify the DNS record exists and propagation from a different resolver.
  • Browser cert error: compare the cert's SAN list vs the requested hostname.
  • Mixed content: the page loads HTTPS but assets via HTTP — inspect network tab origins.
  • Expired cert despite renewal: check the validation record is still present and the CA check reaches it.
Interviews

Interview checkpoint

Practice

Hands-on lab

Request, Validate and Bind a Domain (DNS-01)
25 min · intermediate
In progress
Objectives
  • Exercise the DNS validation flow
  • Bind a cert to an HTTPS listener
  • Plan an automated renewal guardrail

Request, Validate and Bind a Domain (DNS-01)

25 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

Why is DNS validation preferred for ACME/cert issuance?

Go deeper

Official documentation

AWS — Certificate Manager
docs
Azure — TLS/SSL certs
docs
GCP — Certificate Manager
docs