I’m making this post to get some information from users on how they find a current behavior of Certbot so we can potentially improve it. I’d like to hear from people what their first impressions were and if they found its current behavior intuitive or not. If you spend a lot of time helping people use Certbot, I’d like to see if you’ve talked with any users about this and what you’re experience was. Links to threads and conversations is very beneficial.
As you probably know, Certbot saves parameters like selected plugins, preferred challenges, RSA key size, etc. so that they can be reused during renewal. When you run certbot renew these values are picked up from the files in /etc/letsencrypt/renewal and used again to renew your certificate. This is not the case when running certbot certonly, certbot run, or certbot without a subcommand to renew or reinstall a certificate. In this case, the values used to originally obtain the certificate are ignored and the new values from the command line are used. If a new certificate is obtained, the originally saved values are overwritten.
Do you find this behavior intuitive? Have you or someone you’ve talked to been surprised or confused by it? Possible effects of a misunderstanding here include trying to install a certificate you originally obtained for Nginx in Apache, RSA key size changing unexpectedly, dropping a pre/post/renew hook, and not remembering previously specified challenge preferences for the standalone or manual plugins.
It’s worth noting that we’ve had bugs in the past where values like --preferred-challenges, --pre-hook, --renew-hook, and --post-hook weren’t saved at all (even for certbot renew). This is not the same thing. The specific issue we’re curious about is if people are expecting previously specified values for a certificate to be used with Certbot subcommands other than renew.
For what it’s worth, I’ve never personally been confused by this particular behaviour, nor do I recall encountering anyone who was. Plenty of people seem to expect renew to be even more magical than it already is, but I haven’t encountered this sort of confusion regarding the other subcommands.
@ahaw021, thanks for the input. Have you or somewhat you’ve talked to been stumped or surprised by previously specified values for a certificate aren’t used with Certbot subcommands other than renew?
personally I haven’t but there are at least 20 questions a week about renewals in the forums
some of the things I observe most
A) Issuse with the client auto update behavior - people expect just to renew and there are errors beacuse certbot can’t update
B) Users wanting to change certificates or key sizes etc
C) Users forgetting how they obtained the certificates initially etc
I usually read the manual and work through the challenges
I personally haven’t seen confusion here either. I think the conventional behavior of command line tools is to not store options between runs of the program. Many tools offer configuration files for reusing values (like Certbot does), however, these values are explicitly set by the user either by editing the config file by hand or running a command that explicitly does this like git config.
It is abnormal for a program to automatically remember options provided to a command that does something (e.g. certbot certonly/run) and then reuse them in future invocations of (other) subcommands. In general, I think doing things like this increases the amount of information a user has to understand to be able to use a tool properly. Us doing this for certbot renew makes sense; this command needs to be able to run non-interactively and obtain the cert like it did before for renewal. I think doing this for other subcommands though is likely to do more harm than good as it breaks normal conventions and makes Certbot more complex.
With all that said, I’m happy to be wrong. I just wanted to bump this thread one more time in case anyone else was willing to provide input.