Faster iteration for `certbot certonly --staging --manual --preferred-challenges http --manual-public-ip-logging-ok --agree-tos --eff-email`


I’m attempting to integrate certbot into our cloud servers and because of some specific requirements, I have to use the flags from the title and steer the certbot process with scripts.

This implies in principle using expect or variants - as I haven’t found any flag for certbot to generate output in a machine-friendly format.

In order to test all cases while I develop my script, I would need to wait 90 days in some cases, which is not really acceptable.

Is there any way to tell certbot to give me a certificate which is valid for only 30-60 minutes or so?

Additional question: since a machine-parsable output would improve the development time, is there something to make it give me the path to .well-known/acme-challenge/ and its contents in a friendly format like json?

Nope. There isn’t a way for certbot to tell Let’s Encrypt to do so either.

You can add --force-renewal to your certbot renew command to test it without waiting 60 days.

If you can parse JSON your script probably isn’t a shell script and you can use one of the client libraries for your language of choice.

If it really is a shell script, unfortunately none of the clients seem to advertise machine readability from shell scripts as a feature. But I recall a few of them do at least separate obtaining a verification token, the actual verification, and issuance into separate commands so you wouldn’t have to use expect, though I don’t remember which ones offhand.

1 Like

Are you aware of the --manual-auth-hook and --manual-cleanup-hook options? Sounds like they might be useful in your situation.


As a reminder: when developing something, please use the staging server (--staging).

This won’t trouble the Let’s Encrypt servers with the extra load and doesn’t have the strict rate limits as production has.

The title clearly mentions it.

Whoops, missed it,sorry!

Hi @flavius

If you want this level of control while you’re testing I recommend that you try setting up Boulder, the Let’s Encrypt server-side CA software that Certbot communicates with. The quickstart guide should be enough to get going. You can refer to the working with a client section of the README to see how to use Certbot with your local Boulder instance. You would want to edit test/config/ca.json and the expiry values to change the lifetime of the issued certificates.

No, but you can edit /etc/letsencrypt/renewal/ for your domain after the certificate has been issued and put in something like renew_before_expiry = 100 days at the top which says that the certificate should be renewed by Certbot when it will expire in less than 100 days. Since Let’s Encrypt certificates are only valid for 90 days, this means that certbot renew will try to renew that certificate as soon as possible. This is similar to the behavior that would normally happen with Certbot beginning 2 months after the issuance of the certificate.


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