3 ms·

I find it hard to believe you can't imagine any valid scenario where at least one of those scenarios shouldn't be using pubic CAs. I've got personal experience

I find it hard to believe you can't imagine any valid scenario where at least one of those scenarios shouldn't be using pubic CAs. I've got personal experience with the first two (embedded devices and mobile apps) having pinned certificates (or limited sets of supported CAs) There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of supported CAs. (e: Also, don't forget the tons of 'smart' phones out there running ancient versions of whatever) If you're someone who supports applications that run on those, then your choices for what CAs you offer on your API/Media/etc endpoints is extremely limited. Some of these decisions were made more than a decade ago, and migrating off those is going to take another decade (i.e as old hardware dies).

Pyxl101 9y ago
> There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of supported CAs. What exactly is the issue? If an embedded device trusts Symantec CA, then connections from the device to its central servers will continue working without interruption. In this example, the device trusts the Symantec CA, and the server presents a certificate signed by the Symantec CA. Everything's hunky-dory. What's the problem?
- will_hughes 9y ago
  Clients have no way to indicate what CAs they trust, so my infrastructure has to just present a certificate and say "Here I am" So now if Google go ahead and distrust Symantec CAs, I need to duplicate that infrstructure (or at least the configuration at load balancers, etc) - this leads to all sorts of complexity.
  - Pyxl101 9y ago
    That certificate can be signed by whatever CAs you wish to use, including Symantec and others.
- peeters 9y ago
  You have api.mysite.com which serves both an embedded device as well as your site. To allow the site to be viewed in Chrome, you need a new cert for your API, and so you now have to either update your site to point to a different endpoint, or update your devices to accept the new cert. Sure it might be easier to do the former for some companies, but either way there's certainly a cost.
  - Pyxl101 9y ago
    Sure. If api.mysite.com supports both web browsers and embedded devices, then you can issue a certificate for it your publicly-trusted CA of choice, and then can cross-sign that certificate with the Symantec CA.
revelation 9y ago
If you control the client and you control the servers it needs to communicate with, then you should probably not be using the public CA system. Well yes if your "embedded" device has a user-facing webbrowser you will need the public CA system, but then I'd wager if you shipped such a device and don't have ongoing updates you have much much bigger problems than an outdated set of root CAs. But there is zero reason for your mobile app communicating exclusively with your API endpoint to use the public CA system. You're paying for a less secure system with all the same hassles.

Pyxl101 9y ago

> There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of supported CAs. What exactly is the issue? If an embedded device trusts Symantec CA, then connections from the device to its central servers will continue working without interruption. In this example, the device trusts the Symantec CA, and the server presents a certificate signed by the Symantec CA. Everything's hunky-dory. What's the problem?

will_hughes 9y ago
Clients have no way to indicate what CAs they trust, so my infrastructure has to just present a certificate and say "Here I am" So now if Google go ahead and distrust Symantec CAs, I need to duplicate that infrstructure (or at least the configuration at load balancers, etc) - this leads to all sorts of complexity.
- Pyxl101 9y ago
  That certificate can be signed by whatever CAs you wish to use, including Symantec and others.
peeters 9y ago
You have api.mysite.com which serves both an embedded device as well as your site. To allow the site to be viewed in Chrome, you need a new cert for your API, and so you now have to either update your site to point to a different endpoint, or update your devices to accept the new cert. Sure it might be easier to do the former for some companies, but either way there's certainly a cost.
- Pyxl101 9y ago
  Sure. If api.mysite.com supports both web browsers and embedded devices, then you can issue a certificate for it your publicly-trusted CA of choice, and then can cross-sign that certificate with the Symantec CA.

revelation 9y ago

If you control the client and you control the servers it needs to communicate with, then you should probably not be using the public CA system. Well yes if your "embedded" device has a user-facing webbrowser you will need the public CA system, but then I'd wager if you shipped such a device and don't have ongoing updates you have much much bigger problems than an outdated set of root CAs. But there is zero reason for your mobile app communicating exclusively with your API endpoint to use the public CA system. You're paying for a less secure system with all the same hassles.