Letsencrypt wild card Certificates


(Bill ) #1

I am confused about ssl certificates. I currently use Nethservers built in lets-encrypt cert tool to request a server.domain.com cert which only seems to renew over port 80. I also have another server server2.domain.com that uses letsencrypt for some mqtt data that also renews over port 80. I have to keep changing my fire wall settings in my tplink router (port forwarding) every few months so they can auto renew.

This is stupid.

I would like to add more servers, so a wild card cert seems like the answer *.domain.com.

Is this possible using Nethserver? Am I doing something wrong?


(Eddie Atherton) #2

You can always add multiple SANs to the certificate:

image

Cheers.


(Giacomo Sanchietti) #3

Take a look also to this great howto:


(Dan) #4

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.