nickf

CAs are gonna start rotating more frequently soon, and you may even see randomisation. Pinning to public certs is a real no-no.

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 sites/endpoints.

Is the certificate you use on your website any different to that on google.com? Does/could a browser know this and act differently?

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.

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.

It'll be tough when ICAs rotate every 5/6 months and may even randomise.

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.

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.

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't. Roots are going to start changing every couple of years. Issuing/intermediate CAs will be down to 6 months, and may even need to be randomised so when you request a new cert, there's no guarantee it'll be from the same CA as before.

Don't pin to certs you don't control.

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 planning a smaller, lower-capacity charger!

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!

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. However, nothing has had the feature set I wanted - bluetooth, auracast, Apple MFI and being CIC.

Oticon just announced/released their 'Zeal' product - a non-custom CIC, with seemingly all the bells and whistles, including bluetooth. Planning to try them soon.

I have tried a few aids before (Starkey and some older Phonak) and I do really like the Oticon 'sound'. They work for me, but of course YMMV. I think many aid manufacturers (many of them the same company - WDH!) do 60 day trials. Worth a shot.

My only dislike is the new fad, particularly of Oticon, of stopping disposable batteries and only going rechargeable. Disposable zinc-air cells have great life (I'd get a week on the Opns at least, with a few hours streaming per day). I travel for work a lot, so carrying a couple of tiny 312's in my wallet or keychain was perfect. The Zeal look to have what Oticon think is a 'compact' charger - but it ain't small. My kingdom for a charger the size of the AirPods Pro case...

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 the rules. Even Azure’s $2400a month managed HSM isn’t acceptable, as they don’t run them in FIPS mode.

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.

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 practically be automated, it near-certainly doesn't need to have a public cert on it.

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 resources and my own time to investigate.

None of this will happen. Saying this as the named endorser for SC-081.

Not just browsers, CAs voted in favour too.

…and I didn’t even have to play the SC-081 sponsor card either ;)

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 certificates, quickly, is a bigger reason. 1k -> 2k RSA took too long. SHA1 -> SHA2 took waaaaay too long. Changing anything about the webPKI takes too long unless everyone is on short lifetimes. The post-quantum bogeyman looms, too. Heartbleed and unforced CA errors become way less of a problem is everyone is forced to rotate monthly.

Sure: https://learn.microsoft.com/en-us/security/trusted-root/prog...

3.D.3 covers the details about EV CS.

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.

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 billions of relying parties, so it's expected.

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.

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-party you have nothing to do with decides that some part of the hierarchy needs to change.

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, but I appreciate many people do and it's just been 'the way' for many years. This is why I think it's going to hurt if folks don't realise soon and start to plan.

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.

That isn’t at all true.

Because they operate in a regulated, security industry where changes happen - sometimes beyond their control?

Then the CA goes away, like Entrust. Huge problems. I speak (sadly) from experience.