Certificate pinning explained, and why HPKP died

Certificate pinning is the practice of hardcoding which certificate or key a client will accept for a host, so that even a technically valid certificate from a trusted authority is rejected if it is not the expected one. It closes a real attack and opens a real way to take your own service offline, which is why it has mostly moved out of browsers and into apps.

The problem it solves

Normal TLS trusts any certificate signed by any certificate authority in the client's trust store, and that store holds well over a hundred of them. If a single one of those authorities is compromised, tricked, or coerced, it can issue a valid certificate for your domain to an attacker. The client sees a correctly signed certificate and accepts it, and the attacker can intercept traffic. Pinning narrows trust: the client accepts only the specific certificate or key you nominated, so a rogue certificate from any other authority fails even though it chains to a trusted root.

What gets pinned

There are two things you can pin, and the distinction matters for how brittle the pin is.

Public key pinning is the safer of the two. A certificate expires and is reissued often, but you can generate the new certificate from the same key pair, so the pinned public key stays valid across renewals. Pinning the whole certificate means every renewal breaks the pin unless you update every client first.

Why HPKP was deprecated

HTTP Public Key Pinning let a website pin its keys through a response header that browsers would remember and enforce. It was deprecated and removed from browsers, for two reasons.

The first was the bricking risk, often called HPKP suicide. If you pinned a key and then lost it, or your certificate authority could not reissue from it, every returning visitor was locked out for the lifetime of the pin, which could be months. A single configuration mistake took the site down for its own users with no way to recover until the pin expired in each browser.

The second was that it became an attack tool. An attacker who briefly compromised a site could set a long lived pin to keys they controlled, a technique called hostile pinning or ransom pinning, holding the domain hostage after losing access. The feature created more risk than it removed, so browsers dropped it in favor of Certificate Transparency, which detects misissuance without the self destruct hazard.

Pinning lives on in mobile apps

Pinning did not disappear, it moved. Mobile apps still pin regularly, because an app ships with its own code and can bundle the expected pins at build time, and the developer controls both ends. An app talking to its own backend knows exactly which keys to trust and gains real protection against intercepted traffic, which matters on untrusted networks. The trade is the same bricking risk: if the backend rotates to a key the shipped app does not know, the app cannot connect until users install an update.

Doing it without bricking yourself

• Pin public keys, not certificates, and reuse the key across renewals.
• Pin a backup key as well as the live one, so you can rotate to the backup without an app update.
• Keep the pin set in a form you can update, and never pin to a single key with no fallback.
• For websites, do not attempt to pin at all. Rely on Certificate Transparency and CAA records instead.

To inspect the certificate chain, the key, and the issuing authority for a host before deciding what to trust, the SSL Checker shows you the full certificate details.