Hacker Neue

Preferences
captn3m0 parent
This is great news. This would blow a hole in two interesting places where leaf-level certificate pinning is relied upon:

1. mobile apps.

2. enterprise APIs. I dealt with lots of companies that would pin the certs without informing us, and then complain when we'd rotate the cert. A 47-day window would force them to rotate their pins automatically, making it even worse of a security theater. Or hopefully, they switch rightly to CAA.

bearjaws
Giving me PTSD for working in healthcare.

Health Systems love pinning certs, and we use an ALB with 90 day certs, they were always furious.

Every time I was like "we can't change it", and "you do trust the CA right?", absolute security theatre.

DiggyJohnson
Do you (or anyone) recommend any text based resources laying out the state of enterprise TLS management in 2025?

It’s become a big part of my work and I’ve always just had a surface knowledge to get me by. Assume I work in a very large finance or defense firm.

grishka
Isn't it usually the server's public key that's pinned? The key pair isn't regenerated when you renew the certificate.
toast0
Typical guidance is to pin the CA or intermediate, because in case of a key compromise, you're going to need to generate a new key.

You should really generate a new key for each certificate, in case the old key is compromised and you don't know about it.

What would really be nice, but is unlikely to happen would be if you could get a constrained CA certificate issued for your domain and pin that, then issue your own short term certificates from there. But if those are wide spread, they'd need to be short dated too, so you'd need to either pin the real CA or the public key and we're back to where we were.

nickf
I've said it up-thread, but never ever never never pin to anything public. Don't do it. It's bad. You, and even the CA have no control over the certificates and cannot rely on them remaining in any way constant. Don't do it. If you must pin, pin to private CAs you control. Otherwise, don't do it. Seriously. Don't.
toast0
There's not really a better option if you need your urls to work with public browsers and also an app you control. You can't use a private CA for those urls, because the public browsers won't accept it; you need to include a public CA in your app so you don't have to rely on the user's device having a reasonable trust store. Including all the CAs you're never going to use is silly, so picking a few makes sense.
richardwhiuk
You don't need both of those things. Give your app a different url.
ori_b
Why should I trust a CA that has no control over the certificate chains?
nickf
Because they operate in a regulated, security industry where changes happen - sometimes beyond their control?
einsteinx2
Repeating it doesn’t make it any more true. Cert providers publish their root certs, you pin those root certs, zero problems.
nickf
Then the CA goes away, like Entrust. Huge problems. I speak (sadly) from experience.
Plasmoid
They rotate those often enough.
1a527dd5
Dealing with enterprise is going to be fun, we work with a lot of car companies around the world. A good chunk of them love to whitelist by thumbprint. That is going to be fun for them.

This item has no comments currently.