Certificate pinning restricts which TLS certificates a client accepts for a specific domain, beyond standard CA validation. The client stores expected certificate hashes and rejects connections presenting different certs – even if CA-signed. Pins prevent MITM via compromised CAs but cause outages if pins are not rotated before certificate renewal.
Certificate pinning binds a domain to specific certificates or public keys, preventing acceptance of any other valid cert. Without pinning, any of the hundreds of trusted CAs could issue a certificate for your domain – a compromised or coerced CA enables government MITM surveillance. With pinning, even a valid CA-signed certificate is rejected if its hash does not match the pin. HPKP (HTTP Public Key Pinning) was a browser standard but was deprecated because misconfigured pins locked users out permanently. Mobile apps still use pinning extensively (banking, security apps) by embedding expected hashes in the app binary. Modern alternatives include Certificate Transparency (CT) log monitoring which detects unauthorized issuance without the catastrophic failure mode of hard pinning.
Certificate Authority (CA)
A Certificate Authority issues and signs TLS certificates that browsers and operating systems trust. CAs verify domain ownership (DV), organization identity (OV), or extended validation (EV) before signing. The CA system relies on ~150 root certificates pre-installed in trust stores. Let's Encrypt automated DV issuance, issuing 400M+ active certificates.
Man-in-the-Middle (MITM)
A man-in-the-middle attack intercepts communication between two parties, reading or modifying traffic without either party's knowledge. TLS prevents MITM by authenticating the server via certificates and encrypting the channel. MITM succeeds when: TLS is absent (HTTP), certificate validation is disabled, or the attacker controls a trusted CA.