Lots of ways to skin this cat. Here are a few; there are probably others I’m not thinking of:
- Just keep doing what you’re doing. Simple, but a PITA.
- As @EddieA suggested, you can put multiple FQDNs on a single cert. Add the FQDN of your other server, then send the resulting cert/key files to the other server–you’d want to script this to make it practical.
- Run a separate job on your Neth box to obtain a second cert just for the other server, then deploy the cert to that server. This is what I did on my SME server for a while; scripting the deployment was generally pretty straightforward. Here are a few examples of how I did that.
- If your DNS host is supported by a suitable ACME client, use DNS validation to obtain the cert for your other server. Here’s a how-to I wrote up for doing this on a Neth box using acme.sh; the process would be pretty similar for any other *nix system.
- If your DNS host doesn’t have a suitable API (or you just don’t want to use it because it would leave you too exposed if its credentials were to become compromised), install acme-dns on your Neth server, then use that to do DNS validation for your other server–here’s a how-to I wrote up for that.
- Get a wildcard cert on your Neth box, and automate deployment of that cert to your other server. Not a big fan of this one, honestly.
I’ve been dealing with this issue for a while (pretty much since Let’s Encrypt went public). My first answer was, essentially, the third option I listed above–I got all the certs on my SME box using HTTP validation, then deployed those certs to whatever other hosts needed them. Finding that a bit awkward, I changed to using DNS validation (which involved switching my DNS hosting to Cloudflare at no cost), and am now using a combination of my fourth and fifth bullet points.