What is a TLS Certificate — How SSL/TLS Certificates Work

Key Takeaways

A TLS certificate binds a domain to a public key, signed by a trusted CA

Clients validate the full chain: end entity → intermediate → root

TLS often terminates at load balancers, not application servers — visibility must cover all termination points

Most outages come from expired certs, incomplete chains, or services not reloaded after renewal

A TLS certificate is a digital document that proves a server is who it claims to be. It binds a domain name (like api.example.com) to a cryptographic public key, signed by a trusted Certificate Authority. When a client connects over HTTPS, the server presents this certificate — and the client verifies the signature chain before sending any data.

Without it, there’s no encryption and no identity verification. Just plaintext flying across the wire.

Why it matters

Session encryption — the certificate’s public key bootstraps the ECDHE key exchange that produces AES session keys for the connection
Server authentication — prevents man-in-the-middle by proving the server controls the private key matching the certificate’s public key
Chain validation — clients walk the signature chain up to a root in their trust store; if any link is missing or invalid, the connection fails hard
Regulatory requirement — PCI DSS 4.0 (Req 4.2.1), HIPAA, and SOC 2 all mandate TLS for data in transit between systems

Types of TLS Certificates

By validation level:

Domain Validated (DV) — proves domain ownership only. Issued in seconds via ACME/DNS challenge. Used for most web services.
Organization Validated (OV) — includes business identity checks. Shows organization name in certificate details.
Extended Validation (EV) — highest verification level. Less common today since browsers removed the green bar.

By scope:

Single-domain — covers exactly one FQDN (www.example.com)
Wildcard — covers all single-level subdomains (*.example.com) but NOT sub.sub.example.com
SAN / Multi-domain — covers multiple specific domains in one certificate via Subject Alternative Names

How it works

Client sends ClientHello with supported cipher suites and key share
Server responds with ServerHello + its TLS certificate + key share
Client validates the certificate chain (end entity → intermediate → root)
Client checks: is the domain correct? Is it expired? Is it revoked (CRL/OCSP)?
Client and server perform key exchange (ECDHE in TLS 1.3 — no RSA key transport)
Both sides derive session keys from the shared secret
Encrypted application data flows

In real systems

Nginx — certificate and key configured in the server block:

ssl_certificate     /etc/ssl/certs/example.com.pem;
ssl_certificate_key /etc/ssl/private/example.com.key;

Kubernetes — stored as a tls Secret, referenced by Ingress:

apiVersion: v1
kind: Secret
type: kubernetes.io/tls
metadata:
  name: example-tls
data:
  tls.crt: <base64>
  tls.key: <base64>

AWS ALB — certificate managed in ACM, attached to the listener. No file management, auto-renewal handled by AWS.

Where it breaks

Expired certificates — the #1 cause of TLS outages. Certificate was valid when deployed, nobody tracked the expiry date, service goes down at 3 AM. Automation (ACME, CLM platforms) eliminates this entirely.

Incomplete chain — server sends the end-entity cert but forgets the intermediate. Works in Chrome (which fetches missing intermediates via AIA), fails in curl, Java clients, and mobile apps. Always serve the full chain.

Certificate updated but service not reloaded — automation renews the certificate files on disk, but Nginx/Apache keeps serving the old cert from memory. Without a reload or SIGHUP after renewal, the new certificate is never actually used. This is the silent failure that monitoring misses.

Where TLS actually terminates

In most architectures, TLS does not terminate on the application server. It terminates at:

Load balancers (AWS ALB, Nginx, HAProxy)
API gateways (Kong, Envoy)
CDN edge (Cloudflare, Akamai, CloudFront)

This means the certificate you manage may not be the one actually serving traffic. Visibility must include all termination points — not just what’s deployed on your origin servers. If you’re doing mTLS for service-to-service auth, verify where termination actually occurs and whether client certificate headers are forwarded correctly.