SSL/TLS Certificates

SSL/TLS certificates are the mechanism that binds a cryptographic public key to an identity (domain name, organisation, or IP address). They underpin HTTPS, mutual TLS, email signing, and code signing. Despite the name, "SSL" certificates use TLS — SSL itself is deprecated and must not be used.

How Certificates Work

A certificate contains:
- The subject's public key
- The identity the key belongs to (domain, organisation)
- The issuer (Certificate Authority that signed it)
- A validity period (not before / not after)
- Subject Alternative Names — the actual list of domains the cert covers
- The CA's digital signature over all of the above

When a client connects, the server presents its certificate. The client:
1. Verifies the CA signature chains to a trusted root in its trust store
2. Confirms the hostname matches a SAN in the certificate
3. Checks the certificate has not expired or been revoked (CRL / OCSP)
4. Uses the public key to complete the TLS handshake (key exchange)

The private key never leaves the server. If it does, the certificate must be revoked immediately.

Validation Levels

Certificate Authorities offer three validation levels. Higher validation requires more identity verification before issuance.

Domain Validation (DV)

The CA verifies only that the applicant controls the domain — no identity or organisation checks.

Verification methods: DNS TXT record, HTTP file challenge, or email to domain admin contacts.

DV is appropriate for most technical use cases. The padlock indicates encrypted transport — it says nothing about who operates the site.

Organisation Validation (OV)

The CA verifies the domain and also validates the legal existence of the organisation (via business registry, phone verification).

Extended Validation (EV)

Strictest vetting — CA verifies legal entity, physical address, operational existence, and authorisation of the requester. EV certificates once triggered a green address bar in browsers; this visual indicator was removed in 2019 as it was shown to provide no measurable phishing protection benefit.

Recommendation: DV certificates issued by Let's Encrypt are appropriate for the vast majority of use cases. Reserve OV for externally visible services where your organisation's identity in the certificate adds compliance or contractual value.

Certificate Types by Coverage

Single-Domain (Dedicated) Certificates

Covers exactly one fully qualified domain name (FQDN).

Example: www.example.com

The certificate's SAN list contains one entry. Some issuers include both example.com and www.example.com as a convenience.

When to use:

• High-value, isolated services — payment processing, authentication endpoints, admin portals. Compromise of one service's private key cannot affect others.
• Compliance requirements — PCI DSS requires isolated certificates for the cardholder data environment in some interpretations.
• Different certificate policies — if api.example.com needs a short 30-day auto-renewing cert and secure.example.com needs an OV cert, they must be separate.
• Minimising blast radius — if a private key is compromised or a certificate needs emergency revocation, only the single service is affected.

Advantages:

Disadvantages: Management overhead at scale — 50 services means 50 certificates to track, renew, and rotate. Mitigated by automation (ACME / Let's Encrypt, cert-manager, Vault PKI).

Wildcard Certificates

Covers one subdomain level beneath a base domain using the * prefix.

Format: *.example.com

Scope: Matches api.example.com, www.example.com, mail.example.com — but not example.com itself (include this as a separate SAN), and not sub.api.example.com (wildcards do not span multiple subdomain levels).

When to use:

• Large numbers of subdomains on the same service tier — e.g., tenant1.app.example.com, tenant2.app.example.com for a SaaS platform
• Environments where subdomains are created dynamically and can't be enumerated in advance
• Shared load balancers or reverse proxies serving many subdomains with the same termination point
• Development and staging environments — *.dev.example.com, *.staging.example.com
• Simplified operations — one certificate, one renewal, deployed to many services

Where wildcards are NOT appropriate:

Wildcard limitations:

• Only covers one level of subdomain: *.example.com does not cover a.b.example.com
• The apex domain (example.com) requires explicit inclusion as a SAN
• Wildcard SAN certificates (combining wildcard + explicit SANs) are supported but verify with your CA
• Let's Encrypt issues wildcard certs but only via DNS-01 challenge (requires DNS API access for automation)

# Let's Encrypt wildcard via Certbot (DNS-01 challenge)
certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d "*.example.com" \
  -d "example.com"

Multi-Domain / SAN Certificates

A single certificate with an explicit list of domains in the Subject Alternative Names extension. No wildcards — every domain is named.

Example SAN list:

DNS: example.com
DNS: www.example.com
DNS: api.example.com
DNS: shop.example.com
DNS: blog.example.com

When to use:

• Fixed, known set of domains that share a trust boundary
• Multiple domains on one server — example.com and example.co.uk both pointing to the same service
• Consolidating certificates on shared infrastructure without wildcard scope
• Maximum flexibility with explicit control over exactly which domains are covered

Choosing the Right Certificate Type

Is the domain count unpredictable or very large?
  └─ YES → Wildcard (*.subdomain.example.com)
  └─ NO ─┐
         Is this a high-security or isolated service (payments, admin, auth)?
           └─ YES → Dedicated single-domain certificate
           └─ NO ─┐
                  Are there 2–100 known domains sharing the same trust tier?
                    └─ YES → Multi-domain SAN certificate
                    └─ NO ─ Single-domain certificate

Certificate Lifecycle Management

Certificate expiry is among the most common causes of unplanned service outages. Automate everything.

Automated Renewal (ACME / Let's Encrypt)

Let's Encrypt issues 90-day DV certificates free of charge. The short validity period encourages automation.

# Certbot auto-renewal (runs as a cron/systemd timer)
certbot renew --quiet --deploy-hook "systemctl reload nginx"

# Cert-manager in Kubernetes
kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-tls
spec:
  secretName: api-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - api.example.com
EOF

Validity Periods

As of September 2020, publicly trusted certificates have a maximum validity of 398 days. Proposals to further reduce this to 90 days and eventually 47 days are in progress at the CA/Browser Forum.

Monitoring and Alerting

Never rely on developers or operations noticing expiry. Implement automated monitoring:

• Alert at 60 days, 30 days, 14 days, 7 days before expiry
• Alert immediately on certificate mismatch (hostname validation failure)
• Use a certificate inventory tool (cert-manager, Vault, Venafi, or custom scan)
• Monitor with openssl s_client or Prometheus blackbox exporter:

# Check expiry of a live certificate
echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -dates

# Get days remaining
echo | openssl s_client -connect api.example.com:443 2>/dev/null \
  | openssl x509 -noout -checkend $((30*86400)) \
  && echo "Valid for >30 days" || echo "EXPIRING WITHIN 30 DAYS"

Private Key Security

The certificate is public — the private key is the secret. Its compromise requires immediate certificate revocation and reissuance.

Key Generation

# Generate a 3072-bit RSA private key
openssl genrsa -out private.key 3072

# Or an ECDSA key (P-256) — smaller, faster, equivalently secure
openssl ecparam -name prime256v1 -genkey -noout -out private.key

Key Storage

Rules

• Never commit private keys to source control — scan repos with tools like git-secrets or TruffleHog
• Never log private keys or include them in support bundles
• Restrict read access — only the process serving the certificate should read the private key file
• Rotate on personnel change — if someone with key access leaves, reissue the certificate
• Revoke immediately on suspected compromise — do not wait for expiry

Revocation

If a certificate's private key is compromised or the certificate was mis-issued, it must be revoked:

CRL (Certificate Revocation List): CA publishes a periodically updated list of revoked serial numbers. Clients download the CRL and check against it.

OCSP (Online Certificate Status Protocol): Client queries the CA's OCSP responder in real time for the status of a specific certificate.

OCSP Stapling: The server fetches and caches the OCSP response and includes it in the TLS handshake — improves performance and privacy (client does not contact CA directly).

# Enable OCSP stapling in Nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/certs/ca-bundle.crt;
resolver 8.8.8.8 1.1.1.1 valid=300s;

Common Mistakes

Internal PKI

For internal services (microservices, internal APIs, mTLS), run your own Certificate Authority rather than using public CAs for non-public names.

Options:

Short certificate lifetimes (1–30 days) from an internal CA are achievable with automation and provide strong security guarantees — a compromised cert expires quickly and revocation complexity is reduced.

References

• CA/Browser Forum Baseline Requirements
• Let's Encrypt — How It Works
• RFC 5280 — Internet X.509 PKI Certificate Profile
• Mozilla SSL Configuration Generator
• NIST SP 800-57 — Key Management
• HashiCorp Vault PKI Secrets Engine