What is certificate pinning?
Ordinary TLS validation accepts any certificate that chains to a root in the device's trust store, which on a typical phone or PC means well over a hundred root certificates. Certificate pinning narrows that down. The application stores, or pins, the certificate or public key it expects for a particular server and refuses the connection if the server presents anything else, even a certificate a trusted CA issued correctly. The aim is to defeat on-path interception that relies on a misissued certificate, a compromised CA or a rogue root installed on the device.
What gets pinned
- The leaf certificate: the strictest option, but every renewal changes the certificate and breaks the pin.
- The leaf's public key: a hash of the server's public key information survives renewals as long as the same key pair is reused.
- An intermediate or root CA key: accepts any certificate from that CA, which tolerates key changes but trusts more.
Pins are usually SHA-256 hashes of the public key, encoded in Base64. One can be computed from a certificate file with an OpenSSL pipeline: openssl x509 -in server.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64. Good practice is to pin at least one backup key that isn't in use yet, so a lost or compromised key can be replaced without locking every client out.
Where pinning is used today
Pinning now lives mainly inside mobile and desktop applications that talk to their own back-end servers, such as banking, payment and messaging apps. Android apps can declare pins in a network security configuration file using a pin-set element that can carry an expiration date, iOS apps can declare pinned keys in their settings, and common HTTP libraries support pinning directly. Browsers ship a small number of built-in pins for some high-value domains.
Websites once pinned themselves through HTTP Public Key Pinning (HPKP), a response header defined in RFC 7469. It was abandoned: a wrong pin or a lost key could make a site unreachable to every returning visitor until the pin expired, and an attacker who briefly controlled a site could plant a hostile pin. Chrome removed HPKP in early 2019 and Firefox in early 2020. For websites, Certificate Transparency and CAA records took over its job.
The trade-offs
- Outages from certificate changes: rotating a key, switching CA or renewing a pinned leaf breaks every client that pinned the old value. Partners whose integrations pin a certificate need advance notice and the new chain before a planned change.
- Conflict with TLS inspection: a corporate proxy that re-signs traffic with its own CA presents a certificate the app doesn't expect, so pinned apps fail behind it and usually need a decryption bypass.
- No defense against the device owner: on a rooted or jailbroken device, instrumentation tools such as Frida can switch pinning checks off, so testers and attackers can still inspect an app's traffic.
Certificate pinning vs. CAA vs. Certificate Transparency vs. HSTS
Pinning is enforced by the client at connection time and rejects unexpected certificates outright. CAA records are checked by CAs before issuing and limit which CAs may issue for a domain. Certificate Transparency blocks nothing; it makes every publicly trusted certificate visible so misissuance can be detected. HSTS forces browsers to use HTTPS for a site but accepts any valid certificate. SSH's known_hosts file applies a related idea: the client remembers a server's key on first connection and warns if it ever changes.
Certificate pinning on the CompTIA Security+ exam
Certificate pinning is taught next to the certificate topics in SY0-801 objective 1.3, the cryptographic solutions objective, and turns up in two scenario patterns elsewhere: an app that stops working once TLS inspection is enabled, a mitigating control taught under objective 4.1, and partner integrations that fail after a certificate rotation, a change management problem under objective 1.2. Wording such as "the app must reject any certificate except the one the company expects, even if a trusted CA issued it" points to pinning. Distractors include OCSP stapling and CRLs, which report revocation, HSTS, which forces HTTPS, and a wildcard certificate, which changes coverage rather than trust.