What is recommended: Use UCS CA to manage client certificates, or setup a separated PKI?

[tony2]

Hello,

I would like to setup own PKI to manage internal certificates. Since I already use UCS which has its own CA, I wonder what would be recommended between the following options:

(1) use UCS CA to create the certificates as per https://docs.software-univention.de/domain-4.4.html#extdom:ssl:manage. This works very well if one needs only to issue a few certs for some non-UCS servers. However it supports only ssl certs for server. I would like to be able to create client cert for openvpn, and this seems unsupported. I looked into the scripts /usr/sbin/univention-certificate and /usr/share/univention-ssl/make-certificates.sh, and I think I might be able use openssl directly to generate the CSR for openvpn clients and sign them with UCS CA. However there are some potential problems with this approach:

• it can break UCS (just a worry, I am not that experienced with openssl and UCS)
• it will put a lot of certs into the UCS CA db (under /etc/univention/ssl), since I want to create for each openvpn user a separate cert

What I like about this approach is that I have a single CA in UCS,

(2) setup another PKI, completely separated from UCS CA, following for example this guide: https://pki-tutorial.readthedocs.io/. This is probably easier and safer. The downside is that now I have 2 root CA, which feels odd.

What would you recommend?

Regards,
Tony

[tony2]

I think another option would be this:

• create a signing CA, sign its cert with UCS CA
• use this signing CA to issue non-UCS certs

This way I still have a single root CA (UCS CA), but can manage non-UCS certs using only the signing CA, hence reduce the chance of conflicts.

Would this option be a reasonable choice?

[externa1]

maybe that helps:

Cool Solution - Creating custom certificates for "ip managed client" / switch

Task Serveral switches on my internal network need their own certificates issued and the corresponding pem files uploaded to properly support https for their management GUI. As my infrastructure can not be reached/verified from the internet, LetsEncrypt is no viable solution. The facilitation of the internal CA of the UCS server looks intriguing… Conceptual Solution First of all - thanks for all the great “cool solutions”, there’s a lot to discover and the solutions are really straight from the…

rg
Christian

[tony2]

thank you, that’s a lot of useful information, very much appreciated.

I took a close look; unfortunately for me the openvpn client certs are not ip-managed; they are bound to username.

I also tried to setup an intermediate CA, sign it with UCS CA and use the intermediate CA to issue internal certs. I could issue a server cert, got it up and running, now going to issue the openvpn client cert. However a small issue is that I must include the intermediate cert in every leaf cert.

I am still evaluating the options and hope to hear further opinions/recommendations from UCS admins.

Regards,
Tony

[raphi59]

Hi Tony2,

Have you already figured out how to issue client certs for non-ip-managed-clients from the univention ca?

[tony2]

Hi,

I ended up with this approach:

• copy the root CA from UCS to a safe server
• use that root CA to create intermediate and leaf certs as I need. I use the tools from smallstep https://github.com/smallstep/cli, much easier to use than openssl.

This way I have a single CA (generated by UCS) but can create the certs I need in a convenient way.