Overview

Every time your browser shows a padlock, a chain of cryptographic assertions has just been verified in under a hundred milliseconds. Public Key Infrastructure (PKI) and Transport Layer Security (TLS) are the machinery that lets two parties who have never met agree on a shared secret and authenticate each other. Getting this right is the difference between a private connection and one that an attacker on the same coffee-shop network can read. This group builds intuition for what certificates actually claim, who vouches for them, and what happens on the wire.

Why This Matters

Almost every network protocol you use daily rides on TLS: HTTPS, secure email submission, database drivers, gRPC, and message queues. If you cannot read a certificate, reason about a chain of trust, or explain why a handshake failed, you cannot debug production outages or reason about the security posture of a system. PKI is also where cryptography meets operations: expired certificates cause more outages than broken math ever will.

The Core Problem PKI Solves

Public key cryptography gives you a way to encrypt to someone or verify their signature, but it does not tell you whose key you actually hold. An attacker can generate a keypair and claim to be your bank. PKI answers the question “is this really the bank’s key?” by having a trusted third party, a Certificate Authority (CA), digitally sign a statement binding a public key to an identity such as bank.example.com. That signed statement is a certificate.

What a Certificate Asserts

A certificate is not a secret and it is not encryption. It is a signed claim of the form: “The holder of the private key matching this public key is authorized to use these names, and I, the issuing CA, vouch for that until this expiry date.” Nothing more. It says nothing about the site being safe, well-run, or trustworthy in a human sense. See the sibling page X.509 Certificates for the exact fields.

Chains of Trust and Root Stores

Trust is not flat. Your operating system and browser ship with a root store: a curated set of root CA certificates that are trusted by decree. Roots almost never sign leaf certificates directly. Instead they sign intermediate CAs, which sign the leaf certificate presented by a server. Verification walks this chain from leaf to a trusted root.

Level	Signed by	Kept where	Lifetime
Root CA	Itself (self-signed)	Offline, air-gapped HSM	10 to 25 years
Intermediate CA	Root CA	Online HSM at the CA	3 to 12 years
Leaf (server)	Intermediate CA	On the web server	90 days to 1 year

The sibling page Certificate Authorities walks a real chain and builds a lab CA. See also Mutual TLS for the case where the client also presents a certificate.

What Really Happens in a TLS 1.3 Handshake

TLS 1.3 collapsed the older multi-round-trip dance into a single round trip. At a high level: the client sends a ClientHello with its key share and supported cipher suites, the server replies with its own key share, its certificate, and a signature. Both sides derive the same shared secret via an ephemeral Diffie-Hellman exchange, and application data flows. The certificate proves identity; the ephemeral key exchange provides forward secrecy so that recording today’s traffic does not decrypt it after a future key compromise. The sibling page TLS Handshake dissects this on the wire.

First Look

mkdir -p ~/crypto-lab && cd ~/crypto-lab
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Expected output:

subject=C=US, ST=California, L=Los Angeles, O=Internet Corporation for Assigned Names and Numbers, CN=*.example.com
issuer=C=US, O=DigiCert Inc, CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1
notBefore=Jan 15 00:00:00 2026 GMT
notAfter=Jan 15 23:59:59 2027 GMT

You just pulled a live certificate, extracted who it is for, who vouches for it, and when it expires: the three questions every verification asks.

Practical Guidance

1. Treat certificate expiry as an operational risk: monitor notAfter and alert well before it, because expired leaf certificates are a top cause of self-inflicted outages.
2. Always send the full chain (leaf plus intermediates) from your servers; a missing intermediate is the most common “works in my browser but fails in curl” bug.
3. Prefer TLS 1.3 and disable TLS 1.0 and 1.1 everywhere; they are deprecated and carry known weaknesses.
4. Never disable certificate verification to “make it work” in code; fix the trust store or the chain instead.
5. Learn to read a certificate before you learn to issue one; inspection with openssl x509 is the single most useful PKI skill.