Standalone not complaining about existing binding when using --force-renewal

Running in a docker container (if that matters)

I’m just running a long term test of certbot renewing a cert.

I’m running as standalone.

After a couple months I started getting the error that certbot could not bind to port 80. This makes perfect sense, since nginx was already running there. This part of the test was a partial success :wink:

Continuing the experiment… I just happen to reinstall everything, and had a new test cert. Hoping to repeat the problem.

With nginx running (on 80 and 443) (confirmed with curl and the exact renewal domain), I can run
certbot renew --force-renewal
and get a new cert ?!?

Is --force-renewal doing something sneaky and not requiring port 80 at all (maybe if the current cert is still current), even though I get the message a standalone server is launching?

1 Like

Yes, your instinct is correct.

Let’s Encrypt will not force you to repeat an authorization if your Let’s Encrypt account has recently successfully completed an identical authorization (for a variable value of “recently”, but currently ~30 days).

So when you repeat the certificate order, the authorization is essentially skipped, and you get your certificate without having to involve any webservers or authenticators.

The correct way to test Certbot’s renewal is --dry-run, not --force-renewal. This avoids using Let’s Encrypt’s production resources and avoids blowing through your rate limits.

Unfortunately … up until Certbot 0.40.0, --dry-run suffered from the same authorization reuse issue. But if you’re running in Docker, you’re hopefully running a recent-ish version (at least, newer than 1.0), so you can rely on --dry-run's results to be accurate.

2 Likes

This is diabolical. It even says

Description: Spin up a temporary webserver

Unfortunately I’m using 0.31.0, which comes with Ubuntu 18.04.4 LTS.

At least I know I’m not going crazy now :slight_smile:

1 Like