Inspired by this thread, browsers have long given grief over self-signed certificates, and it sounds like they’re getting worse. The best answer, of course, is to simply use a trusted cert, and Let’s Encrypt makes that pretty easy in most cases.
However, Let’s Encrypt isn’t the answer for everyone, and sometimes you need to work with a locally-generated cert. In that case, browser warnings can be minimized if, rather than using a true self-signed cert, the server uses a cert that’s signed by a local CA. The process works like this:
- Create local CA
- Import local CA cert into client computers
- Create server cert and sign with that CA
- ???
- Profit! As long as the client computers have the local CA cert in their trust store, they’ll trust the server cert signed with that CA.
All of this can be done at the command line using openssl
, but it’s a pain. There are scripts to simplify the process, and they help, but it’s still messy.
Including a web-based CA as part of the server-manager would greatly simplify this process. SME Server had a contrib for phpki, which has been forked on Github, but even that fork hasn’t seen a commit for three years. It looks like Certidude might be under more active development. pfSense includes this capability as well.
Edit: I guess another way to help with the problem noted in the linked thread would be to change the way that Neth auto-generates the cert. Rather than a simple self-signed cert, Neth could generate a CA, then a properly-formed (including the server’s FQDN as a SAN; Chrome at least will complain if this isn’t present) CSR for the server, then use the CA to sign that CSR. If you then expose that CA cert to be downloaded to client machines, you address this issue with very little GUI work.