@Rich_Morin, the self-signed cert is a great solution if you control both the browser and the web server—in principle it’s actually better than a CA certificate because you’re not extending trust to a third party in order to communicate between your own machines.
The trouble is that if you use self-signed certs like this for an application you distribute to other people, they won’t really have a basis for deciding whether or not to add the certs in their own browsers, or at least the user interface for doing so is likely to be cumbersome (perhaps especially so for blind users, given the multiple layers of dialogs that may appear, as you were alluding to). In this scenario, “you” (as the application developer) don’t actually control the browser side, if you anticipate users using unmodified web browsers that came with their operating systems or that they downloaded from major browser vendors.
If you don’t want a self-signed cert but rather one that the browser will trust automatically, you need a public domain name and a way to
- let users discover this name on their LAN
- associate a locally-generated cryptographic key with a public name, and
- perform an interaction with a CA like Let’s Encrypt to cause issuance of a certificate that reflects that association
This is a pretty tricky set of requirements. It seems that Plex has found one way to satisfy them, but it wasn’t particularly easy. CAs should be quite strict about these requirements because the industry standards that govern them make clear that they have to actually verify control of the name, and that the name has to actually exist in the public DNS. That should now be true for all certificate issuance under all of the roots that browsers trust by default.