Not seeing port 80 traffic during webroot renewal

I’m trying to test how we are deploying and renewing LE certs and I’m getting a bit thrown by the behaviour of the setup at a certain point.

During initial request, we’re using standalone mode as our deployment setup won’t be expecting a web server to be installed and/or configured.

For renewal, we will have installed and configured Apache to use the LE certs, so we’re using the webroot plugin.

What is throwing me, though, is that neither the Apache logs nor tcpdump are showing any traffic on port 80 during a renewal of the cert. For testing purposes, I’m using the staging instance and forcing renewal. Here is the command and the output generated:

/opt/certbot-auto --staging renew --post-hook "service apache2 reload" --webroot -w /tmp/acme-challenge --force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/
Starting new HTTPS connection (1):
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
Using the webroot path /tmp/acme-challenge for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0015_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0015_csr-certbot.pem

new certificate deployed without reload, fullchain is

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/ (success)
Running post-hook command: service apache2 reload

I’ve even blocked incoming port 443 and port 80 traffic and the renewal still succeeds.

What am I misunderstanding here?


There are a few things here … The main one being that once you have verified and authorized control of a domain then the ACME server remembers this for a period of time ( currently 60 days, but will reduce to 7 days probably at some point. Since you are already authorized (using that account key) then it can issue a certificate without needing to verify again.

There are a couple of options here for you in testing. 1) you can deactivate ( see Authorization deactivation ) or 2) you can simply change the account key you use for the staging server, then you won’t already be authorized, and it will go through the full process.

Personally, I deactivate the authorization every time after successfully getting certificate, since (to me ) that more closely represents the reality of what will happen in reality. I’ll be using the same key, which won’t already be authorized )

On a separate issue, I’m not sure if the “renew” will work - as it will try and renew by the method you used first time - i.e. standalone mode, which is not what you want. I think the above (remembering the authorization ) is the main issue you are hitting first though

Thank you for your explanation of what is happening here.

As I’m using certbot, I think that trying to create a signed message to deactivate is going to be tricky. Unfortunately, we’ve put a lot of effort into the automation around certbot that trying to switch tools now would be difficult.

So I’m trying to understand how to achieve (2), changing the account key. I can see where certbot stores the account information but what do I actually need to do to change the key?


The easiest whilst testing is simply to delete the account key. certbot should generate a new one.

Thanks! I’ve managed to successfully confirm (and fix!) the renewal of certs now.

1 Like

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