nickf

8 ms·

31.
by nickf 10mo ago
CAs are gonna start rotating more frequently soon, and you may even see randomisation. Pinning to public certs is a real no-no.
32.
by nickf 10mo ago
I still think 'don't pin' is the best advice, but absolutely it should never be done to public CAs. I agree with your point about different endpoints, but maybe one endpoint for pinned apps, separate to your browser-based sit
33.
by nickf 10mo ago
Is the certificate you use on your website any different to that on google.com? Does/could a browser know this and act differently?
34.
by nickf 10mo ago
You can, but it’s still dangerous. You don’t have control over if those certs are revoked or keys blocklisted. It’s best to simply not use public certs for pinning, if you really must do it.
35.
by nickf 10mo ago
A certificate is a binding of a cryptographic key, along with an attestation of control of a DNS record(s) at a point in time. DNS changes frequently. The attestation needs to be refreshed much more frequently to ensure accuracy.
36.
by nickf 10mo ago
It'll be tough when ICAs rotate every 5/6 months and may even randomise.
37.
by nickf 10mo ago
I'd say two big reasons: 1) A lot of people/enterprises/companies/systems are not ready. They're simply not automated or even close to it. 2) Clock skew.
38.
by nickf 10mo ago
I would strongly suggest that these certs have no reason to be from a public CA and thus you can (and should) move them to a private CA where these rules don't apply.
39.
by nickf 10mo ago
Don't. Don't pin to public certificates. You're binding your app to third-party infrastructure beyond your control. Things change, and often. Note that pinning to a root or intermediate seems 'sensible' - but it isn
40.
by nickf 11mo ago
That's interesting - thank you! Can I ask where you saw the (limited) information? Hearingtracker forum seems devoid of info on the Zeal and accessories (likely due to the limited fitting range) - but I'd be curious if Oticon are
41.
by nickf 11mo ago
How are you finding the Zeal's charger? As I said in another comment - I'm baffled Oticon can't make a charging case the size of the AirPods Pro or similar. The Zeal charger doesn't seem exactly...pocketable!
42.
by nickf 11mo ago
Weird - in an incredibly similar situation and my RICs are overdue an upgrade (Oticon Opn 3). I've been keeping an eye on developments for some time, and I've been looking for something ideally CIC, though I do like the RIC Opns.
43.
by nickf 11mo ago
Azure Key Vault - even in the ‘premium’ HSM flavour can’t actually prove the HSM exists or is used, which doesn’t satisfy the requirements the CA has. In theory, it shouldn’t work - but some CAs choose to ignore the letter and the spirit of
44.
by nickf 1y ago
It's likely to get worse as CAs rotate roots more frequently. Cross-signing will work for a time (provided you correctly install) but at some point, older devices will drop out of support and that'll be it.
45.
by nickf 1y ago
If there are systems that are that resistant to automation, the question should be 'does this system need a publicly-trusted server certificate, the same as a blog about cats or a Shopify shop?'. The answer is no. If it can't
46.
by nickf 1y ago
It will not be reversed, of that I'm certain. Attributing deaths, even indirectly, to the change in duration of TLS server certificates for the webPKI is incredibly extreme. If you have any real evidence or data to share, I have resour
47.
by nickf 1y ago
None of this will happen. Saying this as the named endorser for SC-081.
48.
by nickf 1y ago
Not just browsers, CAs voted in favour too.
49.
by nickf 1y ago
…and I didn’t even have to play the SC-081 sponsor card either ;)
50.
by nickf 1y ago
Not quite that simple, no. It's a good reason, and while CRL and OCSP don't really work well - CRLite/OneCRL, CRLsets and valid all go some way to making revocation reasonably effective. Having an effective way to rotate all
51.
by nickf 1y ago
Sure: https://learn.microsoft.com/en-us/security/trusted-root/prog... 3.D.3 covers the details about EV CS.
52.
by nickf 1y ago
ZeroSSL is owned by Identrust, but the infra is operated by another CA. Also Microsoft killed EV codesigning early last year - not stopping it working, just making it identical to ‘normal’ codesigning certs.
53.
by nickf 1y ago
It wasn't just the browsers. Some CAs supported this for a long time, and even directly endorsed the ballot. You're not wrong about the browsers having 'the power', but then again - they are the representatives of bill
54.
by nickf 1y ago
It's a Chrome policy: https://googlechrome.github.io/chromerootprogram/ 3.2.1 (item 2). In case it helps - am the CTO of a large CA, so (un)fortunately aware of what's happening and when.
55.
by nickf 1y ago
I think if you're going to pin, pin to something you control. If it's an API endpoint, you can use a private CA and have the app trust your root, and pin to that. Same end result, but you're not going to be stuck if a third-p
56.
by nickf 1y ago
It applies to leaf certs too. (Full disclosure - I work in the industry, so know this well). After June 15th, 2026 - no leaf certs with serverAuth and clientAuth. Mind you, client authentication with public certificates is a bad idea anyway
57.
by nickf 1y ago
mTLS is going to be a problem soon, arguably bigger than this lifetime reduction. Most server certs today have clientAuth EKU and can be used for mTLS. That stops next year.
58.
by nickf 1y ago
That isn’t at all true.
59.
by nickf 1y ago
Because they operate in a regulated, security industry where changes happen - sometimes beyond their control?
60.
by nickf 1y ago
Then the CA goes away, like Entrust. Huge problems. I speak (sadly) from experience.

More ›