Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide setting to use staging server #23

Open
exploide opened this issue Apr 22, 2017 · 9 comments
Open

Provide setting to use staging server #23

exploide opened this issue Apr 22, 2017 · 9 comments
Labels

Comments

@exploide
Copy link
Contributor

For testing playbooks and roles, it would be reasonable to tell certbot to use the staging Let's Encrypt ACME server. Especially when #12 is implemented (and for the work on this as well) since one's test environment may not have valid domain names where legitimate certificates can be requested for.

On the first glance, introducing a certbot_staging_server setting and conditionally applying --staging to certbot commands is easy. That may be enough but we should think of the cronjob and if this becomes inconsistent when the setting eventually changes.

@exploide
Copy link
Contributor Author

Thinking about this, it might be a good idea to have this in a configuration file. This allows easy changes w/o breaking cron jobs, etc.

But this wouldn't be limited to the --staging / --test-cert setting. It would allow to set all options of certbot that can be set globally. Like rsa-key-size. Guess this is a good idea anyway.

https://certbot.eff.org/docs/using.html#configuration-file

Certbot has a lot of possible settings, so I think it is inappropriate to introduce role variables for all of them. Instead I propose adding a single role variable certbot_config_file_options that defaults to an empty dict but that can be filled with all global options one wants to set. Then there is a template for /etc/letsencrypt/cli.ini that iterates over the dict and writes all the options.

What do you think? Would be nice to have a design decision. Maybe I find time to work on this afterwards.

@geerlingguy
Copy link
Owner

Yeah, definitely! I'll take a look at the PR (noting that I'd rather not merge until we can find a way to make it pass tests).

@exploide
Copy link
Contributor Author

exploide commented May 1, 2017

Ok, that's fine. While I still think this is out of scope of the PR, because the failed tests stem from the changed Ansible behavior, I would add commits to work around this if you tell me how it should look like.

@geerlingguy
Copy link
Owner

Just giving a second pass here—I still do like the idea, but one thing that may help in many cases is to have test/non-public environments generate a self-signed cert instead.

That's how I've been building my prod/test splits lately, since it allows things to work even without public internet access.

@stale
Copy link

stale bot commented Mar 6, 2020

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

@stale stale bot added the stale label Mar 6, 2020
@colans
Copy link

colans commented Mar 9, 2020

This is still an issue.

@stale
Copy link

stale bot commented Mar 9, 2020

This issue is no longer marked for closure.

@stale stale bot removed the stale label Mar 9, 2020
@geerlingguy
Copy link
Owner

I do think we should allow the use of the staging environment (e.g. for CI, local testing, etc.), so will add a label to prevent stale bot from taking down this issue.

@nekeal
Copy link

nekeal commented Jul 27, 2020

It's easy to add support for staging flag but the problem is if we want to replace a fake certificate with a valid one because certbot will not issue cert if it finds existing. So I made PR #120 which tasks check who is an issuer of a certificate and if it is Fake LE Intermediate X1 and certbot_staging_mode is set to false then existing cert is deleted. Let me know what do you think about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants