[ Technical ]

SSL/TLS Certificates and Domains: What You Need to Know

HTTPS is mandatory. Understanding how certificates relate to domain names — wildcards, SANs, Let's Encrypt, and what happens at renewal — prevents avoidable outages.

· · 6 min read

SSL/TLS Certificates and Domains: What You Need to Know

HTTPS is table stakes — browsers mark HTTP sites as "Not Secure," and Google uses HTTPS as a ranking signal. But certificates have specific relationships with domain names that cause problems if you don't understand them.

How Certificates Are Bound to Domain Names

A TLS certificate is issued for one or more specific domain names, listed in the certificate's Subject Alternative Name (SAN) field. A certificate for example.com does not cover www.example.com — those are two different names unless both are included.

Single-domain certificate: covers exactly one FQDN (e.g. example.com)

Multi-domain (SAN) certificate: covers a list of FQDNs explicitly named at issue time

Wildcard certificate: covers one subdomain level — *.example.com covers www.example.com, api.example.com, app.example.com, but does NOT cover example.com itself (add it explicitly) or sub.api.example.com (two levels down)

Let's Encrypt and Automated Certificates

Let's Encrypt provides free, 90-day TLS certificates via the ACME protocol. Most modern hosting platforms (Cloudflare, Vercel, Netlify, Fly.io) issue Let's Encrypt certificates automatically when you point a domain to them.

For self-managed servers, the standard client is Certbot. Automation via a cron job or systemd timer is straightforward:

# Renew all certificates near expiry (run twice daily via cron)
certbot renew --quiet

Let's Encrypt certificates expire after 90 days. Automated renewal is not optional — it is the expected operating model. Treating a Let's Encrypt certificate like a traditional one-year certificate and renewing manually will result in lapses.

Domain Validation — How Certificates Are Issued

Before a CA (Certificate Authority) issues a certificate, it verifies you control the domain. There are three validation methods:

HTTP-01: place a specific file at http://example.com/.well-known/acme-challenge/<token>. CA checks the file is there. Works only for the exact domain queried.

DNS-01: create a TXT record _acme-challenge.example.com with a specific value. CA checks the DNS record. Required for wildcard certificates; works without an HTTP server running.

TLS-ALPN-01: handled at the TLS layer directly. Used by some hosting platforms internally; rarely configured manually.

For wildcard certificates (*.example.com), DNS-01 is the only option. This requires programmatic access to your DNS provider for automated renewal — your ACME client needs API access to create and delete TXT records.

What Happens at Domain Transfer

Certificates are not transferred with a domain. When you move a domain to a new registrar or new hosting:

  • The certificate on the old server remains valid until it expires — but it's on the wrong server
  • The new server needs a new certificate issued for the domain
  • For Let's Encrypt, the new certificate is issued automatically once DNS propagates to the new server, assuming the hosting platform handles it

Order of operations: point DNS to new server first, let DNS propagate, then issue the certificate. Issuing a certificate before DNS propagates will fail validation.

Certificate Transparency Logs

Every certificate issued by a public CA is logged in Certificate Transparency (CT) logs. These are public, searchable records.

Practical uses:

  • Security monitoring: search crt.sh for your domain to see all certificates ever issued for it. Unexpected certificates are a sign of subdomain takeover or account compromise.
  • Competitor research: searching a competitor's domain on crt.sh reveals all subdomains they've had certificates issued for — useful for discovering unreleased products, staging environments, or API subdomains.
  • Expiry tracking: CT logs show issuance and expiry dates for any domain's certificates.

.dev and .app — HTTPS Is Mandatory

The .dev and .app TLDs are on the HSTS preload list. Browsers enforce HTTPS for all domains on these TLDs before a connection is even attempted — there is no way to serve HTTP on .dev or .app in a standard browser. This is by design (both are Google Registry TLDs), but it means your HTTPS setup must be working before DNS is switched, or users will see a browser error.

Check a domain's HSTS preload status at hstspreload.org before changing DNS.