> The only thing that can confuse people is the certificate security system, where a friend of mine complained they couldn't connect, but it was just a "Do you want to accept this certificate" popup that was in the way.
Is this because the server didn't have a certificate from a trusted CA? In which case the fix is that Mumble could integrate ACME to get certificates from Let's Encrypt or whoever
Or is the situation that Mumble doesn't integrate the WebPKI and so it expects the user to make trust decisions for each certificate, which is pretty hostile ?
> That is an issue of general technical illiteracy
I guess that's kind of true, but I'm not sure I should need to understand the correct range of manifold pressure for the engine in a motor vehicle to operate it, for example. "Just do what is obviously the correct thing" seems reasonable in both cases.
> Is this because the server didn't have a certificate from a trusted CA? In which case the fix is that Mumble could integrate ACME to get certificates from Let's Encrypt or whoever
In my experience, a lot of people who set up a Mumble instance don't have an actual domain name, so they can't get a CA certificate, only self-signed. Most people do set up at least a dynamic DNS of some sort. But as long as you're doing that, you might as well pay the extra $10/year to get a domain, in my opinion.
> Most people do set up at least a dynamic DNS of some sort.
Most dynamic DNS providers got a default shared domain name added to the Public Suffice List e.g. dyndns.example might be on the PSL and then you can have your server be named etskinner.dyndns.example when you call their dynamic DNS service.
In this case Let's Encrypt is quite happy to give you a certificate for etskinner.dyndns.example since you control it. Unlike a web server, the Mumble server can't trivially bake the elements needed for this into its functionality, but it shouldn't have a hard time in the two easy cases:
1. There is no web server for this DNS name, spin up a temporary web server, answer Let's Encrypt queries until they give you a certificate, then spin it back down
2. This machine is the web server, so, have the user tell us how to pass http-01 challenges on that existing web server.
That doesn't cover every corner case, and it is one more notch on your "Duplicate certificate count" rate limit if you do have an HTTPS web site on the same name from Let's Encrypt, but I'd guess 95% of users who have a working Murmur and either a Dynamic DNS setup or their own "proper" DNS setup would get a working system and a further fraction would have some trivial problem they'd fix and after that it would Just Work™.
Is this because the server didn't have a certificate from a trusted CA? In which case the fix is that Mumble could integrate ACME to get certificates from Let's Encrypt or whoever
Or is the situation that Mumble doesn't integrate the WebPKI and so it expects the user to make trust decisions for each certificate, which is pretty hostile ?
> That is an issue of general technical illiteracy
I guess that's kind of true, but I'm not sure I should need to understand the correct range of manifold pressure for the engine in a motor vehicle to operate it, for example. "Just do what is obviously the correct thing" seems reasonable in both cases.