Featured Articles

Continuous Documentation: Hosting Read the Docs on GitHub Pages (2/2)
WordPress Multisite on the Darknet (Mercator .onion alias)
Detecting (Malicious) Unicode in GitHub PRs
Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot)
Introducing BusKill: A Kill Cord for your Laptop
Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)
Hardening Guide for phpList
WordPress Profiling with XHProf (Debugging & Optimizing Speed)
Crowdfunding on Crowd Supply (Review of my experience)
previous arrow
next arrow

HPKP Best Practices for Let’s Encrypt

This post describes how to generate a few backup public key hashes to add to your HTTP Public Key Pinning (HPKP) config that might save you from bricking your domain if Let’s Encrypt ever gets untrusted like StartCom did.

If you have a healthy distrust of the X.509 PKI trust model, then you’ve probably heard of HPKP (and probably also HSTS & CAA). Website certificate pinning was a trend first started by google, who hard-coded a pin of their certificates in their Chrome browser. Eventually, google helped build a more standardized pinning method under RFC 7469. And today, it’s supported by Chrome, Firefox, and Opera.

Pinning is a great TOFU improvement to https, but–if misconfigured–you could “brick” your domain–making it so that your client’s browsers will refuse to let them access your site for months or years (interestingly, this has also caused some security experts to think of how HPKP could be abused in ransom-ware). Therefore, it’s a good idea to follow a few HPKP Best Practices.

Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


. . . → Read More: HPKP Best Practices for Let’s Encrypt