HPKP (HTTP Public Key Pinning)

HPKP (HTTP Public Key Pinning, RFC 7469) let a site send a Public-Key-Pins header listing SHA-256 hashes of public keys (SPKI pins). For max-age seconds afterwards, the browser rejected any connection whose certificate chain did not include at least one pinned key, even if the certificate was otherwise valid. The RFC required at least one backup pin for a key not in the current chain.

Why it matters

HPKP is a cautionary tale. A lost key, a forced CA change or a wrong pin could lock users out for the whole max-age with no remote fix, a failure known as "HPKP suicide"; an attacker who briefly controlled a site could even set malicious pins to hold it hostage. Adoption stayed tiny, and HPKP was removed from Chrome in Chrome 72. The problem it addressed, rogue certificates from trusted CAs, is now handled mainly by Certificate Transparency and CAA. Pinning survives mostly inside mobile apps as certificate pinning, with the same operational risks.

Example

Compute a pin, and the header a site would once have sent:

openssl x509 -in cert.pem -pubkey -noout \
  | openssl pkey -pubin -outform der \
  | openssl dgst -sha256 -binary | openssl enc -base64

Public-Key-Pins: pin-sha256="<primary-key-hash>"; pin-sha256="<backup-key-hash>"; max-age=5184000; includeSubDomains

Do not deploy this header today.

Common misconceptions

• HPKP is the same as HSTS. HSTS forces HTTPS; HPKP restricted which keys were acceptable. HSTS remains recommended, while HPKP has been removed from Chrome.
• Pinning the leaf key is safe if you renew carefully. Renewing with a new key breaks the pin unless a backup pin covers it, which is exactly how sites locked themselves out.
• Removing the header unlocks users immediately. Browsers kept the pins until max-age expired.