Public-Key-Pins (HPKP): A Cautionary Tale
HTTP Public Key Pinning (HPKP) was a powerful security header that backfired spectacularly. Learn why it was deprecated and what replaced it.
The road to hell, as they say, is paved with good intentions. In the realm of web security, no technology embodies this proverb quite like HTTP Public Key Pinning (HPKP). Introduced as a silver bullet against rogue Certificate Authorities (CAs) and nation-state Man-in-the-Middle (MITM) attacks, the Public-Key-Pins header was one of the most powerful-and dangerous-security features ever shipped to modern web browsers.
Today, HPKP is fully deprecated and obsolete. It was a loaded gun that caused catastrophic "self-denial-of-service" incidents, locking legitimate companies out of their own websites for months at a time.
In this comprehensive guide, we will dive deep into the history of HPKP, why it was deprecated, the anatomy of the Public-Key-Pins header, the terrifying reality of "Ransom-PKP," and the modern, safer alternatives you should be using to secure your SSL/TLS infrastructure in 2026 and beyond.
Quick Answer: HPKP Deprecated
What was HPKP? HTTP Public Key Pinning (HPKP) was a security mechanism that allowed a web server to tell the browser to trust only specific cryptographic keys (via their hashes) for future TLS connections.
Why was HPKP deprecated? HPKP was deprecated due to extreme operational brittleness. If a server administrator lost their pinned cryptographic keys or failed to back them up correctly, the website would be permanently bricked for any returning visitor. It also opened the door to "Ransom-PKP" attacks, where hackers could pin a site to a malicious key and demand a ransom.
What replaced HPKP? The industry has abandoned client-side key pinning for the web in favor of server-side and infrastructure-based enforcement. Today, you should use Certificate Transparency (CT) logs and DNS Certification Authority Authorization (CAA) records to prevent rogue certificate issuance.
People Also Ask
Is HPKP still supported in browsers?
No. Support for the Public-Key-Pins header was entirely removed from Google Chrome (v72), Mozilla Firefox (v72), Apple Safari, and Microsoft Edge. Emitting the header today does nothing in modern browsers.
What is the difference between HPKP and HSTS?
HSTS (Strict-Transport-Security) forces the browser to only connect to a site over HTTPS, preventing downgrade attacks. HPKP forced the browser to only accept specific SSL certificates over that HTTPS connection. HSTS is highly recommended; HPKP is dead.
Do mobile apps still use certificate pinning? Yes! While HPKP (web-based pinning) is dead, application-level certificate pinning inside mobile apps (iOS/Android) and thick clients is still considered a best practice. Because developers control the app deployment cycle, they can issue a forced update if the pinned keys need to change, avoiding the catastrophic lockout scenario seen on the web.
How do I remove an old HPKP header?
If you still have Public-Key-Pins in your legacy web server configuration, you should delete the directive entirely.
Understanding the Problem: Why Did HPKP Exist?
To understand why HPKP was created, we must look at the foundational weakness of the Web's Public Key Infrastructure (PKI).
When your browser connects to sechead.com over HTTPS, the server presents a digital certificate. This certificate is trusted because it was digitally signed by a Certificate Authority (CA) (like Let's Encrypt, DigiCert, or GlobalSign).
Browsers and operating systems ship with a pre-installed list of hundreds of "Trusted Root CAs." Here is the fundamental flaw: By default, any of those hundreds of trusted CAs can issue a valid certificate for any domain in the world.
If a hacker or a hostile government compromises just one of those hundreds of CAs, they can issue a fraudulent certificate for google.com or yourbank.com. Since the compromised CA is in the browser's trust store, the browser will silently accept the fake certificate, allowing the attacker to intercept, decrypt, and manipulate all traffic.
This wasn't just a theoretical threat. In 2011, a Dutch CA named DigiNotar was hacked. Attackers generated rogue certificates for Google, Yahoo, Skype, and others, facilitating massive state-sponsored surveillance against internet users.
The HPKP Solution
Security engineers realized that relying on hundreds of CAs was too risky. They needed a way for a domain to say: "I only get my certificates from this specific provider. If you ever see a certificate for me signed by anyone else, it's an attack. Drop the connection immediately."
Thus, HTTP Public Key Pinning (HPKP) was born (RFC 7469).
It was delivered via an HTTP response header. When a user visited a site for the first time, the server sent the Public-Key-Pins header, giving the browser a list of cryptographic hashes (pins) representing the public keys of the site's legitimate certificate chain.
HTTP/1.1 200 OK
Date: Mon, 22 Jun 2026 12:00:00 GMT
Server: SecHead/2.0
Strict-Transport-Security: max-age=31536000; includeSubDomains
Public-Key-Pins: pin-sha256="cUPcTAywTlz2aR41c/o96gTpHsXzR1vB2xYv2Y4="; pin-sha256="sm2x/Rz6hCGW1N1t3aV8jE1eBvI0qFk/YqA="; max-age=2592000; includeSubDomains
Content-Type: text/html; charset=UTF-8
For the duration specified in the max-age directive (e.g., 30 days), the browser would securely store those pins. If the user revisited the site and the server presented a certificate that didn't match at least one of those pinned keys, the browser would throw an un-bypassable, hard-fail security error.
The Anatomy of the Public-Key-Pins Header
To truly appreciate the complexity of HPKP, let's dissect its syntax. A valid HPKP header required at least two pins: one for the active certificate key, and a backup pin for a key not currently in use (stored offline securely).
pin-sha256="<base64>": The Base64-encoded SHA-256 hash of the Subject Public Key Information (SPKI) from the certificate.max-age=<seconds>: The time (in seconds) that the browser should remember the pin.includeSubDomains(Optional): Applied the pinning policy to all subdomains.report-uri="<URL>"(Optional): Instructed the browser to send JSON reports of pinning failures to a specific endpoint, similar to CSP reporting.
Generating the Pin
System administrators had to use OpenSSL to extract the SPKI hash from their certificates or private keys:
$ openssl x509 -in certificate.crt -pubkey -noout | \
openssl pkey -pubin -outform der | \
openssl dgst -sha256 -binary | \
openssl enc -base64
cUPcTAywTlz2aR41c/o96gTpHsXzR1vB2xYv2Y4=
This manual, cryptographic overhead was the first sign that HPKP was not for the faint of heart.
The Dark Side of HPKP: Why it Failed Spectacularly
If HPKP solved a critical security vulnerability, why was it deprecated? The answer lies in its unforgiving nature. HPKP was inherently a "fail-closed" mechanism. If anything went wrong, the website went offline.
1. The "HPKP Suicide" (Self-Inflicted Bricking)
Because the HPKP error in the browser was strictly un-bypassable (no "Click here to proceed to unsafe-domain.com" button), a misconfiguration was fatal.
Imagine a company setting a max-age of one year (31,536,000 seconds). Six months later, their server hardware catastrophically fails. They lose the active private key. No problem, they have the backup key required by the RFC, right?
What if the backup key was on the same server that died? What if the system administrator who generated the backup key left the company and deleted the USB drive?
If the company had to generate a brand new private key and get a new certificate, every user who had visited the site in the last six months would be completely locked out for the remainder of the year.
URL: https://www.example-bricked-site.com
Title: Privacy Error
NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN
The server presented a certificate that does not match the pinned public keys.
This may be an attacker attempting to intercept your connection, or the
website administrator may have misconfigured their server.
[There is no button to bypass this warning]
This exact scenario happened to several high-profile websites. The web hosting company Smashing Magazine notoriously bricked their own domain for a segment of their users in 2016 due to an HPKP misconfiguration, leading to severe financial and reputational damage.
2. Ransom-PKP (Hostage Situations)
The second nail in HPKP's coffin was the theoretical (and sometimes practical) threat of Ransom-PKP.
If a malicious actor briefly gained administrative access to a server, or if a disgruntled employee wanted to exact revenge, they could deploy an HPKP header pinning the domain to a public key only the attacker controlled.
They could set the max-age to a year, wait for Google's crawlers and thousands of users to visit the site (caching the malicious pin), and then delete the header and leave.
<strong>CRITICAL THREAT: Ransom-PKP</strong>
An attacker could email the company stating: "Your domain is now pinned to my private key. Pay 50 Bitcoin, or I will destroy the key, and your returning customers will be permanently locked out of your web app."
Because the browser enforced the pin client-side, the server owners were powerless to reverse the damage once the user's browser had cached the header.
3. Crippling Operational Complexity
Web infrastructure changes rapidly. Companies migrate between cloud providers, switch CDN vendors (like moving from Cloudflare to Fastly), and change Certificate Authorities.
If a company was using HPKP and decided to switch to a CDN that managed certificates on their behalf, they couldn't just flip the DNS switch. The CDN's certificates wouldn't match the old HPKP pins, causing mass outages. Companies had to undergo complex, multi-month rollover ceremonies to slowly introduce new pins, wait for user caches to expire, and then transition infrastructure. It stifled agility.
4. Low Adoption
Because of the massive risks, almost no one used HPKP. A scan of the Alexa Top 1 Million websites in 2017 showed that less than 0.1% of websites deployed HPKP, and of those, a significant percentage were misconfigured and technically invalid.
Google Chrome's security team realized that the theoretical protection against rogue CAs was vastly outweighed by the practical reality of website administrators continuously shooting themselves in the foot.
The Deprecation Timeline
The writing was on the wall for HPKP in late 2017.
- October 2017: Chris Palmer from the Google Chrome security team announced the "Intent to Deprecate and Remove" HTTP-Based Public Key Pinning.
- May 2018 (Chrome 67): Chrome began ignoring the
Public-Key-Pinsheader completely. - October 2019 (Firefox 72): Mozilla officially removed HPKP support from Firefox.
- Apple Safari & Edge: Quietly dropped support in tandem with Chromium and WebKit engine updates.
By 2020, HPKP was a relic of the past.
How it Was Configured (And How to Clean it Up)
If you are a web developer or system administrator inheriting a legacy codebase, you might still find Public-Key-Pins lurking in old Nginx or Apache configurations.
Historical Nginx Configuration (Do Not Use)
# LEGACY NGINX CONFIG - DO NOT USE THIS IN PRODUCTION TODAY
add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains' always;
Historical Apache Configuration (Do Not Use)
# LEGACY APACHE CONFIG - DO NOT USE THIS IN PRODUCTION TODAY
Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"
Historical Node.js / Express Configuration (Helmet)
The popular helmet security middleware for Node.js used to have an hpkp module:
// LEGACY NODE.JS EXPRESS CONFIG - THIS MODULE IS DEPRECATED
const hpkp = require('hpkp');
app.use(hpkp({
maxAge: 5184000,
sha256s: ['base64+primary==', 'base64+backup=='],
includeSubDomains: true
}));
The Cleanup Protocol: Removing HPKP Safely
If you find this header in your environment today, what should you do?
Because modern browsers actively ignore the header, it is entirely safe to simply delete the line of configuration from your server. There is no risk of breaking modern clients because Chrome, Firefox, Safari, and Edge do not parse the header at all.
If, for some highly unusual reason, you are supporting incredibly old, legacy systems (e.g., embedded devices running Chrome v50 that somehow still validate pins), the safest deprecation path was to set the max-age to 0 to instantly clear the cache on client devices:
HTTP/1.1 200 OK
Public-Key-Pins: max-age=0;
Leave that configuration active for a few weeks, and then remove the header entirely.
Modern Alternatives to HPKP: How We Secure PKI Today
The death of HPKP did not mean the threat of rogue CAs disappeared. Instead, the security community realized that putting the enforcement burden on the user's browser was the wrong architectural decision.
Today, we protect the PKI ecosystem through systemic transparency and DNS-based enforcement.
1. Certificate Transparency (CT)
Certificate Transparency is an open framework that requires all CAs to publicly log every single certificate they issue into immutable, append-only cryptographic ledgers (CT Logs).
If a CA issues a certificate for sechead.com, that issuance is permanently recorded in a public database. Domain owners can monitor these logs using services like Cloudflare's CT Monitoring or crt.sh. If an attacker tricks a CA into issuing a fake certificate for your domain, you will immediately receive an alert.
More importantly, modern browsers (like Chrome and Apple Safari) now mandate Certificate Transparency. If a web server presents a certificate that does not have Signed Certificate Timestamps (SCTs) proving it was submitted to public CT logs, the browser will reject the connection with ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.
This eliminates the need for HPKP. Rogue CAs cannot secretly issue stealth certificates anymore; if they do, the browser rejects it, and if they log it, the domain owner sees it and can have it revoked instantly.
(Note: In the transitional period after HPKP, the Expect-CT header was introduced to help sites transition to CT enforcement. However, as of 2021, CT is universally mandatory in modern browsers, and the Expect-CT header has also been deprecated and removed. You do not need to configure it.)
2. DNS Certification Authority Authorization (CAA)
CAA is a DNS record that allows domain owners to explicitly specify which Certificate Authorities are allowed to issue certificates for their domain.
Instead of HPKP (where the browser checks the key after the certificate is issued), CAA prevents the rogue certificate from being issued in the first place. When a CA receives a request for a new certificate, they are mandated by the CA/Browser Forum Baseline Requirements to check the domain's CAA DNS records. If the CA's name is not in the record, they must refuse to issue the certificate.
Example CAA Configuration:
If you only want Let's Encrypt and DigiCert to issue certificates for your domain, you would add these DNS records:
sechead.com. IN CAA 0 issue "letsencrypt.org"
sechead.com. IN CAA 0 issue "digicert.com"
sechead.com. IN CAA 0 iodef "mailto:security@sechead.com"
issue: Specifies the allowed CA.issuewild: Specifies CAs allowed to issue wildcard certificates.iodef: Instructs the CA to send an email to your security team if someone attempts to request an unauthorized certificate.
CAA is vastly superior to HPKP because it operates entirely out-of-band at the infrastructure level. It cannot brick user browsers, and a temporary misconfiguration can be fixed instantly by updating the DNS record (subject to TTL).
Best Practices for SSL/TLS Security in 2026
With HPKP gone, what should a secure, modern web application's configuration look like? Follow this checklist to ensure your transport layer is ironclad:
- Enforce HSTS (
Strict-Transport-Security): Always redirect HTTP to HTTPS, and serve the HSTS header with a longmax-age(e.g., 1 year) and theincludeSubDomainsandpreloaddirectives. Submit your domain to the HSTS Preload List. - Deploy CAA DNS Records: Explicitly restrict which CAs can issue certificates for your domains.
- Monitor Certificate Transparency Logs: Subscribe to a service that alerts you whenever a new certificate is issued for your domain names.
- Use Modern TLS Versions: Disable TLS 1.0 and 1.1. Strongly prefer TLS 1.3, while supporting TLS 1.2 with strong, forward-secret cipher suites (like AES-GCM or CHACHA20-POLY1305).
- Automate Certificate Renewal: Use ACME protocols (like Certbot / Let's Encrypt) to issue short-lived certificates (e.g., 90 days) and automate their renewal. Short-lived certificates naturally limit the blast radius of a compromised private key.
Comprehensive FAQ on HPKP and Certificate Security
1. What does HPKP stand for? HPKP stands for HTTP Public Key Pinning. It was a security standard delivered via HTTP headers that instructed web browsers to associate a specific cryptographic public key with a certain web server to prevent MITM attacks.
2. Why was HPKP dangerous? It was a "fail-closed" mechanism enforced entirely by the user's browser. If a company lost access to their pinned cryptographic keys, or an attacker pinned the domain to an arbitrary key (Ransom-PKP), legitimate users were permanently locked out of the website until the header's cache expired, which could take up to a year.
3. When was HPKP deprecated? The deprecation process began in late 2017. Google Chrome completely removed support for HPKP in May 2018 (Chrome 67). Mozilla Firefox followed suit and removed it in October 2019 (Firefox 72).
4. Should I still use HPKP in my application? Absolutely not. If you are developing a web application, you should never use HPKP. Modern browsers completely ignore the header, and legacy systems could be actively harmed by it.
5. What is Ransom-PKP? Ransom-PKP was a theoretical attack vector where a hacker would gain temporary control of a web server and inject an HPKP header containing cryptographic keys that only the hacker possessed. The hacker would then demand a ransom to hand over the keys, threatening to leave the site permanently inaccessible to returning visitors.
6. Does HPKP protect against SSL Stripping?
No. HPKP only worked if the initial connection was made over secure HTTPS. To protect against SSL Stripping (where an attacker downgrades the connection from HTTPS to HTTP), you must use the Strict-Transport-Security (HSTS) header.
7. Are mobile applications affected by HPKP deprecation? No. HPKP was specifically a web standard (HTTP-based). Mobile applications (iOS and Android) and desktop thick clients still frequently use application-level certificate pinning. Because app developers can push software updates to bypass a broken pin, the catastrophic lockout risks of web-based HPKP do not apply to native mobile apps.
8. What is the Expect-CT header?
Expect-CT was a transitional security header introduced after HPKP to help websites verify that their certificates were being properly logged in Certificate Transparency (CT) logs. Like HPKP, Expect-CT is now also fully deprecated because CT logging is universally mandatory in modern browsers.
9. How do I test if my site has HPKP enabled?
You can use command-line tools like curl -I https://yourdomain.com or browser developer tools (Network tab) to inspect your server's HTTP response headers. If you see Public-Key-Pins or Public-Key-Pins-Report-Only, you should remove it from your server configuration immediately.
10. What is CAA and how does it replace HPKP? CAA (Certification Authority Authorization) is a DNS record that restricts which CAs are allowed to issue certificates for your domain. It prevents rogue issuance at the infrastructure level before the certificate is even created, making it a much safer and more reliable alternative to the client-side enforcement of HPKP.
11. Can HPKP be used in Report-Only mode?
Historically, yes. The Public-Key-Pins-Report-Only header allowed administrators to test their pinning configuration without enforcing it. The browser would send JSON violation reports to a specified endpoint instead of blocking the connection. However, this header is also deprecated and ignored by modern browsers.
12. What was the Diginotar incident? In 2011, the Dutch Certificate Authority DigiNotar was compromised. Attackers issued fraudulent SSL certificates for domains like google.com. Because DigiNotar was trusted by default in all browsers, the attackers were able to launch massive MITM surveillance campaigns. This incident was the primary catalyst for the creation of HPKP.
13. Do I need to rotate my SSL certificates manually now? No. Modern best practices dictate that SSL certificates should have short lifespans (typically 90 days) and be rotated completely automatically using the ACME protocol (e.g., Let's Encrypt). This automation reduces human error and mitigates the risk of long-term key compromise.
14. What happens if a CAA record is misconfigured? If a CAA record is misconfigured (e.g., you typo the CA's domain), you simply will not be able to obtain a new SSL certificate from your provider. While frustrating, it is infinitely better than HPKP, because your existing valid certificates will continue to work, and you can instantly fix the DNS typo without bricking your active users.
15. Is DANE a viable alternative to HPKP? DANE (DNS-based Authentication of Named Entities) uses DNSSEC to pin certificates to DNS records. While it solves similar problems, DANE requires widespread DNSSEC deployment, which has historically been slow. CAA and Certificate Transparency remain the dominant, industry-standard solutions today.
Conclusion
The story of HTTP Public Key Pinning is a fascinating case study in cybersecurity architecture. It proves that extreme security measures, if designed without operational empathy and fault tolerance, can become a greater threat to availability than the adversaries they were designed to thwart.
As web security professionals, we must learn from HPKP's failure. Security must not only protect the user but also be resilient enough to survive the inevitable chaos of human error and infrastructure drift. Today, with Certificate Transparency and CAA, we have achieved exactly that.
Meta Title: HTTP Public Key Pinning (HPKP) Deprecated: Why It Failed & What Replaced It Meta Description: Learn why the Public-Key-Pins (HPKP) header was deprecated due to extreme self-inflicted outages, and how to use CAA and CT logs for modern SSL/TLS security. URL Slug: /blog/hpkp-deprecated Keywords: HPKP Deprecated, Public-Key-Pins, Certificate Pinning, SSL/TLS Security, Ransom-PKP, Expect-CT, CAA, HSTS, Web Security, SecHead
Related Security Guides
Continue your journey into web security with these related, deep-dive articles from the SecHead team:
Related articles
Free tool
Check your own security headers
Instant grade, plain-language explanations, and a full remediation plan - no signup needed.
Scan your site now →