Live data from Hacker News

New Intermediate Certificates

letsencrypt.org

21–30 of 57 posts

Re: New Intermediate Certificates

#21
post #9

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.

Does this not simply mean they want people to pin "ISRG Root X1" instead of pinning "Let’s Encrypt R10" because they want the ability to rotate the latter? Although IMHO saying "don't pin this cert which expires in 2027, instead pin this cert which expires in 2035" is kinda a weird distinction to make as those are both too short.

I kinda wish pins by default became unpinned when the pinned cert expired.

Pinning an expired cert means you are 100% sure the software won't work.

Re: New Intermediate Certificates

#22

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.

I'd recommend pinning (your) keys because knowing cert SHAs ahead of time means you need the certificates themselves and in a nasty situation the CAs you relied on to issue those certs may be out of the picture, if you're pinning a key that's fine, CA #5 will cheerfully issue you a brand new certificate against the same key you were using with CA #1 before something went badly wrong - but with cert SHAs you have to bootstrap all of that fresh if it happens.

If you pin keys you can even pin a key you haven't and never plan to use, keeping the corresponding private key in the company safe as a hedge against something going badly wrong.

Re: New Intermediate Certificates

#23
post #9

Earlier quoted context omitted.

Does this not simply mean they want people to pin "ISRG Root X1" instead of pinning "Let’s Encrypt R10" because they want the ability to rotate the latter? Although IMHO saying "don't pin this cert which expires in 2027, instead pin this cert which expires in 2035" is kinda a weird distinction to make as those are both too short.

I kinda wish pins by default became unpinned when the pinned cert expired. Pinning an expired cert means you are 100% sure the software won't work.

What prevents the user from simply setting their clock forward?

(I do agree cert pinning is bad overall.)

Re: New Intermediate Certificates

#24

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 should be able to fully inspect all traffic originating from your device and reverse-engineer everything running on it, so any change that makes it harder for others to stop you from doing so is a good one.

Re: New Intermediate Certificates

#25

Earlier quoted context omitted.

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

I'd recommend pinning (your) keys because knowing cert SHAs ahead of time means you need the certificates themselves and in a nasty situation the CAs you relied on to issue those certs may be out of the picture, if you're pinning a key that's fine, CA #5 will cheerfully issue you a brand new certificate against the same key you were using with CA #1 before something went badly wrong - but with cert SHAs you have to b…

I completely disagree with you: reusing private keys is an enormous vulnerability. It's really important to rotate them.

It's very easy to avoid the pitfall you mentioned by having multiple valid certs with different expiry dates. You can easily use multiple CAs.

Done your way, a single leaked private key means your entire site is compromised indefinitely. That's unacceptable to me.

Re: New Intermediate Certificates

#26
post #18

Earlier quoted context omitted.

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.

> Please don't pin roots

So what would be the recommended way to protect against government MitM by using some obscure CA?

Re: New Intermediate Certificates

#27
post #18

Earlier quoted context omitted.

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

> Please don't pin roots So what would be the recommended way to protect against government MitM by using some obscure CA?

Currently CT logs:

https://certificate.transparency.dev/

Monitor CT for your domain name and if you find an "obscure CA" misissuing for your domain, report it! This may result in the obscure CA getting explicitly distrusted.

At some level this is not that great a solution, but it's really so much better than what we had 13-14 years ago.

Re: New Intermediate Certificates

#28
post #20
post #15

Earlier quoted context omitted.

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.

These three "levels" are the minimum that would work in the Web PKI and thus usual (for public services).

The reasoning goes like this. Roots represent entities you trust (or in most cases, which are trusted on your behalf by some entity that's thought about what constitutes trustworthiness e.g. your browser vendor, OS vendor, or maybe your workplace). Accordingly the root "certificates" aren't really certifying anything, the X.509 certificate format is a convenient structure to put this data in, but unlike most certificates they don't represent a certification of anything by anybody, in human terms these documents tend to say e.g. "We, ISRG claim that we are ISRG and we're a Certificate Authority and we're signing this document to say so". OK, but anybody could make such a self-signed document, there's no way to "authenticate" them, you must have decided to trust some of these claims (or as I said, your vendor probably did for you)

The private key corresponding to a root is therefore very precious, billions of people trust signatures made with this key so it's a huge deal if it's stolen/ compromised. As a result we require that these keys aren't online, they're typically manifested as a small physical object (a "hardware security module") locked in a safe, the idea is that the key itself cannot easily leave the object, so by locking it in a safe we've protected the key.

But since these roots can't be online, we can't make certificate with them online, so a simple system of the sort you might build at work, with a CA root that directly issues certificates, isn't possible. This is where the Intermediates come in.

A ceremony is conducted, with third party auditors and senior personnel from the CA to watch as the Root is used to sign one or (as here for ISRG) a handful of Intermediate certificates. These documents can usefully be verified because they were signed with the Root's keys, if we trust a Root we can check that indeed it has signed this Intermediate. The CA is also required to have a technology so that it can (in a reasonable amount of time) revoke an intermediate if for example it was compromised or stolen.

Unlike a root, the Intermediates can then be kept online (at ISRG only some are used this way, others are just backups against the unexpected) and used to sign End Entity (what you've called Server) certificates in real time shortly after they are ordered, once the appropriate checks have been carried out. HSMs are used again, but in this case they're attached to a server where the issuance software is running rather than locked in a safe.

This post is about ISRG using new Intermediates.

Re: New Intermediate Certificates

#29

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.

Pinning the site cert (or its key) is not great because it makes it very hard to rotate your certificate or key.

And you've got to be able to do that, in case your key is disclosed or possibly disclosed.

Pinning intermediates doesn't make a lot of sense; unless you have a deep relationship with the CA, they can and do change intermediates, and may not be able to issue from the old intermediate after the change. But, I've been involved in cert pinning where we had to pin intermediates, because that's the only viable information the client API returned we could use for pinning (and really, it was pinning based on the name of the intermediate --- any system trusted Root CA could have made an intermediate specifically to bypass our pinning, but it was the best we could do on that platform; of course, this was also the platform where we ended up with a wrong pin in our final build (platform owner shut down their app signing CA), which meant some ugly workarounds).

Pinning roots makes sense, but you need to pin more than one. And roots from more than one organization. And you need a succession plan. You can't use a new root on an existing hostname until all of the deployed clients with pins that could use that hostname have become irrelevant. If your all your trusted CAs stop issuing, you're pretty screwed.

You can sometimes use an in-house root, which makes continuity easier, but not if you need to share hostnames with browsers. You can't get an entity cert signed by two issuers, so there's no way to present a cert that is trusted by browsers and also signed by your root. You can present alternate paths for the issuers of your cert (and any intermediates) and if the x.509 libraries do the right thing, any valid path is accepted; but not all libraries do the right thing, and again, that doesn't apply to the entity cert.

Re: New Intermediate Certificates

#30
post #29

Earlier quoted context omitted.

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

Pinning the site cert (or its key) is not great because it makes it very hard to rotate your certificate or key. And you've got to be able to do that, in case your key is disclosed or possibly disclosed. Pinning intermediates doesn't make a lot of sense; unless you have a deep relationship with the CA, they can and do change intermediates, and may not be able to issue from the old intermediate after the change. But,…

Absolutely, I agree with everything you said.

Pinning is not an effective anti-reverse-engineer technique. It's just annoying obfuscation to anybody who knows what they're doing.

Post reply on HN