Suppose my Public-Key-Pins max-age is 60 days. When can I deploy a new cert? 60 days from now? But what about browsers who first connect to my site between now and 60 days from now?

This site says:

When GitHub [who uses HPKP] wants to replace its TLS certificate, the new certificate must be signed by either DigiCert or Symantec – otherwise, none of the key hashes in the new certificate chain would match the existing HPKP policy, and its users would be blocked from accessing the site.

So, I can't deploy a new cert signed by a different CA (e.g., Let's Encrypt's) than that of the one I originally pinned (e.g., Verisign)?

Is this why it's recommended to pin a backup cert from a different CA?
cf. p. 315 of Ivan Ristić's Bulletproof SSL and TLS (2014)

2 Answers 2

  1. You should ALWAYS have two (or more) pins in your headers: one for your current certificate, and one (or more) for the backup certificate(s) (held separately from current one, best offline).
  2. If your current certificate was not compromised, you don't need to touch the pins or issue new certificate - you can simply renew existing certificate (ask CA to issue new CRT using the same CSR as previously).
  3. If your system was compromised you can switch to backup certificate you've had pinned (for at least max-age) ANY TIME - UA will accept it, because the pin is valid (was previously present in headers).
  4. You can ask any CA that is trusted by the client to sign your CSR (current or backup).
  5. If you want to add new pin you need to wait max-age period (usually 60 days) before using certificate that matches it, to eliminate risk of UA rejecting connection. See scenario below and note the differences between clients X and Y:
  • day 1: you configure pin A + crt A, set max-age to 60 days,
  • day 2: client X connects and learns A is safe for 60 days,
  • day 3: client Y connects and learns A is safe for 60 days,
  • day 20: you add pin B to the headers,
  • day 21: client X connects (he trusts A) and learns both A and B are safe for 60 days,
  • day 40: you switch to crt B,
  • day 41: client X connects (he trusts both A and B),
  • day 42: client Y rejects the connection - he didn't manage to learn new pin from trusted A (like client X did), so he will reject everything except A until day 63.

If still in doubt, see section 2.6. Validating Pinned Connections and Appendix B. Deployment Guidance in RFC 7469.


What you have to do is add a SHA-256 hashes of the new cert and chain, in addition to the ones already there. Then in 60 days, you can remove the SHA-256 hashes of the old certs.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .