My Synology NAS (DS916+) has been running around the clock on the Internet since 2007 and is constantly accessible. I have had a domain in operation for more than two years. However, since last fall, there have been problems with the SSL certificate (Let's Encrypt): I can no longer register my main domain in the Synology panel. The following message appears repeatedly: “Check that the IP address, reverse proxy rules, and firewall settings are configured correctly, and try again.”
This usually happens when the ports in the router are not open or the firewall is blocking these ports. As I mentioned earlier, my NAS has been accessible from the outside for more than 15 years. This error is buried deeper in the system. Since last year, I have been using a new Ubiquiti Gateway fiber optic router at home, which is perfectly configured. Since I operate a domain, I naturally also have a fixed IPv4 address; otherwise, the domain would not work at all. I have read a lot of advice available online, but I am not getting anywhere. I have already tried everything possible on the web interface. Now my SSL has expired at the end of 2025, and nothing works anymore. Of course, I have already deleted the existing domain entries. Last year, I wanted to set up some subdomains, which was not possible even then. Now my main domain is no longer accessible without SSL.
When I try to renew the existing certificate, this error message always appears. The same thing happens when I delete the old certificate. I guess I would have to dig deeper into the system, right?
When I looked at the logs via terminal, this error message appeared.
.
2026-01-10T17:24:03+01:00 invoked[16049]: store.cpp:229 failed to parse response: .
2026-01-10T17:24:20+01:00 syno-letsencrypt[20939]: client_v2-disk.cpp:123 Failed to open port
2026-01-10T17:24:24+01:00 syno-letsencrypt[20939]: client_v2-base.cpp:641 Failed to do new authorization, may retry with another type. [{"error":110,"file":"client_v2-base.cpp","msg":"The key authorization file from the server did not match this challenge. Expected "qpHQYr-Bi2JJsJiQ2gYtWH18rZ5gshn9x6md7V6q3m8.lHz6aTdAVljU4tmMCsRVcJlEuHSL4E1QM5SBKW-rg5g" (got "")"}
Hello @Knorrli, welcome to the Let's Encrypt community.
Without more information it is difficult to assist diagnosing remotely.
However this is worth another look to see why the port failed to open.
(something possibly has the port open?)
When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:
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. crt.sh | example.com), 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:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
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):
I don't know Synology very well but can provide more info about this.
That is an error from the Let's Encrypt server for a failed HTTP Challenge. The LE server sent the challenge but your system returned an empty response rather than the expected data. The challenge has a form like:
You could try a request like that from outside your local net to see what is responding.
The "did not match" error is distinct from more common errors like "404" which is an HTTP Not Found. This means something replied with a valid HTTP status code but returned no data.
You could check the logs for each of your devices to see which one replied. Start with the device closest to the public internet (probably your router) and work towards the server / system that should be replying.
Thank you for your prompt reply. I am happy to send you further information about my problem:
The domain is alexserver.ch and the DSM version is DSM 7.3.2-86009.
Until now, I have always created the SSL certificate via the DSM web interface. I have never had to create a certificate manually via the terminal console. I have no technical knowledge of SSL certificates. However, I am better informed on other topics. The DSM version is actually quite simple.I also used the “Let's Debug” tool you mentioned. It produced the following message: MultipleIPAddressDiscrepancy
Warning
alexserver.ch has multiple IP addresses in its DNS records. While they appear to be accessible on the network, we have detected that they produce differing results when sent an ACME HTTP validation request. This may indicate that some of the IP addresses may unintentionally point to different servers, which would cause validation to fail.
[Address=2a00:d70:0:b:2002:0:d91a:340c,Address Type=IPv6,Server=Apache,HTTP Status=200] vs [Address=77.74.81.125,Address Type=IPv4,Server=,HTTP Status=301,Number of Redirects=1,Final HTTP Status=404] Thanks
If you have multiple ips for the same apex domain, unless the same device or virtual machine is serving those IPs, validation might fail - and it still might even if its the same device.
That is a good explanation of the likely problem. You have both an A and an AAAA record in your DNS for that domain name. These are for IPv4 and IPv6.
HTTP requests to the IPv4 address get redirected to HTTPS. Following that redirect leads to a page that is related to your domain name.
HTTP requests to the IPv6 address get an http error 500 and an error page for a Hostpoint Control Panel. Do you know what that is? If not, you should remove the AAAA record from your DNS or set the AAAA record to the correct IP for your system.
Let's Encrypt prefers using IPv6 when it is configured. Cert requests will fail until you sort out the IPv6 problem.
Oh, that was my mistake last year with the domain registrar. I never knew if it was my server or if I had caused a conflict. But thanks to your help, I finally understood what the problem was! I removed the AAAA record and now everything is working. Thank you very much!
