Hey,
I'm trying to automate the process to create certificates, using certbot.
Currently I manage to use the commands to create and renew certificates when all done in one computer.
I want to save the certificates on a secret/ durable store and have a process calling for the right certificate and renew it from different allowed computers.
having just the certificates is not enough, so I'm trying to figure how can I save the minimum possible for the process.
is there a tutorial somewhere? suggestions? tools ?do you just copy the entire filesystem and mount it to different computers? I wish to just save the certificates and maybe the required metadata (account for example) and call them when the process is triggered.
some of the weird behaviour I saw was flags in the command where overridden by the files generated automatically.
I'm using the following command to create and later also renew:
I'm in research mode, Initially I used certbot renew, but it depends on the letsencrypt/config/renewal/*.conf files, I tried to see if I can pass all the flags in one command but without success, moreover the force renewal flag is used right now for testing to see whether I manage to renew or if I send certbot to get a new certificate, once I'll get it stable i'll remove the force and will expect the software to successfully renew in the last 30 days..
about the flags i'll try to rephrase. my expectations were that if I pass the flags values they will override the filesystem values, it seems it did not and that the files have bigger weight.
So how do i get rid of the filesystem and pass everything on the command? because when I issue a certificate it saves the absolute paths on the computer that made the requests which make it unclea and hard to use on another computer later on. (I thought of using /tmp, or create a container but feel there is asimple way)
how do you go about it? do u save the entire filesystem or do u save just the certs? or?
Research mode is fine. Unfortunately you are missing the most important flag for that, which is --test-cert. See: Staging Environment. There you can test without burdening the productive system and with much higher rate limits.
The easiest way is just let Certbot do its thing in its own folder structure. Don't try to control every element. Then just copy the files from from the ../live/ folder for the cert chain and private key that you need (usually the fullchain.pem and privkey.pem). If the other server is in recurring location you can use --deploy-hook to ensure certs are copied there every time they are renewed.
Or, of course, wrap the certbot renew with your own script to make these copies.
They only update the renewal.conf when a new cert is actually issued.
When you run the command and it fails, then no changes are made to renewal.conf files.
That's what --dry-run is for, so you can test away without hitting rate limits and unnecessarily add load to the Let's Encrypt systems.
I'd say --dry-run is better for testing than --staging or --test-cert when there's already an existing certificate present. When using --staging or --test-cert with an already valid certificate present, Certbot will try to overwrite a perfectly fine and publicly trusted certificate with a fake, staging one. However, --dry-run does not have that limitation. It will do everything required for proper testing issuance, but will do so on the staging environment without overwriting any existing certificate.
Bachsau I use explicit server instead with this --server "$acme_server" and i feed it the staging server. I also validated it goes to staging with the command openssl x509 -text -noout -in "$cert_path".
@MikeMcQ the live folder is just a symlink folder to the archive folder, I hoped I can copy the certificates and the key and that would be enough, but right now it seems certbot requires the renewal folder and the account folder.
I don't have an issue with initially create or later renew from the same computer, but If i want a system that can just run the script I need the configuration to be the same and true on all computers its going to be run on, and Ideally i thought and still trying to figure what is the minimum I need, hopefully just the certs and the key.
I wrote a script that copies the certificates and key to a remote location, but once I fetch them it fails because the absolute path of the initial computer is not the same, also i think there is a problem i did not save the account key which i dont understand what it servs.
let me know if i'm still unclear
@rg305 so if I change them they will change the conf file?
Osiris I thought using staging is correct to test what actually happen and not assumptions
Correct. Changing production vs. staging with the --server option is a viable method, but personally I'd use --dry-run for that. That'll switch Certbot to the staging environment internally without messing up any existing publicly trusted certificate.
@rg305 i'll test the conf thing tomorrow i gueess, with that said when I deleted the conf file and ran the command certbot was not willing to proceed, and I dont understand why it is dependant if I provide all the info in the command
in practice infinite out of vm image, but lets say 3-4 different systems
Please don't add/move/delete/modify any files within the control of any ACM client.
When you do that, there is no telling what will happen.
In this case, there was likely already other remaining file(s) found which conflicted with your request.
Totally agree. But, in some cases when you are testing the "boot strap" of a new Certbot install it is nicer to get the test certs and the related folders. With --dry-run you don't get that.
This thread seems more about having multiple certbot installs and options for managing that so staging --server settings can be more helpful.
Should not fail if you are just using that cert/privkey in some other server. If you give us more details of the failure perhaps it is something else. Copying these files is routine although with certbot make sure to copy the file and not just the symlink.
Also:
If you really are talking large numbers of servers running ACME clients be sure to see
I'm not talking about my deploy process to the website itself.
right now we have a adhoc script which saves the certificate and keys in git.
I want to have the ability to run a renew/ create from every computer for a specific certificate and not all my certificates, while removing the certificates and key from git and have it be stored in a secret store. so far it seems certbot requires its filesystem including the conf file in renewal file and the account folder as well on top of what I thought was the minimum- certs and key