Using --staging and certbot saves stuff in /live directory ?!?

why when using --staging option the certbot tool creates certs in the LIVE folder ?
/live/

certbot 2.6.0

letsencrypt/
letsencrypt/.gitkeep
letsencrypt/accounts
letsencrypt/accounts/acme-v02.api.letsencrypt.org
letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory
letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/54313ab441be6b6dd1c4daad4066a3cb
letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/54313ab441be6b6dd1c4daad4066a3cb/private_key.json
letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/54313ab441be6b6dd1c4daad4066a3cb/meta.json
letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/54313ab441be6b6dd1c4daad4066a3cb/regr.json
letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org
letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory
letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory/35007be0e72d1a056440647e14afefc2
letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory/35007be0e72d1a056440647e14afefc2/private_key.json
letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory/35007be0e72d1a056440647e14afefc2/meta.json
letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory/35007be0e72d1a056440647e14afefc2/regr.json
letsencrypt/renewal-hooks
letsencrypt/renewal-hooks/pre
letsencrypt/renewal-hooks/deploy
letsencrypt/renewal-hooks/post
letsencrypt/renewal
letsencrypt/renewal/example.com.conf
letsencrypt/live
letsencrypt/live/example.com
letsencrypt/live/example.com/cert.pem
letsencrypt/live/example.com/fullchain.pem
letsencrypt/live/example.com/chain.pem
letsencrypt/live/example.com/privkey.pem
letsencrypt/live/example.com/README
letsencrypt/live/README
letsencrypt/archive
letsencrypt/archive/example.com
letsencrypt/archive/example.com/fullchain1.pem
letsencrypt/archive/example.com/privkey1.pem
letsencrypt/archive/example.com/cert1.pem
letsencrypt/archive/example.com/chain1.pem

Correct.

Ah, wait, I see you did ask a question, I see the "why" know.

To explain more: --staging simply changes the ACME server used from the production environment to the staging environment. That's the only change made.

If you don't want any staging certificates ending up in /archive/ and /live/, you should use the --dry-run option.

I'm not sure how/why this is not what you expected?

3 Likes

I would expect the certificates to be saved in /staging/ subfolder.
Now when I try to request a new (live) certbot says not due for renewal.

I tried deleting it delete --cert-name example.com
No certificate found with name

tried passing --staging parameter same thing

How did you try to get a live cert?

See the output of certbot certificates for the certificate name. Maybe you manually deleted something from the /etc/letsencrypt/ directory?

3 Likes

isssuing certbot certificates --non-interactive

No certificates found.

I have set up a tmp docker container and mounted all the necessary folders just for this. I don't think it's a docker issue

hmm, maybe the delete command succeeded after all even though it reported an error ?!?

I don't see the staging cert files anymore

/etc/letsencrypt
/etc/letsencrypt/.gitkeep
/etc/letsencrypt/accounts
/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org
/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory
/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/54313ab441be6b6dd1c4daad4066a3cb
/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/54313ab441be6b6dd1c4daad4066a3cb/private_key.json
/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/54313ab441be6b6dd1c4daad4066a3cb/meta.json
/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/54313ab441be6b6dd1c4daad4066a3cb/regr.json
/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org
/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory
/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory/35007be0e72d1a056440647e14afefc2
/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory/35007be0e72d1a056440647e14afefc2/private_key.json
/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory/35007be0e72d1a056440647e14afefc2/meta.json
/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory/35007be0e72d1a056440647e14afefc2/regr.json
/etc/letsencrypt/renewal-hooks
/etc/letsencrypt/renewal-hooks/pre
/etc/letsencrypt/renewal-hooks/deploy
/etc/letsencrypt/renewal-hooks/post
/etc/letsencrypt/renewal
/etc/letsencrypt/live
/etc/letsencrypt/live/README
/etc/letsencrypt/archive

I don't think delete removes anything from the /archive/ folder ...
Are you sure you didn't remove some files yourself?

2 Likes

I didn't delete anything myself.

hmm...
Then the delete is more comprehensive than I remember it
OR
You are not on the same system - LOL
OR
You didn't show the entire output

2 Likes

I believe it does, actually. The only things preserved if I recall correctly were /csr/ and /keys/, but those don't exist any longer in the latest Certbot version.

4 Likes

I think the keys should be saved in /staging/ folder. It's just confusing to store staging keys into /live/ folder.
I am using docker with alpine image.
In the output I removed replaced my domain with example.com

I had issues with that too when first using Certbot.

Having the staging certs in /live allows your https service to be fully configured and tested for that folder. You can use your https service it just will show cert validation errors. Then, when you get a production cert your https service will work fully.

I'm a little puzzled about the problem getting a production cert though. What was the exact sequence of commands and what was the error?

I agree with Osiris that using --dry-run option is best. But, the --apache and --nginx plug-ins don't support that directly. In that case adding certonly along with --dry-run can be a useful test.

5 Likes

Ok. It kind of make sense to use the /live/ folder when the cert is switched to production.

I did use --dry-run first and then tested with the --staging option in case my setup needed tweaking.

The command is pretty standard. I created a custom docker image for certbot and mapped all the necessary folders perfectly so certbot can run normally.
that's what is executed.

certbot
certonly
--dry-run
--webroot
--webroot-path /var/www/html
--noninteractive --verbose --rsa-key-size 4096
--email admin@example.com
--verbose --text --agree-tos
-d us1.example.com
-d www.us1.example.com 2>&1
| tee -a $(pwd)/logs/run.log

Your command reminds me a lot of my first attempts with Certbot too :slight_smile:

Your case is one of the rare examples where using --force-renew is useful. After successfully testing with --staging you add --force-renew to your command to get a production cert. You use --force-renew ONCE because leaving it there often leads to people getting rate limited.

5 Likes

Thanks! I has once reached the limits for one of my subdmains and had to wait a week or something before I can request a new cert

2 Likes

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