Live data from Hacker News

New Intermediate Certificates

letsencrypt.org

11–20 of 57 posts

Re: New Intermediate Certificates

#11

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.

You must pin your own key, not certbot key.

Re: New Intermediate Certificates

#12

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.

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)

exactly right.

Re: New Intermediate Certificates

#13
post #5

Earlier 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".

Also, some companies[1] have been caught being naughty and installing CA certs which allowed third parties to MiTM local connections. This was a major issue and, at least in my case, what drived many to pin certs at the time.

[1] https://en.wikipedia.org/wiki/Superfish#Lenovo_security_inci...

Re: New Intermediate Certificates

#14

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.

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.

Re: New Intermediate Certificates

#15

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.

You must pin your own key, not certbot key.

What does this mean?

Re: New Intermediate Certificates

#16

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.

> Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer

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

#17
post #14

Earlier 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.

Let's Encrypt, and WebPKI in general is meant for public consumption of certificates.

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

#18

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.

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…

> Or if they want to pin a root public key to ensure some other CA doesn't issue a MITM certificate, go for it

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.

Re: New Intermediate Certificates

#19
post #15

Earlier quoted context omitted.

You must pin your own key, not certbot key.

What does this mean?

I believe they are using "certbot" to mean "Let's Encrypt", in which case their advice is sound -- if you truly have to pin a key, pin your own end-entity cert's key, not the CA's key.

Re: New Intermediate Certificates

#20
post #15

Earlier quoted context omitted.

You must pin your own key, not certbot key.

What does this mean?

I'm assuming out of the 3 levels that are on most certificates

Root / Intermediate / Server, you only pin server certificates and not the levels above them.

Post reply on HN