I’m unable to renew my cert and get the errors below. This worked fine in June, but now errors out.
The cert was generated in standalone mode. I shut down the server on port 80 and run:
I see the http server start on port 80, but get get the following error:
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/www.example.com.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
/opt/eff.org/certbot/venv/lib/python2.6/site-packages/acme/jose/jwa.py:110: DeprecationWarning: signer and verifier have been deprecated. Please use sign and verify instead.
signer = key.signer(self.padding, self.hash)
Performing the following challenges:
http-01 challenge for www.example.com
Waiting for verification...
Challenge failed for domain www.example.com
Cleaning up challenges
Attempting to renew cert (www.example.com) from /etc/letsencrypt/renewal/www.example.com.conf produced an unexpected error: Challenges failed for all domains. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/www.example.com/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.example.com/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)
Yes. Just reran the command. All I did was sanitize the domain. I did however learn after I posted the question that the content provider that the domain name maps to is erroring when I go to the URL, so that may be the issue. I’ll work on that and try again.
In the meantime, I’m trying to get a high level understanding of this renew process for a standalone setup. Is this roughly how it works:
Shut off server
Certbot brings up it’s own server on port 80
A request is made to letsencrypt to renew the certs.
A request is made to the domain name on the cert
Understand that a lot more is going on, just trying to see if the content provider error could be causing the issue we are having trying to renew.
That's right. In this case, it appears that you previously specified --preferred-challenges http-01, which Certbot recorded in your renewal configuration file. Otherwise, it would default to using the tls-sni-01 method on port 443 instead.
I'm still puzzled about why it didn't give a more specific error message, but my best guess is that --allow-subset-of-names, an option that I really don't recommend using in most cases, is possibly suppressing the error output by making Certbot conclude that failed challenges don't need to be individually reported. If you remove --allow-subset-of-names, you might see a more specific error message here.
Thanks for the reply. Used --allow-subset-of-names since we had removed a few domains from the original request and that enabled me to renew the last couple of times. I removed it and it didn’t show anything more than what was in the original post.
My guess at this point is that Akamai isn’t forwarding the request due to a issue with them. Interestingly, sniffing the traffic it appears to only be 443 traffic when the command is running and no attempts are made to 80. Since it looks like letsencrypt uses akamai for their site, I’m assuming that the traffic I am seeing is just general comms with letsencrypt since the original call to them was to https. The attempt to contact the server on 80 seems to never come in. Hope that makes sense.
@bmw, do you know any circumstances under which we can get a failed challenge without any further explanation from Certbot of the underlying reason? I really feel like I’ve never seen that before.
I think you were on the right track with --allow-subset-of-names. I suspect it is saved as a renewal parameter in the file under /etc/letsencrypt/renewal for the cert you’re trying to renew.
Also, more information can always be found in Certbot’s logs found at /var/log/letsencrypt by default.
Just to close the loop on this. The main issue was related to a bad DNS record that didn’t allow the domain to be accessed properly. Thanks for the help.