How to Pin TLS Certificates Safely
Pinning is a sharp tool: done right it stops a rogue CA from impersonating your service; done wrong it locks out your own users with no quick way back. The safe version comes down to three habits — pin the public key not the certificate, always keep a backup pin, and never serve a key that is not already pinned. This guide walks all three, plus when not to pin at all.
In plain words
Pinning TLS certificates safely means hard-coding which public key a client will accept so a fraudulent certificate is rejected — and PlayCISO has a free, browser-based Certificate Pinning Lab to build a pin set and simulate a rotation before you ship one.
Pin the SPKI (the key), not the leaf certificate; always ship at least one offline backup pin; keep the currently served key in every client’s pin set at all times; and don’t pin anything you cannot reliably update.
Step by step
- 1
Understand what pinning actually protects against
Certificate pinning hard-codes which key or certificate a client will accept for a given host, so that even a valid certificate from a different (possibly fraudulently issued) CA is rejected. It defends against mis-issuance and man-in-the-middle via a rogue or compromised CA. It is a powerful control and a dangerous one: a pin that no longer matches blocks your own users just as effectively as it blocks an attacker.
- 2
Pin the public key (SPKI), not the leaf certificate
Pin a hash of the Subject Public Key Info — the public key — rather than the whole certificate. If you pin the leaf certificate, every routine renewal issues a new certificate and breaks the pin even when the key is unchanged. Pinning the SPKI lets you renew, and even reuse the same key across renewals, without re-pinning, so it is the only maintainable form of pinning.
- 3
Decide where in the chain to pin
You can pin your leaf key, an intermediate CA key, or in some models the root. Pinning your own leaf/key is the tightest but needs the most careful rotation; pinning an intermediate is more forgiving because you can rotate leaves freely under it, at the cost of trusting everything that intermediate issues. Choose based on how often you rotate and how much issuance flexibility you need.
- 4
Always ship at least one backup pin
Never deploy a single pin. Generate a backup key pair now, keep its private key offline and safe, and include its SPKI hash as a second pin from day one. If your primary key is ever lost or compromised you can switch to the backup without pushing a client update — which, for installed apps, you may not be able to do in time. A pin set with no backup is a self-inflicted outage waiting to happen.
- 5
Roll out gradually in report-only mode first
Before enforcing, run in a monitoring mode that reports pin mismatches without blocking (for example HPKP’s report-only equivalent, or your mobile library’s dry-run). Watch for unexpected failures from proxies, enterprise TLS inspection, or a forgotten endpoint. Only switch to enforcement once reports are clean, and keep the enforcement lifetime short at first so a mistake expires quickly.
- 6
Rotate keys without bricking clients
To rotate, start serving a certificate whose key is already in the pin set (your backup), confirm clients accept it, then publish an updated pin set that adds your next backup and retires the old primary. The invariant is simple: at every moment the key currently being served must already be in every client’s pin set. Breaking that invariant locks users out until they update.
- 7
Know when NOT to pin
Pinning is usually wrong for public websites in browsers — HPKP was deprecated and removed precisely because sites bricked themselves — and for anything you cannot reliably update. It makes the most sense for mobile and desktop apps talking to your own backend, or machine-to-machine clients, where you control both ends. If you cannot guarantee a safe rotation path and a backup pin, do not pin.
Compute SPKI pins, build a pin set with backups, and simulate a rotation to see exactly when a client would be locked out — in your browser.
Related
Keys, certificates and trust decisions across the PlayCISO labs.
Rotate TLS certificates without downtimePinning makes rotation harder — plan the overlap carefully.
Mutual TLS LabPinning and mTLS are complementary ways to lock down who you trust.
All PlayCISO labsHands-on, browser-based security labs across crypto, cloud and incident response.
Frequently asked questions
Should I pin the certificate or the public key?
Pin the public key (the SPKI hash), not the certificate. A leaf certificate changes on every renewal even when the underlying key stays the same, so pinning the certificate forces you to re-pin constantly and makes a missed renewal an outage. Pinning the SPKI lets certificates renew freely as long as the key is reused, which is why it is the standard approach.
Why do I need a backup pin?
Because a single pin leaves you with no recovery path if that key is lost or compromised, especially for installed apps you cannot update instantly. A backup pin is the SPKI of a separate key pair you generated in advance and stored safely; including it from the start means you can switch keys by simply serving the backup, with no client update and no outage.
How do I rotate a pinned key without locking people out?
Keep the invariant that the key you are currently serving is already present in every client’s pin set. In practice you serve a certificate using a key that is already pinned (your backup), confirm clients accept it, then push an updated pin set that introduces the next backup and drops the retired key. Never serve a key that is not yet in the deployed pin set.
Is certificate pinning still recommended for websites?
Generally no. HTTP Public Key Pinning was deprecated and removed from browsers because too many sites pinned incorrectly and locked out their own visitors, sometimes permanently. For web content, Certificate Transparency monitoring and strict CAA records are safer. Pinning remains valuable in mobile and desktop apps and machine-to-machine clients where you control both ends and can rotate safely.
What happens if all my pins stop matching?
Clients will refuse to connect to the host entirely, because pinning deliberately overrides normal certificate validation. For a web page the lockout lasts until the pin lifetime expires; for an app it can last until users install an update, which some never will. This is exactly why you test in report-only mode, keep enforcement lifetimes short at first, and always carry a backup pin.