If I generate the initial keys on the server 111.112.113.114 then how should those be used / moved to the other servers and how will one automate renewal of the keys and then getting those cert files to each other server?
Is it possible to just generate each set of keys on each server?
I am looking for a sensible working solution to this before I even generate any keys for this one particular domain. Anyone have any real world advice on doing this correctly, cleanly and properly?
Let's Encrypt can issue you many certificates, subject to rate limits to let everyone share fairly
So you have basically two alternatives, you could use either of them, or a mixture of both
You could ask for a separate certificate on each server, just covering the names used by that server. Each server will need to run "certbot" or other client software to obtain the certificate, both initially and then to renew these certificates every couple of months. Most people set this with a cron job or similar.
OR
2, Ask for one certificate covering all the names, or a large group of names, and then securely copy the associated keys and certificates to each server which needs them. For example with a script that calls scp or something.
For every name in every certificate you will need to be able prove to Let's Encrypt that you control this name. So that may be much easier to do in scenario 1 where the software asking for the certificate is running on the machine it needs to prove control of. On the web servers for example, you should be able to do the "http-01" challenge, where Let's Encrypt just wants to see a special file created in a particular URL on the web server with that name.
I am all about fair play so I am not one to go generating keys for hundreds of domains. Even though I have 150+ domains I only have about 20 in use and will only ever generate keys for my important sites, for the foreseeable future 15 domains … that’s it.
My primary domain that handles mail etc for all other domains is the one where I need these keys spread across different boxes.
I have full root control over all 4 servers, they all run the very same Server OS and setup. So that means I can install letsencrypt on each one and generate each set of keys for each server individually.
That sounds like just the answer I needed and I will test this today to see if I run into any errors.
So effectively on:
Server 1: I can generate mydomain.com (with an expand option) to generate the www
Server 2: I can generate mx.mydomain.com
etc etc etc
Then just run my cron job on each server to auto-renew each set of keys.
Copying keys between servers just wasn’t an option for me, no matter how secure it can be done. It’s just clumsy and messy in my books.
Thanks so much I will test this out today and report back on this post.
This sounds right. If you know straight away that you want www.example.com and example.com in a certificate you won’t need the “expand” mode, that’s for adding things later. Just specify you want both these names in the initial request. For the certbot client that’s by using the -d option, so after the rest of the command it’d be something like -d www.example.com -d example.com to ask that both names appear in the certificate.
That actually depends on how it's done. With your configuration it certainly works to run specific certificate generation on each server, but for example with more servers being added over time, at certain point you would end up with a bit of a mess in terms of update management and would have multiple points of failure. In which case it would probably become more efficient to ProxyPass validation path to a dedicated machine running the certificate generation and then distribute the certs with Puppet or similar software.
Awesome, thanks leader for the confirmation. I am a small environment, 4 servers is enough for me to manage and that’s it for me … only 4 for ever (famous last words)
Just another quick question I hope you can answer before I even get started on this set of keys today.
Is it better to use the Domain TXT key challenge on the domain for that extra level of authentication of who really owns and controls the domain? I run my own nameservers for all my domains so adding TXT records is no pain, just finding any documentation on this right now seems impossible.
For LE it doesn't really matter what type of challenge is being selected, as long as you are able to satisfy it. So in my view it's more about what is more convenient.
For example, if I don't like the idea of creating files at all or there is something preventing HTTP verification from being successfully run (as in some other topic, where symlink protection seems to interfere with the process) or if I have a domain but the site is not yet public or just does not exist - then I would go for DNS option.
Or if I'm actually running my own name servers and I can instantly publish the new records (unlike the case when I push them to NS servers not running by me and it takes some time for the records to appear), then I might choose DNS too.
P.S. The DNS record value is constructed as follows:
A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key. The client then computes the SHA-256
digest of the key authorization.
The record provisioned to the DNS is the base64 encoding of this digest. The client constructs the validation domain name by prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under that name.
I'm not sure whether certbot supports dns-01 challenge yet, though some alternative clients do (my Crypt::LE certainly does).
Should one add the --expand parameter when generating keys for a domain that you know will grow later or can you just re-generate keys at a later date adding more subdomains with the -d paramater ?
Thanks so much leader, I think DNS records are a viable option for me as I am hesitant to go the ./well-known directory route on my Apache server and having to create files there for validation.
Now to read through all the documentation about these scripts above and then do some testing.
When testing with certbot-auto does one just use the –test-cert, --staging option to see if all response are correct before live generating keys? does either option do the same thing?
Nah, the --expand parameter isn’t about whether the domain will grow in the future, it’s a way to tell the certbot client (other clients might be different, check their documentation) that even though the certificate you’re now asking for has extra names, it should be considered a replacement for an existing certificate, not a completely fresh “lineage” of certificates.
Suppose you have one cert for a.example and b.example, and then one day you want a cert to cover a.example, b.example and c.example as well.
If you use --expand when requesting the newer certificate, certbot knows you mean for this new certificate to replace the one used for a.example and b.example today, which is fine since it still has those names in it, just it will now have c.example in it too.
If you do NOT use --expand for that request then certbot assumes you want to keep having certificates issued with just a.example and b.example, but you ALSO want certificates with a.example, b.example and c.example. Every couple of months it will renew both types of certificate.
Some people might want this, but most people will want the --expand behaviour.
(famous last words)