Skip to main content Logo

Quis custodiet ipsos custodes?
Home | About | All pages | Cluster Status | RSS Feed

Chrome 68 is depcrecating HPKP (HTTP Public Key Pinning)

Published: 12-06-2018 | Author: Remy van Elst | Text only version of this article

❗ This post is over five years old. It may no longer be up to date. Opinions may have changed.

HPKP removed from Chrome 68

In 2014 I published an article on HPKP, http public key pinning. It allows a site operator to send a public key in an http header, forcing the browser to only connect when that header is found. It was ment to redice the risk of a compromised certificate authority (since any CA can create a certificate for any website). Quite secure, but it was often wrongly configured, forgotten until certificates expired and there were some security issues like a false pin. Late 2017 Google announced that HPKP would be removed in Chrome 68 and that version is released now, so HPKP is no longer supported.

A certificate authority, like Comodo, because they are trusted by every browser, can issue a certificate for any site (so, But, the Netherlands Government (Staat der Nederlanden) or the Hong Kong Post office (China government) are trusted as well, thus are also able to issue a certificate for Now, there are all kinds of rules prohibiting that, but as I've shown by getting a certificate for a website I don't own, just as this guy for Microsoft, that it is prohibited by rules doesn't mean it is not technically possible. HPKP was meant to prevent that, by hardcoding a certificate for your site into a browser.

Recently I removed all Google Ads from this site due to their invasive tracking, as well as Google Analytics. Please, if you found this content useful, consider a small donation using any of the options below:

I'm developing an open source monitoring app called Leaf Node Monitoring, for windows, linux & android. Go check it out!

Consider sponsoring me on Github. It means the world to me if you show your appreciation and you'll help pay the server costs.

You can also sponsor me by getting a Digital Ocean VPS. With this referral link you'll get $100 credit for 60 days.

The Google development announcement can be found here, where they describe and discuss the intent to remove the feature from chrome.

ZDNET has an article going into more detail on what goes wrong when you forgot about Key Pinning when a certificate expires:

This scenario happened to Smashing Magazine when it was updating an expiring SSL certificate. It enabled HPKP and set the policy for 365 days. After rolling out new valid certificates, all browsers with the old HPKP policy couldn't visit the site. Also, the new HPKP policy did nothing to update the old one.

Replacement for HPKP, Expect-CT header?

Google wants the Expect-CT header to replace HPKP. This header allows web host operators to instruct user agents (browsers) to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. When configured in enforcement mode, user agents (UAs) will remember that hosts expect SCTs and will refuse connections that do not conform to the UAs Certificate Transparency policy.

There is no automatic detection of invalid certificates or rouge certificates. As far as I understand you must configure and monitor the CT logs yourself to find rouge certificates. I use this site and get emails when a certificate for a certain domain is found.

This page has a little bit more on the replacement:

By combining Expect-CT with active monitoring for relevant domains, which a growing number of CAs and third-parties now provide, site operators can proactively detect misissuance in a way that HPKP does not achieve, while also reducing the risk of misconfiguration and avoiding the risk of hostile pinning, (Chris) Palmer said.

Google's Certificate Transparency project is an open framework for monitoring and auditing SSL certificates. The goal behind the project is detection of mis- issued/malicious certificates and identification of rogue Certificate Authorities.

Read more about the Expect-CT header in the RFC. To read more about Certificate Transparency, check the site here.

As I'm unsure on how the actual header works, for example what defines when an error is given, I'm not recommending it yet, until I've done more research.

Removing HPKP on

I removed HPKP about half a year ago from the servers hosting First by setting the max-age portion of the header to 0, that tells existing browsers that have HPKP cached to invalidate the known time. Otherwise, when changing the certificate, the browser would still have old information thus giving errors.

After 4 months, I actually changed the webserver configuration to remove the HPKP headers:

$ curl -I
HTTP/2 200 
server: nginx/1.10.3 (Ubuntu)
date: Tue, 12 Jun 2018 09:39:01 GMT
content-type: text/html
content-length: 376
last-modified: Tue, 05 May 2015 17:21:00 GMT
etag: "5548fbfc-178"
expires: Thu, 12 Jul 2018 09:39:01 GMT
cache-control: max-age=2592000
strict-transport-security: max-age=63072000; includeSubdomains; preload
referrer-policy: origin
x-xss-protection: 1; mode=block
coffee: Black
tea: Earl-Gray; Hot
x-frame-options: DENY
x-content-type-options: nosniff
x-ua-compatible: IE=Edge,chrome=1
cache-control: public
accept-ranges: bytes

As you can see, no Public-Key-Pins header. If you have HPKP and want to remove it, make sure to first set the time to 0 and let that run for a few months.

Tags: apache , blog , expect-ct , hpkp , https , lighttpd , nginx , security , ssl , tls