3 ms·
Imagine the embedded device or mobile app connects to a https://api.example.com/.. https://api.example.com/... and so does their web app. They need to use a new
by ploxiln 10y ago
Imagine the embedded device or mobile app connects to a https://api.example.com/.. https://api.example.com/... and so does their web app. They need to use a new certificate for api.example.com, signed by a different CA root, because when Chrome tries to run the web app it won't trust the old certificate, nor a new cert signed by the old root. So they get a new cert signed by a different root so Chrome works, but then the embedded or mobile apps stop working.
In this case the story is more complicated - I think new certificates signed by existing Symantec CA roots would be trusted if their duration is 90 days or less. Historically, most CAs offered one, two, or three year duration. Presumably, the "big customers" would not accept the need to rotate their certificates for this purpose in less than 90 days, they need their 3 years because it takes over 90 days to get something through their bureaucracy. And presumably there are other things they can't do in 90 days, like update an embedded device configuration or firmware, or a mobile app.
Of course it depends on the particulars, but of course these "big customers" can't figure any particulars out in 90 days. But that's why Google proposed a slow sliding scale that would gradually reduce the max duration allowed over the course of a year, so random unknown stuff breaks more gradually throughout the year, not in one huge event like Symantec's blog post suggests.
- X-Cubed 10y agoAn 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 10y 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 10y 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 10y 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.