3 ms·
An easier way around this sort of issue is to change their web app to use a different domain, and only put the new certificate from a different CA on that domai
by X-Cubed 9y ago
An easier way around this sort of issue is to change their web app to use a different domain, and only put the new certificate from a different CA on that domain. It's not necessary to update every device.
Embedded devices => https://api.example.com https://api.example.com (Symantec cert)
Browsers => https://new-api.example.com https://new-api.example.com (New trusted cert)
Another approach is that if the devices are old enough they're probably using a deprecated version of TLS, so the existing https://api.example.com https://api.example.com server could choose which certificate to issue based on the version of TLS offered by the client.
- toast0 9y agoYou have to have planned for this (or be lucky) though. Some people just put their api on www.example.com; assuming you have clients in the field which have pinned BIG CA, and you've got HSTS preloaded (because you're forward thinking). Unless you can detect Chrome N+1 from your existing clients during the TLS handshake, you have to pick between browsers or existing clients. If Chrome ships this at the same time as re-enabling TLS 1.3 support, that would be a decent way to target, since presumably very few of your distributed clients are using TLS 1.3.
- majewsky 9y agoI know it's not going to help companies which pinned Symantec, but that's exactly why every serious guide to HPKP will have you pin two separate CAs.
- ploxiln 9y agoTrue, but you know how it is ... the management of these companies would prefer to do nothing if it is possible. They'll put most of their efforts into that strategy.