Implement Certificate Authority in Neth?

v7
(Dan) #1

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.

(Davide Principi) #2

A certification authority should be a part of the IPA in RHEL 8. Free-IPA should integrate also with MS Active Directory too. Maybe too early to think about it, but Free-IPA could be an official account provider in NS8 :upside_down_face:

+1 for any enhancement/fix to default NS certificate generation process

(Dan) #3

It’s interesting how writing something out gets you thinking, and often takes you in a different direction that you’d expected. My post was with the intent/hope that NS would implement some sort of web-based CA in the server-manager–big GUI job. I still think there would be significant value there, but my edit suggests a different route–not as much of a value-add for the user, perhaps, but very little GUI work involved in this one:

  • On install, create a root CA cert/key. Put the files somewhere that’s covered by backup/restore so that when you restore from backup, the server will be using the same CA as before.
  • Expose that CA cert so that it can easily be installed on client machines. At a minimum, expose it to the server admin (a link on the Server Certificates page would do, I’d think). Perhaps expose it directly to users, though this might just be a matter of the web designer including a link to it somewhere.
  • Admins or users will then need to install that CA cert on the client machines. I understand this can be automated on Windows clients using Active Directory, but for anyone else it would be a manual process.
  • Any time the server’s name is changed, or a name is added, generate a new cert containing all names that belong to that server, if the server is using the default cert. If it’s been set to use any other cert, then don’t generate anything new.

This involves very little GUI work–the only change would be adding a link somewhere to download the CA cert. But it still has the default Neth cert signed by a CA, which can be trusted, which should avoid (or at least reduce) browser warnings. Until browsers start requiring Certificate Transparency, that is…

And I’m going to repeat my suggestion (even though it doesn’t have anything to do with NS acting as a CA) that Nethesis provide acme-dns service, perhaps as a subscription benefit. Implementing this well would require some GUI work in NS–primarily, it would need a way to tell the user what CNAME records need to be created–but requires no other software on the user’s system other than the hook script, and provides a relatively foolproof way for private servers to get trusted certs.