5 ms·
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.
by captn3m0 2y ago
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.
- grishka 2y agoIsn't it usually the server's public key that's pinned? The key pair isn't regenerated when you renew the certificate.
- toast0 2y agoTypical 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 2y agoI'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.
- einsteinx2 2y agoRepeating it doesn’t make it any more true. Cert providers publish their root certs, you pin those root certs, zero problems.
- toast0 2y agoThere'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 2y agoYou don't need both of those things. Give your app a different url.
- ori_b 2y agoWhy should I trust a CA that has no control over the certificate chains?
- nickf 2y agoBecause they operate in a regulated, security industry where changes happen - sometimes beyond their control?
- DiggyJohnson 2y agoDo 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.
- bearjaws 2y agoGiving 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.
- 1a527dd5 2y agoDealing 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.