How should certificates for multiple separate sub-domain servers be issued/renewed with Let's Encrypt?

Question

Upgrading my home infrastructure to learn as well as be more secure, I have not been able to find out how best to get certificate(s) issues and installed across my servers, which comprise:

• Firewall (pfSense - FreeBSD): fw.example.com
• NAS (Openmediavault - Debian Buster): nas.example.com:80 ▷ nas.example.com:443
• Network controller (Unifi on same Debian Buster as the NAS) nas.example.com:8443
• Video Controller (Unifi ditto) nas.example.com:7443
• Home Automation (Home Assistant on hass.io) home.example.com:8123

With that background:

1. Should I run ACME protocol software (Certbot, acme.sh or equivalent) on each server through Cron to have Let's Encrypt issue and renew the certificate(s)? Or should I do it on one server and set up to copy the resulting public and private keys to the others?

2. Is one certificate with Subject Alternative Names (SANs) for the domain itself (example.com) AND one for each subdomain (fw.example.com, nas.example.com & home.example.com) OR wildcard (*.example.com, which restricts authentication methd). Or should each server get its own certificate?

For now, in additional to the firewall, only Home Assistant will be external facing. Thus it is the obvious candidate for the issue/renew process (given that my registrar is Google Domains, who don't support DNS-O1, so I need an HTTP server for HTTP-01 if I am not be renewing manually every three months).

In future, I would like to implement OpenVPN on the firewall in order. My understanding is that the certificates for that are/should be generated privately.

Further research, suggests HA proxy for the internal only web sites. Makes sense as it reduces the place where a current certificate is required. But would software that requires https: (e.g. Unifi Controller) not complain, as it won't know that it is being accessed securely as this is handled by HA Proxy. Thoughts on this?

Answer 1

First, a little about how Let's Encrypt and Certbot works:

Certbot is already automating certificate requests, generation and installation on web servers. So you install Certbot on a Internet-facing web server, and it requests the certificate from Let's Encrypt, modifies the web server configuration to use said certificate, and handles renewals of the certificate going forward. So there's no need to automate that part.

However, there will be a need to automate the copying of the certificate to every service that needs it internally.

Hope this answers your first question.

Secondly, SANs are the names of the services that will use the certificate. So normally you might have a web server that serves a lot of different APIs and sites and services. Instead of configuring separate certificates for every different site, you just combine them all into a single certificate using multiple SANs, and only need to handle renewing a single certificate.

The only technical reason to not use a multi-SAN certificate on multiple servers that I can think of is that you're spreading the private key from the certificate over multiple servers, which means that you're exposing the private key more, and if one server get's compromised, all your servers are compromised.

In a business environment you try to avoid this by using one certificate per server, but then again a wildcard certificate used on multiple servers isn't any different, and this is used a lot. Normally though, wildcards are a way to save money, since certificates can be quite expensive, but in your case it doesn't really matter since LE is free.

In your case, I'd just list all the different names in one certificate, have Certbot handle requesting and renewing that certificate, and then use some code to copy the certificate everywhere you need it.

Another option is to use a web server with NGINX as a reverse proxy and do all the HTTPS encryption there, that way only the NGINX server needs the certificate, and you don't need to expose your internal server to the Internet. It's a bit more secure, but you end up with one more server to maintain.

Finally, luckily OpenVPN uses it's own certificates, so you don't need to worry about getting external certificates from a CA for that. The only tip I can give you is to make sure that the internal CA used by OpenVPN has a long expiration time (10 years), and that your client certificates do as well (>1 year).