How I WISH Certbot Worked

Bear in mind that this is just one man's fantasy for what he believes would make for a saner world...

I feel that certbot's usage has become overly convoluted. Perhaps taking on a little RISC might help.

Hear me out completely, please, before commenting. The following represents what would be beyond the handbook I am still drafting as information becomes firm.

For starters... get rid of:

  • run
  • --keep, --keep-until-expiring
  • --expand
  • --duplicate

  • Rename certonly to acquire
  • Rename --dry-run to --test
  • Add a clear function to clear all settings for a certificate without erasing the certificates and keys
  • Add a backup function to backup everything to a single file (outside the certbot directory structure)
  • Add a restore function to restore everything from a single file (outside the certbot directory structure)
  • Add a 'sweep' function that sweeps everything (basically clears the entire ceftbot directory structure)

Mandate strict syntax:

certbot clear certname

certbot acquire certname authenticator "domain,name,list"

certbot install certname installer

certbot backup file

certbot restore file

Make certain that all used settings are saved. This includes those used for install.

Make --keep-until-expiring the default functionality that can only be overridden by --force-renewal.

Ensure that renew is coded internally to use acquire and install with the saved settings in exactly the same fashion as would be expected on the command line.

Definitively demarcate acquisition versus installation outputs in the logs.

The benefits of completely segregating the acquisition and installation processes are many. Here are but a few:

  • drastically reduced acquisition of duplicate certificates
  • surety that acquisition has succeeded when incrementally executing/debugging
  • clear distinction between usage of authenticators and installers

This is great feedback! I know the Certbot team has often wished to revamp the command line user experience, but has been hesitant to do so because there are so many people out there using it whose cron jobs or other scripting would break. Of course, Certbot has now reached 1.x, which opens the possibility of compatibilty-breaking changes in some future Certbot 2.x. :slight_smile:


Thanks. :slightly_smiling_face:

I predict that several of these recommendations could substantially reduce the waste of Boulder's resources.


May I add that when someone has created a duplicate certificate, that instead of an error message that only states Too many certificates have already been created for this domain..., include what @Juergen and so many others have to tell users to do: Use the certificate you have already created.

So many times some people just constantly create cert after cert until they reach the rate limit. Yes, sometimes it's because they use the wrong command (certonly) instead of the testing environment, but other times they'll see the creation was successful but don't know or understand how to install the cert... so they repeat the process again and again.

1 Like

I actually wonder if it'd be more helpful to add another rate limit, along the lines of no more than 2 duplicate certificates within a half hour (or maybe an hour). So people just doing the same thing over and over again would see an error earlier, but yet haven't used up their entire 5 for the week yet. (But I suppose this is getting off-topic.)


@petercooperjr, that would probably catch quite a few of these non-persistent Docker situations!

You know something else that might be useful: an HTTP header that somehow connotes "this resource was moderately expensive to provide to you; please don't make this request in an automated way in a non-persistent environment". Then we would need HTTP clients that run in Docker (etc.) to be able to notice the combination of "I'm non-persistent and automated" and "the server says this is expensive" and generate a warning to the user. (That's quite a few pieces to coordinate, but on the other hand it degrades gracefully because if any piece is missing, the notification just doesn't happen.)

I also imagine that this could be useful for testing environments that spin up a whole virtualized environment and install dependencies or package updates there, then immediately destroy that environment. (I'm not sure what the maintainers of those environments would be willing to do as an alternative in order to have greater persistence, but I bet they can do better than their current naive solutions.)

(like I remember Certbot was using Travis, and it at least gave the appearance of downloading an enormous quantity of dependency packages into a VM to run a fresh test for every single commit on a PR branch!)


I think the backup and restore commands could do worlds of good in environments like what you have described, @schoen. :slightly_smiling_face:

Initial spinup workflow:
certbot acquire mycert ...
certbot install mycert ...
certbot backup mycert

Subsequent spinup workflow:
certbot restore mycert
certbot renew --deploy-hook "certbot backup mycert"

The renew would need to use/check the installation. No duplication. Complete automation.

1 Like

Would it make sense to have if successful create backup for newbies? I think there could be two reasons this would be good for:

  1. Someone has created duplicate certs and reached the rate limit... and deletes their certs and tries to start all over. Surprise! They've still hit the rate limit, but now they don't have a cert we can help them use, unless they wait until the time limit has passed.
  2. When people say they don't remember how or what they did when they got their last cert.

Or would creating a backup for each successful cert be too much load on the servers, seeing how many certs are issued every day?

1 Like

I think you're hitting into what I wrote to schoen above. The backups would be local though (and overwritten on each successful deployment via the --deploy-hook).

1 Like

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