Unable to renew a certificate through Synology DSM 7.2

Help
1

Hello,

In advance, thank you for your help. I was also able to renew my certificate with no issue in the past. I am not able to say what changes in my configuration, but my renewal is now failing.

My domain is: gmgm.ovh

I ran this command: Synology DSM 7.2 certificate renewal tool

It produced this output: "Let’s Encrypt cannot validate this domain name. Please make sure port 80 is open on the Synology NAS and the router for domain validation from Let’s Encrypt over the Internet. All other communications with Let’s Encrypt are via HTTPS to preserve the security of your Synology NAS."

My web server is (include version): nginx

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

My hosting provider, if applicable, is:

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

I did a bunch of tests:
I have the port 80 opened correctly, I am able to access to http://gmgm.ovh/.well-known/acme-challenge/ and was able to see a test file, I run Let's Debug test with no issue.
However, I saw some error in the log when running Let's Debug, in the nginx logs:

2025/12/09 14:33:21 [error] 14612#14612: *1577345 open() "/var/lib/letsencrypt/.well-known/acme-challenge/letsdebug-test" failed (2: No such file or directory), client: 65.21.146.168, server: gmgm.ovh, request: "GET /.well-known/acme-challenge/letsdebug-test HTTP/1.1", host: "gmgm.ovh"
2025/12/09 14:33:26 [error] 14597#14597: *1577349 open() "/var/lib/letsencrypt/.well-known/acme-challenge/Z__ow9LosxI_reMS2jCPkVK0TyvzVo-GSpGGHImq9nw" failed (2: No such file or directory), client: 66.133.109.36, server: gmgm.ovh, request: "GET /.well-known/acme-challenge/Z__ow9LosxI_reMS2jCPkVK0TyvzVo-GSpGGHImq9nw HTTP/1.1", host: "gmgm.ovh"

Now, when I try to renew the certificate, I do not see anything in the logs, so I am wandering if I did not exceed the 5 tries for the week.

Your help is much appreciated.

Thank you!

Gaetan

2

Hello,
Not much success in my request. It is my first time on this forum. Did I do something wrong so that I did not receive any answer? Thank you for your help.
Gaetan.

3

No, nothing wrong. But, 12H is not a long time. Most of the helpers here are volunteers offering their time and experience for free.

I looked at your cert history and you are not exceeding the 5 certs in a week limit. That is not 5 "tries" it is for 5 issued certs. You are failing to get the cert.

I don't know that much about DSM personally. But, HTTP requests to your domain are currently failing from "everywhere" world-wide. That is a test to your "home" page so not related to Let's Encrypt.

To satisfy an HTTP Challenge a connection using HTTP on port 80 must work

See: Check website performance and response : Check host - online website monitoring

I'd check that your DNS still has the correct public IP. Check your router to ensure any NAT or port forwarding is still correct. That sort of thing.

Use a mobile phone and enter http://gmgm.ovh to test connections from outside your local network.

Note that I cannot connect to your domain using HTTPS either but that is not required to satisfy an HTTP Challenge that you are using.

1 Like
4

Sorry for my lack of patience. I appreciate the work you guys do to help us.
I remove my port forwarding rule this morning, as I generally do not like the 80 port open.
I just put it back, if you can do some test.
Thank you again!

5

That is expected resulted in your nginx from a Let's Debug test. It uses a test URL that is similar to an actual challenge. But, your server won't know its name so says it can't find it. Nothing wrong with that.

It's too bad DSM doesn't show the actual error provided by Let's Encrypt. The error in your first post is something DSM shows for a failure. Those are common causes but perhaps something else has gone wrong.

If you check your nginx logs after an actual cert request you should see something in your nginx access log. If nothing shows up the challenge requests are not reaching nginx. You'll need to review your network / DSN config to see why.

While I don't have DSM experience I see these kinds of DSM problems often enough. Sometimes it needs to be reset. Or, routers aren't behaving as they used to or something like that. Or a firewall is blocking the Let's Encrypt validation server IPs.

You could also try posting on the Synology forum. Or, wait for someone else here who offers help.

2 Likes
6

Thank you,
Good point about checking further in the logs. I will extend a bit my search on this. For sure, DSM certification system is not really talkative... I need to see where I can get further logs from the system.
Thank you anyway for your help. I will keep on looking and may end up changing the way I manage my certificate, maybe using a DNS-01 renewal approach, but seems a bit of an higher level for me...

1 Like
7

So, I finally found a shell command to renew the certificate from the shell:

sudo /usr/syno/sbin/syno-letsencrypt renew-all -v

I was able to get the log to sort it out: my certificate is covering several sub-domains. It comes out that one of the sub-domain dynhost was not configured properly and the IP address was not updated...
Problem solved!
Thank you for your help.

8

Where did you find it? We can pass that along when people come here for DSM problems in the future.

And, where did you find an explanation of that? Again, so we can pass it along to future posters.

Thanks

1 Like
9

Actually I found the command to run on a shell in another post:

With the verbose option (-v), I was able to get the logs associated with the command directly in the shell, and was able to pin point that the problem was coming when a specific sub-domain of the certificate was checked (sorry I did not keep a copy of the logs).

Getting back to my domain provider, I figured out that my sub-domain physical address was not correct, and finally, I discovered that the DyDNS for this specific sub-domain was not properly configured...

At the end, as often, a lot of time spent on my side for a fairly stupid mistake... And some learning: if you have a certificate that is covering a main domain and several sub-domains, make sure that each sub-domain is acceptable through the port 80 when you do the renewal!

I hope my experience will help others.

Thank you again.

Cheers.

2 Likes