How can I force a challenge during a renew dry run?

When I do a dry run of a renewal, it appears to skip the HTTP-01 challenge, but I specifically want it to run the challenge because I’m trying to test a pre-hook script I wrote.

The certificate was renewed recently without any problems, and the HTTP-01 challenge worked correctly, so it’s not due for renewal.

Is there an option to force it to run the challenge again?

I ran this command:

certbot-auto renew --dry-run

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/mydomain.com.conf


Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate


new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/mydomain.com/fullchain.pem



** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/mydomain.com/fullchain.pem (success)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)


My web server is:
Apache 2.2.34

My operating system is:
Amazon Linux AMI release 2018.03 on a Linux EC2 instance.

My hosting provider is:
Amazon Web Services

The version of my client is:
0.37.0

Hi @russellg99,

You could use the staging API with the certbot flag --staging without worry of rate limits. Please also see the comment at Testing renew-hooks.

Hi @Phil,

Thanks. However, I tried the following commands but unfortunately got the exact same output that I included in my original post, and it did not run the challenge again:

certbot-auto renew --dry-run --staging

certbot-auto renew --dry-run --server https://acme-staging-v02.api.letsencrypt.org/directory

Am I missing an option to force it to run the challenge again?

Try running without the --dry-run flag. I’m not sure that it’s possible to run the hooks while using that flag per https://github.com/certbot/certbot/issues/5658#issuecomment-494571968.

I would recommend using a test domain for this.

Thanks @Phil, but unfortunately there’s no change without the --dry-run flag, as in:

certbot-auto renew --staging

Without the --dry-run flag, the output shows that it’s not even simulating a renewal:

Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/zoomroses.com.conf


Cert not yet due for renewal


The following certs are not due for renewal yet:
/etc/letsencrypt/live/zoomroses.com/fullchain.pem expires on 2019-11-06 (skipped)
No renewals were attempted.


I think I need the --dry-run flag, but my guess is that since it’s been renewed recently, it’s somehow caching the fact that the challenge was successful, and is skipping a challenge when I try to test the renewal. Is there some way to uncache that information?

As a shot in the dark, I tried doing a dry run of creating a new test certificate. The first time I ran the command below, it did the challenge, but when I ran the exact same command again right afterward, it skipped the challenge:

certbot-auto certonly --debug --webroot -w /home/www_test/html -d test.mydomain.com --config /etc/letsencrypt/config.ini --agree-tos --dry-run

Output from the first run:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for test.mydomain.com
Using the webroot path /home/www_test/html for all unmatched domains.
Waiting for verification…
Cleaning up challenges

IMPORTANT NOTES:

  • The dry run was successful.

Output from the second run of the same command:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate

IMPORTANT NOTES:

  • The dry run was successful.

So clearly it’s remembering the fact that the challenge was successful the first time, but I can’t find where it’s storing that information.

Successful challenges are cached on the Let’s Encrypt side for (I think) 30 days, but the success is tied to the ACME account. So if you create a new account, you can re-test with the formerly successful domain as if it hadn’t been validated yet.

1 Like

Thanks @rmbolger! Now we’re getting somewhere.

I don’t actually remember creating an ACME account though. Can you help me with the steps I need to do to create a new one? Or to somehow simulate having a new account, so I can do multiple dry-run renewals and have it run the challenge each time?

I’m not actually super familiar with the certbot cmd line arguments. But there appear to be register and unregister sub-commands that deal with account management. Those combined with --staging are probably your best bet. Don’t get too crazy though, the staging rate limits are still only allow 50 new accounts per IP per 3 hours.

1 Like

There is a long-term proposal to make --dry-run automatically invalidate authzs in order to force revalidation whenever you use it, but @rmbolger is completely right about the current behavior and the likely best workaround.

@_az has written some code to address this in Certbot, but it hasn’t landed in the codebase yet.

Thanks for the help, @rmbolger and @schoen.

I can see in case #5116 that the perfect solution is probably coming soon. It appears that one of the commits made it into 0.37.0 but the other is still in a separate branch and being worked on.

I looked at the register and unregister arguments but I’m not clear on what effect doing an unregister will have on my existing certificates, so I backed off of that for the time being.

I have a while before the next renewal is due, so I think I’ll wait and see what happens in the next release.

Thanks again.

1 Like

That's a great point—although it doesn't invalidate or remove the certificates in any way, it would probably break certbot renew on existing certificates because they would be marked with account = and the old account ID within /etc/letsencrypt/renewal, but certbot renew could no longer use that account!

Someone should confirm this, but I’m not sure --dry-run ever executes pre-hooks, even if you need to validate again.

Thanks. Was afraid something like that might happen.

It appears to execute pre-hooks ok, even if it skips the challenge. The following command worked correctly for me:

certbot-auto renew --dry-run --staging --pre-hook “date > /tmp/x”

Output:

Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Running pre-hook command: date > /tmp/x

It's not that bad. Most people don't have any permanent staging certificates, so wiping your staging account wouldn't break anything.

If you do have any affected certificates, you can fix the renewal configuration files in a text editor.

1 Like

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