Trouble renewing certificate due to incorrect IP address

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: syno-letsencrypt renew-all -vv

It produced this output: (snippet only)
DEBUG: Post Request:
DEBUG: Post value: {
“payload” : “”,
“protected” : “”,
“signature” : “”

DEBUG: Curl Reply: [200] Header: [HTTP/1.1 200 OK
Server: nginx
Date: Thu, 05 Mar 2020 08:58:27 GMT
Content-Type: application/json
Content-Length: 722
Connection: keep-alive
Boulder-Requester: 72221703
Cache-Control: public, max-age=0, no-cache
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

] Body: [{
“identifier”: {
“type”: “dns”,
“value”: “”
“status”: “valid”,
“expires”: “2020-03-29T00:34:15Z”,
“challenges”: [
“type”: “http-01”,
“status”: “valid”,
“url”: “”,
“token”: “”,
“validationRecord”: [
“url”: “”,
“hostname”: “”,
“port”: “80”,
“addressesResolved”: [
“addressUsed”: “”

My web server is (include version): N/A

The operating system my web server runs on is (include version): Synology DSM 6.2

My hosting provider, if applicable, is: N/A

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):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): N/A

I am having issues renewing the LetsEncrypt certificate for the above domain. I started with the Synology UI to do the renewal but this errored and didn’t provide much detailed information so I found the syno-letsencrypt CLI which allowed more comprehensive logs and allowed me to find that, it appears, that LetsEncrypt’s services are using an old IP address for the domain rather than what it currently is as it ends up with an error about not being able to talk to the server (which it wouldn’t if it was using the old IP address).

I have checked various DNS servers via and found that the new IP address appears to have been propogated out to DNS servers worldwide so not sure why it appears that the old IP address is being used.

Am I wrong in thinking that the validation record like the one shown is what LetsEncrypt would try and talk with to check the validity of the request and if so I wonder what next steps can be taken to try and get the request to use the new IP address?

Thanks in advance.

1 Like

The reason that particular validation record shows your old IP address is because of something called authorization reuse.

Essentially, what it comes down to is: if you prove control over a domain successfully, Let’s Encrypt will avoid asking you to repeat that proof for the next 30 days. It will just refer to the previous successful validation, including what it determined the IP address to be at that point in time. But importantly, it does not use that stale IP address for anything that affects the validation outcome, it’s just an audit trail, basically.

Authorization reuse does not apply to unsuccessful validation attempts, though. If you do not manage to prove control of the domain, then Let’s Encrypt will always repeat the full validation process, including determining the current IP address.

Hope that makes sense!

If you can find a recently-attempted authorization which is invalid (failed validation) rather than valid, it should show the correct IP.

If you can upload the full output of syno-letsencrypt somewhere (none of the logs should be sensitive - the stuff you redacted in your original post is all safe to reveal publicly), we can probably identify what the true reason for the failed validation is.

1 Like

Thanks for the detailed reply - I think I understand what you are saying and it makes sense.

I’ve actually been having a bit more of a poke around and I think some of the problem I’m having is that syno-letsencrypt seems to act very oddly when enhanced debugging is turned on so not sure if there’s some kind of race conditions in the code. When I turned the debug level down it seemed to get further along the process and I then tried replacing the certificate via the UI and it seems to have actually worked now.

Not sure if there were perhaps some load issues with LetsEncrypt servers that the Synology code didn’t seem to like or something like that but I’ll keep an eye on it in three months when it comes renewal time again and see what it does.

Thanks for your help :slight_smile:

1 Like

yes, you are absolutely right. Authorization reuse does not apply to unsuccessful validation attempts, otherwise Let’s Encrypt will always repeat the full validation process, including determining the current IP address. Thanks for the help.