Dry run fails to renew after succesfull generations of certificate


Not sure why challenge is via not domain it self.

My domain is: nycos.co.uk

I ran this command: sudo certbot renew --dry-run

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/www.nycos.co.uk.conf

Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.nycos.co.uk
Waiting for verification…
Cleaning up challenges
Attempting to renew cert (www.nycos.co.uk) from /etc/letsencrypt/renewal/www.nycos.co.uk.conf produced an unexpected error: Failed authorization procedure. www.nycos.co.uk (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from []: “\n\n400 Bad Request\n\n

Bad Request</h1”. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/www.nycos.co.uk/fullchain.pem (failure)

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

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/www.nycos.co.uk/fullchain.pem (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)

1 renew failure(s), 0 parse failure(s)


My web server is (include version): Apache

The operating system my web server runs on is (include version): Ubuntu 18.04.1 LTS

My hosting provider, if applicable, is: Azure

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no


Hi @digijuice

It’s the IP the domain is resolved to. The HTTP Host header of the request is set to the domain name. This is more or less how things have always worked but it has been less visible in the returned validation records and errors. This is part of a refactor/bugfix that’s only enabled in staging presently.

Do you have anything in your server-side logs that might indicate why the response was a 400? Am I correct in assuming you haven’t changed anything in your configuration since your last successful dry-run? (Edit: Not required, its definitely a bug on our side. See my next reply)

This is the second report of trouble I’ve seen with staging’s HTTP-01 validation this morning. I’m working on reverting the feature flag that enabled this new code in staging while I verify whether there is a regression.



Following up: The refactor code in staging has now been disabled. You should find that staging validations for your domain are working again.

With your report and the other report I was able to spot the bug. Your server is returning a redirect to the original HTTP-01 challenge request that sends it to HTTPS. This is a valid use case and should be supported, but it looks like I introduced a regression here and the new code activated in staging yesterday is constructing a URL for the redirected HTTP fetch that has an http:// protocol but is directed to port 443. That’s certainly wrong (Edit: Interested folks can track the fix in Boulder Issue 3956).

Thanks again for posting in the forum. Apologies for the trouble!


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