Create certs for different machines

I have a few certs that I am creating (one domain with several subdomains, for those who are curious) that will be spread across different machines. Is there a way that I can install LetsEncrypt on a single machine and move the certs/keys/whatever around once they’re generated to each other machine or do I really need to install LetsEncrypt on each individual machine that requires a cert?

I’ve seen a few posts that partially address this, but nothing that can be used for a reference unless you already understand the process and what is required >_>

Thanks for the help!


Yes, that's possible. But as far as I know, there aren't any "integrated" software solutions. It all depends on your situation and you'll probably need to script it yourself.

1 Like

Do you need the exact same cert?
Or just the exact same set of names in the cert?

1 Like

Thanks for the quick reply Osiris. Sad to hear (but good to know) there aren’t any well known existing tools out there for this :frowning_face:

Let’s say I have “server A”, where I install Let’s Encrypt and “server B” where I am hosting one subdomain.

My understanding is that Let’s Encrypt works on a challenge (Let’s Encrypt explaination), so as long as it sees the correct thing on the correct page, it doesn’t actually care where it’s looking or how it got there–meaning that as long as the query hits Server B and sees the correct page, it works. So this means I’ll need to move the page from Server A (where Lets Encrypt generates it) to Server B (where the request will be router).

This means that I will also have to move the private key at some point as well–and I suppose somehow have Server B aware of the key? I assume the 1st part is as simple as copying a file (wherever that may be) & the 2nd part depends on what web server you’re using, but probably just needs the private key to be in the right place?

Does this sound about right? Am I drastically oversimplifying? Am I missing steps? Thanks for the help :slight_smile:

1 Like

LE will follow redirects.
That can be a huge advantage in these types of cases.
You can insert code to redirect only the /.well-known/acme-challenge/ requests to a specific FQDN that you control.

You can play many tricks from there.

  • You could process all request at that one system and have the remote systems come pickup their copies of the cert(s).
  • You could cname that FQDN (or modify the IP) to any of the individual systems periodically or on a schedule. Allowing the individual systems to obtain their own certs.
1 Like

Hey rg305. I’m not understanding what you’re asking, so I’m assuming I’m not clear explaining what I’m trying to do.

Let’s say I have 3 different machines, each running a different subdomain of a common website. Rather than install Let’s Encrypt on each machine, I’d rather just install Lets Encrypt on a single machine and move files around. This means I install Let’s Encrypt once, run it 3 times (one for each subdomain) and move that private key to the correct server so that it’s on the correct subdomain. This seems easier (to me) than needing to repeatedly run Let’s Encrypt on multiple machines every time I need to upgrade or change something.

1 Like

I don't understand "move" them around.
I will take that as "share copies".

If you don't mind having all the names on one cert (for an even simpler solution), you can just get one cert with multiple names on it.

As "complicated" as it may seem, the whole point of this exercise it to automate the system.
So, as long as it is automated (and it works), complexity is actually a non-issue.

1 Like

I was showing how you can "consolidate" the challenge requests into a single system; even when their IPs are completely different. [if that helps you reach your goal quicker]

1 Like

rg305 it sounds like you’re saying that I’m thinking about this wrong! And that the easiest path would be to just install Lets Encrypt on each machine individually?

So, as long as it is automated (and it works), complexity is actually a non-issue.

It’s the “and it works” part that has me concerned >_> If it doesn’t work, what would happen? And how much of a pain would it be to fix?

1 Like

OK, I see the point on “when things go wrong” complexity can be a deterrent.
So, let’s try to keep it simple and yet in a manner that can scale and be functional.

How about a very low use dedicated instance (probably can get one for free).
That will only do the renewals. [so your trouble shooting is in only one place]
Then use RSYNC to copy the necessary file - or the entire path - from each of the servers needing certs.
That scales To infinity and beyond!

Troubleshooting will be a single client on a single system.
Can’t make that any simpler.
So choose a simple client with a good community and support and your set.
Well that and you have to make RSYNC your friend - but that is simple (and encrypted too).

Just my 2 cents…
There are many solutions to this type of problem.
None are hard set simply because there are so many variables that it is impossible to issue a one-size-fits-all solution.

1 Like

@coatmaker618, after re-reading your posts, it seems clear that you don’t yet fully understand the authentication process. As you have included passing the private key around as a possible requirement for authentication.

Let me add some clarity.
The private key is not used in the authentication process.
HTTP authentication requires that a specific file with specific content be placed in a specific location.
The file and the content are negotiated by the ACME client and server. [one-time use only]
The location is always http://<your.fqdn>/.well-known/acme-challenge/<file-name>
But LE will follow challenge request redirects, so that location can be “moved” to any other FQDN, another path, and to TLS (port 443) if so desired.

1 Like

it seems clear that you don’t yet fully understand the authentication process. As you have included passing the private key around as a possible requirement for authentication.

Ok, I think I’m confusing authentication of Let’s Encrypt with the TLS encryption? Because the whole point of the Let’s Encrypt challenge (putting a file at: http://<your.fqdn>/.well-known/acme-challenge/<file-name>) is to verify that you actually own the domain? And once ownership is established, you get a private key & send Lets Encrypt your public key. Then you (only) use your private key every time someone tries to browse to your webpage via HTTPS.

So I see that you can authenticate with Lets Encrypt without moving your private key around. Thanks for clearing that up!

1 Like


The other way around...
One generates ones own private key [and that is NEVER shared - always private]
After authentication, LE sends the public cert.

You'll get it - it's not rocket science! LOL

1 Like

In short:
An ACME client (“client”) creates a private key/public cert pair.
Then tries to get it signed by a trusted CA (“LE”) [so all can trust it].
LE must verify ownership (in this case by HTTP authentication).
Client passes LE the public cert to be signed and LE sends back a “proof” file.
(“put this file with this content in this specific location and I will believe you are who you say you are”)
Client places file in said location and asks LE to verify.
LE tries to verify file:

  • Pass = LE returns a signed cert and all are happy.
  • Fail = LE returns error code(s) and all are unhappy

… and that was the short version! ? …

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.