I've got a website with a certificate through Let's Encrypt. Related to that website is an internal network accessible via a VPN and used by ~10 people on their personal devices. In this network, there are several web servers (some grouped together according to use) that I would like to connect to through HTTPS. Is it possible, through Let's Encrypt, for each server (or each group of servers) to have a unique certificate?
A half solution I've found is a wildcard certificate. My understanding of a wildcard certificate is it would allow us to place the same certificate on each of the servers. I'd prefer distinct certificates so that if one is compromised not all others are.
Another solution, unrelated to Let's Encrypt, is to self-sign a Root Certificate. I'd rather not do this since I would like each of the end-users (specifically their browsers) to trust these web servers once connected through the VPN. Seemingly we could have each end-user trust these certificates but this seems tedious especially since the certificates are periodically renewed.
Overall, what I'm wondering is: Can Let's Encrypt (so the end-users will automatically trust the certificates) issue a modified wildcard certificate with several different certificates?
Basically, your choices are: It's either a wildcard cert or its' not.
LE certs can hold up to 100 entries ("names").
[but that would go against your wish to NOT use the same cert on all the systems]
So, you would need unique/individual certs.
So, then each system would have to perform some ACME request (and pass authentication) to obtain its' own cert.
[not impossible - but might get tedious (if possible)]
You mention VPN... Are the systems that need individual certs accessible via HTTP from the Internet [without VPN]?
If not, then HTTP authentication is not an option (presently).
There is also DNS authentication.
Which may be the best/only choice for your needs.
In order to automate DNS authentication, it's best to use a DSP (DNS Service Provider) that allows for zone updates via API. Who is your DSP?
The thing to do, if you're using an internal CA, is to have your client systems trust the CA certificate. That's a one-time task per client system/software. Once that's done, the certs issued by that CA certificate will automatically be trusted. That's how I use the Smallstep CA for my local resources. It's somewhat tedious, but not nearly as bad as having to trust each leaf cert separately.
For the most part, yes. I've issued a few longer-lived certificates from it, but most (of the TLS certs; SSH user and host certs are different) are the default 24-hour certs. Caddy deals beautifully with this; other client software isn't quite as elegant.
And just as a side issue--there are lots of ways to implement a local CA, and the article I linked is just one of them, but it implements a few nice security features (even if you might want to implement it using a different SBC, since Raspberry Pis now seem to be made of unobtainium):
The private keys are offline--they're using a YubiKey 5 as, effectively, a poor man's Hardware Security Module. An offline copy is stored on a USB flash drive, but the keys never touch the filesystem of the CA, and thus there's no way they can leak.
Since randomness is so important in cryptography, it uses a hardware true random number generator.
Since nothing else is running on this device, it has a pretty small attack surface.
And as I alluded to above, it can issue not only TLS certificates, but also SSH host and user certificates. I use my own LemonLDAP::NG installation as a SSH backend for these--logging into that gives me a SSH user certificate that I can use to log into (most of) my other systems.
I'm trying to test the article you sent me in my own little lab today before I implement it on my internal network.
It's a little unclear to me about the offline private key interaction. When I do this initially and issue all the SSL certificates to the servers I'll have the YubiKey (or HSM if I choose to upgrade) connected to the issuing computer. After that, I should disconnect it from the network then reconnect it when I issue/reissue/revoke certificates?
I wouldn't recommend it. The way the system is set up in that guide issues very short-lived (24 hours) certificates, so you'll be renewing them very often. And since "renewal" is nothing different from issuing a new cert, you'll need the key available (and therefore the YubiKey plugged in) pretty much all the time.
When configured according to that guide, the private keys are stored on the YubiKey, but cannot (at least in theory) be extracted from it. All the cryptographic signing operations are done by the YubiKey itself, not by the SmallStep CA software--it's that sense in which the YubiKey is acting as a HSM.