MOZILLA_PKIX_ERROR_KEY_PINNING_FAILURE (HPKP mismatch)

What’s actually happening

Firefox refuses the connection and, unlike most cert errors, often won't even let you click through to proceed. The certificate can otherwise be perfectly valid (good dates, trusted CA, right hostname) and Firefox still says no. It happens because the site previously told Firefox to pin specific public keys, or Firefox ships a built-in pin for that domain, and the cert now on the wire doesn't carry any of those keys. Frequently it's one machine throwing the error while others on the same network load the site fine, which points straight at something local intercepting TLS.

Common causes

• A TLS-intercepting antivirus or security suite (Avast, Kaspersky, ESET, Bitdefender) injecting its own certificate to scan HTTPS, whose key obviously doesn't match any real pin
• A corporate proxy or middlebox doing SSL inspection with a locally trusted root, same mismatch
• An old HTTP Public Key Pinning (HPKP) header the site sent earlier, still cached in Firefox, after the site reissued under a key not in the pin set
• A stored dynamic pin in the profile's SiteSecurityServiceState.txt that's gone stale relative to the current cert
• A built-in static pin (Mozilla ships these for high-value domains like Google and Mozilla properties) not matching because of interception upstream

How to fix it

1. Check for a TLS-intercepting product firstThis is the most common cause now. In your antivirus, turn off HTTPS scanning / SSL filtering / web shield (Avast: Web Shield > enable HTTPS scanning, uncheck; Kaspersky: disable Encrypted connections scan; ESET: SSL/TLS protocol filtering off). Reload with Ctrl+F5. If the error vanishes, the AV was the interceptor.
2. Clear the stale pin from the profileVisit about:support, click Open Folder next to Profile Folder, fully quit Firefox, then delete or trim SiteSecurityServiceState.txt (it stores HSTS and dynamic key pins). Restart Firefox. This wipes a cached HPKP pin left over from a prior cert that's now blocking the new one.
3. Confirm by testing another browser or networkOpen the same URL in Chrome or on a phone on cellular. If those work and only this Firefox profile fails, the pin/interception is local to that machine, confirming the fix path above rather than a server problem.
4. If you run the site, drop HPKP entirelyStop sending the Public-Key-Pins header. HPKP is deprecated and removed from browsers; a stale pin can lock out returning visitors for the max-age you set. Serve HSTS instead for transport security and, if you need pin-like assurance, use Certificate Transparency monitoring (Expect-CT is also retired) rather than HPKP.
5. Last resort: relax pin enforcement for testingIn about:config set security.cert_pinning.enforcement_level to 1 (allow user-added/MITM roots) only to diagnose, never as a permanent setting. Set it back to 2 afterward. This is a debugging step, not a fix.