A common complaint when dealing with embedded devices is, sure we'd love to use SSL for everything on these, but how are we going to deploy certificates to all of them? This was also the excuse Plex cited when they removed SSL support from their software.
Well, it's back! And apparently, they worked something out with DigiCert to automatically deploy certs to all the things. And they didn't just flip the SSL switch in their runtime of choice, they asked someone who knows this stuff how to get the protocol right.
I still have concerns. We don't really have an industry consensus yet on rules for this kind of SSL cert. Here's what it seems they're doing:
- They bought the domain plex.direct. (It looks fake, but .direct is actually delegated thanks to the new generic TLD
- Every Plex user (or Plex device? unclear) gets a private namespace *.somehexstring.plex.direct
- A wildcard cert is printed off by DigiCert for that namespace
- Dynamic A/AAAA records are added in the plex.direct zone, pointing to the known IPs of the Plex devices
So, for most clients, connecting to https:// and the dynamic endpoint domain name will just work - even when Plex does not control the client-side SSL implementation. That's huge. But, they are printing certs for devices they don't control, and they're pointing domain names at addresses they don't control - not usually encouraged activities.
To be clear, I am super totally 100% on board for them doing this, generally. We need
a template for how to get SSL right for this kind of device usage scenario. There's going to be some debate about the finer details of this, but it's a debate we need and that hasn't really been happening until now. Great job +Plex
.+Harald Wagener +Adam Langley +Daniel Dulay
- this may be relevant to your interests.