How should I automate?

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:

certbot certonly \
    --config-dir "$lets_encrypt_config_directory" \
    --work-dir "$lets_encrypt_work_directory" \
    --logs-dir "$lets_encrypt_log_directory" \
    --cert-path "$cert_path" \
    --key-path "$key_path" \
    --fullchain-path "$full_chain_path" \
    --chain-path "$chain_path" \
    --manual \
    --agree-tos \
    --email "$email" \
    --no-eff-email \
    --key-type "$key_type" \
    --preferred-challenges dns \
    --manual-auth-hook "$hook_script" \
    --manual-cleanup-hook "$cleanup_script" \
    --server "$acme_server" \
    --cert-name "$cert_name" \
    -d "$domain" \
    --acount "$account" \
    --force-renewal

force-renewal to renew without prompt

the flags:
--account
--config-dir
--work-dir
--logs-dir
--cert-path
--key-path
--fullchain-path
--chain-path

are not taking into account if the files having different values which are auto generated.

any thoguhts?

Hello @CertifyMe, welcome to the Let's Encrypt community. :slightly_smiling_face:

Here is a search for force-renewal on this community forum:
https://community.letsencrypt.org/search?expanded=true&q=force-renewal%20order%3Alatest
look for a common theme in the responses about using that option.

Yes!:

That is NOT what that is for.
Please don't use it in any such way - remove that from your script.

Please clarify/reword this sentence:

Renewals do not require such specifics; They should have all been recorded during the issuance.
Use only:
certbot renew

And one more "thought"

Speelchkrs dew wunderes

2 Likes

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?

@Bruce5051 @rg305 thanks for replying so fast :slight_smile: , glad to be here

3 Likes

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.

3 Likes

Yes, --test-cert or use a different value for --server like

--server https://acme-staging-v02.api.letsencrypt.org/directory

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.

Is that what you are asking?

3 Likes

Please DO NOT USE --force-renewal.

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.

4 Likes

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.

2 Likes

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.

3 Likes

Yes.

How many computers/systems are you talking about?

3 Likes

@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.

2 Likes

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.

3 Likes

Well that is going to be a problem.

That should be no problem.
You can use any method you choose:

  • independent DNS-01 authentications
  • share/copy the certificate(s)
  • pull cert(s) from central location
  • etc.
3 Likes

my current method is DNS, and I did copy only the certificate and key, but once i download it in a different system it fails

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

and

3 Likes

The certs are good to use, i'm testing the renewal process.
here is what I want to do:

  1. create a certificate for site1.mydomain.com
  2. save the certificate and keys just created
  3. renew that cert once needed
  4. upload the renewed certificate.

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

If you use DNS, then you don't need to copy anything.
[other than the command being run and the credentials being used]

2 Likes

but that will create a new certificate every time which will be held against my certificate quota and not my renewal quota