Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer. It prevents you from installing your own cert in the system's trust store and then using that to man-in-the-middle the app's communication with its backend.
New Intermediate Certificates
11–20 of 57 posts
Re: New Intermediate Certificates
#12Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer. It prevents you from installing your own cert in the system's trust store and then using that to man-in-the-middle the app's communication with its backend.
It's important to note that this is preventing pinning /intermediates/ which are re-issued about annually. It is usually a mistake to do that. It is possible that due to a large-scale incident, we'd have to revoke an intermediate immediately and switch to a backup. While we don't recommend key pinning, there's nothing to prevent pinning Let's Encrypt's root CAs. (I work for Let's Encrypt)
Re: New Intermediate Certificates
#13Earlier quoted context omitted.
They're mainly trying to issue certs for public facing websites. If your service is in a position where someone can install an alternative root CA on your webserver, you're already pwned!
The threat model isn't "someone will install stuff on our servers". The threat model is "some user will look at the network traffic and see all the personal data we're hoovering from their phone". Sometimes also "some user will look at the network traffic and notice that we have 0 server-side security".
[1] https://en.wikipedia.org/wiki/Superfish#Lenovo_security_inci...
Re: New Intermediate Certificates
#14Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer. It prevents you from installing your own cert in the system's trust store and then using that to man-in-the-middle the app's communication with its backend.
Maybe get a proper certificate designed for such things instead of using what amounts to a corporate-funded public service.
Re: New Intermediate Certificates
#15Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer. It prevents you from installing your own cert in the system's trust store and then using that to man-in-the-middle the app's communication with its backend.
You must pin your own key, not certbot key.
Re: New Intermediate Certificates
#16Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer. It prevents you from installing your own cert in the system's trust store and then using that to man-in-the-middle the app's communication with its backend.
I don't think you'd typically pin intermediates if that was your goal: you'd pin the site cert you control. It could be as simple as a whitelist of certificate SHAs.
Re: New Intermediate Certificates
#17Earlier quoted context omitted.
Maybe get a proper certificate designed for such things instead of using what amounts to a corporate-funded public service.
What is improper about them? Works for 100% of my use case, well known, trusted, compatible.
I think what this means is, if you're needing some stricter limitations on these, use private PKI within your own devices. E.g. for Machine to Machine comms.
Re: New Intermediate Certificates
#18Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer. It prevents you from installing your own cert in the system's trust store and then using that to man-in-the-middle the app's communication with its backend.
It's specifically to discourage intermediate key pinning. If folks want to pin their own end-entity public key (and always re-use the same key when renewing their cert), go for it -- dealing with compromise of their own key is their own problem to solve. Or if they want to pin a root public key to ensure some other CA doesn't issue a MITM certificate, go for it (although that doesn't prevent a bad actor from getting…
Please don't pin roots, as that makes it harder to distrust CAs, reducing the agility of the WebPKI. See the Symantec distrust for a painful example.
Chrome and Firefox will be introducing term limits on roots in the near future, which will hopefully help to discourage this harmful practice.