For a test, I pinned both LE CAs and my server key. However, upon changing my server key so that it falls outside the set of pinned keys, Firefox still doesn’t complain. This is backed by the spec which only mentions that the set of pinned keys and keys in the chain must intersect, but doesn’t require the intersection to be permanent.
This raises a question for me about pinning both the CA and the server key, which I see very often but seems completely pointless to me.
If I pin the CA, then anyone who can present a valid cert from that CA passes the HPKP check, regardless of my pinned server key. So if you pin the CA, you shouldn’t pin the sever key, and subsequently, if you pin the server key, it should be the only key in the chain that is pinned (set aside backup keys).
Don’t have experience with HPKP so I only have theoretical knowledge of the implementation.
As I understand it, it’s sufficient for a validation that any key listed in the header can be traced to the key being used, so it’s not used for indicating which CA must be the signatory of a certain server key. The point of HPKP is to pin the CAs one of which must be present in the trust chain, otherwise it’ll be rejected. The recommendation is to pin two or three CAs in case the current one goes out of business or has their private key comprimised.
I don’t know how you conducted your test so I don’t know why Firefox was silent in your case.
Why FF was silent is explained by what you just confirmed. Since any matching key in the pin list is enough to satisfy pinning, pinning the server key in addition to pinning the CA is kinda pointless and only protects against DoSing yourself in case LE becomes unavailable as a CA.
Hi the “securest” why to use HPKP is to pin you current key and an backup key that is offline for desaster recovery.
And reuse the current key if you renew, That disables any CA to issue malicious certificat even with an NSL request.
but for users that didnt visit the site even NSL’ed certs would work. If the DNSSecroot was outside the US it would be a lot more helpful, esoecially because you can easily change TLSA records.
TLSA record you can only change if your registrar support it.
It is the same problem as with CAA record, to use it you need an DNS server that support it and
also an frontend -
But even without both you can ask people to verify the certificate they see the first time and later it is pinned.
DNS, not registrar. the registar has to play fine with DNSSec (and in case of gTLDs when the registry does it then the registrar must do it, greetings from ICANN), yeah but if you can set up a TLSA iin the first place, then you can change it just as easily while you are pretty much F'ed up when you lose your HPKP keys since the user cannot override the error and you can do nothing against it until it runs out.
[quote=“My1, post:5, topic:8626”]
but for users that didnt visit the site even NSL’ed certs would work.
[/quote]Maybe consider HPKP preloading then? For Chrome you can file a bug. Firefox should have a similar procedure.
Hi, you only have to add preload to hsts header and add your domain via https://hstspreload.appspot.com/
this side is primary for chrome but firefox synchronize with the chrome list. So than you get with one entry
"Chrome", “Edge”, “Firefox” and "IE"
Chrome dev only takes few days. But for the prod version it can take months
