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.
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
+1 for any enhancement/fix to default NS certificate generation process
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.
Would be nice. Even for services within NS, it would be nice to have an actual internal CA to issue separate certificates for each service (or assign different external ones for that matter).
When NS is the only server in an environment, this is actually needed functionality to give enough security for clients that trust this CA and not resort to external CA.
Disclaimer part:
I actually evaluated several solutions (in VMs) and I found the strongest competitor to be Zentyal.
I hope this is not taken wrong, but here are my feelings about how NS could be improved. I.e. my list of things missing (and needed) that ARE available in Zentyal. Not a complete list, just what I believe is vital.
NOTE! My comparison between the two systems, also includes MANY positive things for NS. Thing is, positive things are not helping to improve a product. So I may list those in some other thread (or in my blog), not here. I am not bashing NS in any way. Actually I am heavily leaning towards NS for my home server (within an unRAID VM), this is why I post here what I think should be in. As it is “closer” than other “finalist” Zentyal, to what I need already.
Really hope some of these things do get implemented eventually.
Interesting, I’d remembered this thread, but I hadn’t remembered that I’d started it. I ran across this earlier today, and it looks like a pretty slick deal. It would take some adaptation to run it on Neth, of course (it uses a Raspberry Pi), and you probably would want certs valid for more than 24 hours, but it includes some nice touches like:
Running an ACME server to issue certs, so any ACME client can get a cert from the internal CA
It uses a HSM (a YubiKey) to store the private keys; they aren’t online on the signing machine
OTOH, the CA is more secure if that’s all it does, and if the only way it’s accessible on your network is via its ACME API. That would argue against putting it on the Neth server at all, and Pis are cheap enough that a standalone CA (even with the YubiKey and hardware RNG) wouldn’t cost much more than US$100–though you’d need to plug in a monitor and keyboard to administer it.
Though this seems to be configurable, it also looks like it’s a conscious decision:
It does seem to avoid the problems associated with certificate revocation:
One thing I think I would add to these instructions, though, would be to try to come up with some form of paper backup for the CA private key–USB keys are notoriously unreliable. qrencode would seem to do the trick here, then print off that image. Of course, in that case, it’s critical that that piece of paper be stored securely–but as I have a commercial-grade safe at home, I think I have that covered…
If using a Raspberry, it’s not much insecure to allow a single LAN IP access to the RPI for administrative purposes - either using SSH or even RDP (also limited to a single IP and only if GUI access is needed). Both are very trivial to enable / set on a RPI…
I do have 25 RPIs running as UPS NUT server at my clients - and I do need to administer them from Home Office… I do have VPN access to all client LANs, so this is workable!
Saves a Keyboard and Monitor and gives anytime accessibility without replugging an existing monitor / keyboard…
RDP and SSH can easily be protected by fail2ban on a RPI…
No, but it’s always a tradeoff between security and convenience. That opens another port, which exposes another service, with its associated vulnerabilities. And when you’re talking about a certificate authority that would be trusted by everyone else on your network, that’s kind of the “family jewels” for your network, so it might be worth taking some extraordinary measures to secure it.
Granted, the OpenSSH server is pretty robust, but…
I will admit to having 2 RPI-3b at clients remote office with full public SSH (NOT Port 22!) and RDP (NOT Port 3389 !) available. behind a firewall and with fail2ban protection.
The reason behind this: There’s only a NAS at that office, the occupants often work from home office. The router from the provider can’t be bridged, as they’re needed for telephony. They have a default host or DMZ Host (The Internal firewall) to which all ports are forwarded. This firewall creates VPN to both other sites. Every 3-6 Months, the VPN drops, and the only solution is to reboot the provider router. This I do via RDP, a browser on the RPI and the provider router…
In two minutes, all is running again, including both VPNs…
Only workable solution, as one of the offices is in Lugano, on the other side of the swiss alps from my home…
Yet in 4 years, port scanner availability for script-kiddies and hackers alike, no one has been able to hack into these things! They have no access to anything else anyway, but still, they’re amazingly secure… And they’re monitored for any eventtualities.
But fail2ban is quite effective! Even with fail2ban, it’s NOT a good idea to use a simple password like 123…
If you recall Microsofts Windows NT advertisment back in the early ninties: C4 security level achieved for NT Server…
But only with NO Network plugged in… Might as well lock the server in an secure safe - without networking, what use is a server anyway?
Public key authentication is even better, of course. A non-standard port helps too. It sounds like SSH certificates would be better yet, but I don’t know much about them.
I have a spare Pi; I just ordered a couple of YubiKeys and the TRNG to give this a try.
Well, the TRNG isn’t here (not expected to ship for another month), but the YubiKeys arrived today, and the guide I linked above worked perfectly. Caddy is able to get a cert from this CA without issues, the private keys are stored only on the YubiKey, which handles the signing itself, and it’s pretty straightforward to install the root cert on clients running Linux or MacOS (or, presumably, Windows, but I haven’t tried that yet).
Sure, it’s just a matter of setting the CA configuration appropriately.
Their recommendations call for running the renewal job much more frequently than would normally be the case with Let’s Encrypt, for things that run on a schedule (smarter clients like Caddy handle it automatically). For example, they call for running the certbot renew task every 15 minutes. For client’s that renew based on age of cert, though, rather than remaining life of cert (like acme.sh), you may need to add a --force or equivalent.
But to be sure, if the CA device goes down for more than a few hours, there’s a risk of some certs not getting timely renewed.
So I may list those in some other thread (or in my blog), not here. I am not bashing NS in any way. Actually I am heavily leaning towards NS for my home server (within an unRAID VM), this is why I post here what I think should be in. As it is “closer” than other “finalist” Zentyal, to what I need already.
