why when using --staging option the certbot tool creates certs in the LIVE folder ?
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
/live/, you should use the
I'm not sure how/why this is not what you expected?
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
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
I don't think
delete removes anything from the
/archive/ folder ...
Are you sure you didn't remove some files yourself?
I didn't delete anything myself.
delete is more comprehensive than I remember it
You are not on the same system - LOL
You didn't show the entire output
I believe it does, actually. The only things preserved if I recall correctly were
/keys/, but those don't exist any longer in the latest Certbot version.
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.
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.
--noninteractive --verbose --rsa-key-size 4096
--verbose --text --agree-tos
-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
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.
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
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.