One PKI for multiple servers (openvpn + webui + pixelserv-tls)

[truglodite]

I have been getting my cranial signals crossed learning the ins/outs of SSL, as it relates to openvpn vs merlin webui. I need a few questions answered to help straighten my course. ...this is just for my home, n66u 380.67, with only a handful of family only devices connecting.

Right now my openvpn server (on merlin) is working well after a basic gui setup, but I'm studying on upgrading to individual client PKI pairs with easyrsa. The https webui requires extra clicks to access with a red lock... annoying. I'm only accessing the webui from one lan machine, but it would be nice to greenify it, rather than (-half donkey-) http it.

Can I safely use a single PKI (same ca) to build files for both openvpn and webui (and pixelserv-tls), or should I setup a separate PKI for each server? (I'm always interested in the perform:secure reasoning.)

For ovpn, my understanding is I would paste my server keys/certs in the openvpn server gui (say, 'server1'), then setup/export/modify custom client configs that point to the key/crt files on the clients, correct? What happens with of the user/passwords listed in the gui?

For the webgui, I presume I use easyrsa\build-key-server again (cn = 'server2'), then copy/paste contents over the router's existing persistent webui pair (in /jffs/ssl). What about the client end... no export button? (lol j/k)... do I just have the os trust the root cert? Again, only 1 lan wired rig will ever need to access it.

I presume the same strategy for the webui would also work for a pixelserv-tls (I believe they're the same thing... both openssl+httpd servers). If so, my plan is to generate another server pair (cn=server3) for pixelserv-tls, using the same ca. That should just work as long as the client os's trusts the ca, correct?

Considering the 3 servers uses, is it still OK just having one ca? My kids devices will be 'accessing' pixelserv all the time, and one PKI means they'll be able access the router login page as well... my router PW is in itself fairly secure... just worried if the kiddo's install malware on their devices without my knowledge.

Thanks in advance,
Kevin

 

[RMerlin]

Sharing the same Certificate Authority should be fine. In fact it's something I've been pondering lately, to deal with a bunch of self-signed stuff I have to use left and right.

I wouldn't use EasyRSA for a web certificate however. Best to manually create it with openssl, which will allow you to define SANs among other things.

 

[truglodite]

Ooh, googling self-signed web certs using openssl, and finding references to SANs... looks like I've got a whole 'nother book to read upon. If anyone happens to have links to some newb friendly openssh web cert primers, I'd be greatful if you shared them.

I'm not sure if it's even worth the trouble to setup considering everything in question is LAN isolated (aside from VPN access). That said, I live to learn and so will get the hang of it eventually... just not as worried about fixing the red lock right away.

Thanks

 

[sfx2000]

Sharing the same Certificate Authority should be fine. In fact it's something I've been pondering lately, to deal with a bunch of self-signed stuff I have to use left and right.

It's actually good practice to do so - saves time and effort...

Having a master keyring is a good thing, then attach the keys to it...

I wouldn't use EasyRSA for a web certificate however. Best to manually create it with openssl, which will allow you to define SANs among other things.

using OpenSSL to generate certs - concur here - better than using Easy RSA to create - that being said, Easy RSA might be an approach to "manage" certs generated by OpenSSL (or other tools like gnutls) - I'll have to mull on that one a bit.

 

[RMerlin]

EasyRSA is nice for managing OpenVPN certificates.

Windows needs a simple to use GUI-based tool that would allow to easily manage a PKI chain. Even if itès just a wrapper around OpenSSL. A .NET developer might find himself an interesting project there...

 

[sfx2000]

EasyRSA is nice for managing OpenVPN certificates.

For any certs, not just OVPN...

Windows needs a simple to use GUI-based tool that would allow to easily manage a PKI chain. Even if itès just a wrapper around OpenSSL. A .NET developer might find himself an interesting project there...

MacOS has their toolchain - generally works well, but like any software, things can go wrong...

For Windows - I think there's something similar...

https://docs.microsoft.com/en-us/dotnet/framework/tools/certmgr-exe-certificate-manager-tool

 

[Theliel]

IMHO, For Windows, XCA has been the best GUI I've seen in years for Windows. Its not perfect, but work pretty well, and use OpenSSL

 

[truglodite]

I have a related question and didn't want to start a new thread since it involves pki stuff. What are the current cert specs that modern browsers like the latest chrome need to see? (Not crypto wise, but ca info items like cn and san)

My current self signed certs have their server ip's as the cn, and the San's include ip's (and host name's where applicable like router.asus.com for the webui cert san). Using chrome with these certs trusted, I see a green padlock on the webui, and also my pixelserv-tls stats page (from https...) is the same. However recently I noticed the same clients occasionally will reject ome pixelserv generated certs as 'unknown'.

I checked these troublesome pixelserv-tls generated certs, and they have the pixelserv ip as a cn, and just a blocked website as a San (ex. *.googleanalytics.com). Could it be because the pixelserv ip isn't in the pixelserv generated cert san?

Any other new standards coming down the pike to consider? ...like email in the san...