| ▲ | captn3m0 4 days 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. |
|
| ▲ | bearjaws 3 days ago | parent | next [-] |
| 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 4 days ago | parent | prev | next [-] |
| 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 4 days ago | parent | prev | next [-] |
| Isn't it usually the server's public key that's pinned? The key pair isn't regenerated when you renew the certificate. |
| |
| ▲ | toast0 4 days ago | parent [-] | | 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 4 days ago | parent [-] | | 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 3 days ago | parent | next [-] | | 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. | | | |
| ▲ | ori_b 3 days ago | parent | prev | next [-] | | Why should I trust a CA that has no control over the certificate chains? | | |
| ▲ | nickf 3 days ago | parent [-] | | Because they operate in a regulated, security industry where changes happen - sometimes beyond their control? |
| |
| ▲ | einsteinx2 3 days ago | parent | prev [-] | | Repeating it doesn’t make it any more true. Cert providers publish their root certs, you pin those root certs, zero problems. | | |
| ▲ | nickf 3 days ago | parent | next [-] | | Then the CA goes away, like Entrust. Huge problems. I speak (sadly) from experience. | |
| ▲ | Plasmoid 3 days ago | parent | prev [-] | | They rotate those often enough. |
|
|
|
|
|
| ▲ | 1a527dd5 3 days ago | parent | prev [-] |
| 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. |
