Need help replacing expired certificate with Synology

Help
1

Happy I am with LE, let me start with a thank you for your lovely certs service. I am trying to replace an existing certificate on my server. Below is as much as I know. I tried solving it myself reading the LE forum, but still stuck on the same (general) error. Any help is much appreciated.

My domain is: droeska.nl

I ran this command: first I tried to "renew" the existing expired cert without success, then "add new" replacing the existing cert. In the last case I have provided the domain, an email and subject althernative names: vpn.droeska.nl;nas.droeska.nl;music.droeska.nl;unifi.droeska.nl;foto.droeska.nl;file.droeska.nl;www.droeska.nl;67.droeska.nl;www.cubicletree.nl;cubicletree.nl;mail.droeska.nl;mail.cubicletree.nl;3in1winkel.droeska.nl;portainer.droeska.nl;code.droeska.nl

It produced this output (for both cases): "Please check if your IP, reverse proxy and firewall rules are correctly configured then try again"

My web server is (include version): Sysnology Web Station, nginx

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

My hosting provider, if applicable, is: yourhosting (DNS only), hosted locally

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): not sure, couldn't retreive

What I already checked:

  • It managed to obtain the previous ssl cert from let's encrypt (but changes made?)
  • I tripple checked my forwarding rules and firewall (even disabled didn't help); 80 and 443 are open.
  • https://letsdebug.net is providing an 'all clear', after I removed my ddns domain form the subject alternative name list.

The server has reverse proxy setup for most of these (sub)domains, I have the feeling this might be (part of) the issue, but find it hard to debug
Could the following be the culprit?
$ curl -I4 -m8 http://www.droeska.nl
HTTP/1.1 301 Moved Permanently
Date: Thu, 09 Oct 2025 19:53:45 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Keep-Alive: timeout=20
Location: https://droeska.nl/

2

that error message isn't really helpful: can you post releative logs from its log center?

1 Like
3

Hello @Dnango,

Here is a list of issued certificates crt.sh | droeska.nl, the latest being 2025-09-02.
That being this certificate crt.sh | 20739243940, so it looks like the renewal happened properly. The webserver doesn't seem to be serving that certificate.

            X509v3 Subject Alternative Name: 
                DNS:*.droeska.nl
                DNS:droeska.nl

Have you restarted the NAS' webserver, probably the simplest way would to reboot the NAS.

4

Thanks for the quick reply. Are you saying the certificate is stil there? The certficate expired at my end.

This seems registered for *.droeska.nl which is strange since I cant use wild cards on my server. I did have that in my DNS records a month ago, but made it specific for all sub domains now. Does that matter. Rebooted. Same result: same error messsage.

1 Like
5

Good question, thanks. I am trying to figure out how to get to more specific logs on the LE registration process on the server, no luck yet. Will try again tonight.

1 Like
6

This is what I am seeing:

afbeelding
afbeelding2064×446 50.1 KB

7

want raw log in menu-'log center'

1 Like
8

Found this message in the raw log (cat /var/log/messages | grep syno-letsencrypt* - 'log center' doesn't provide info in my case)

2025-10-10T11:34:25+02:00 nasi syno-letsencrypt[9760]: client_v2-disk.cpp:117 Failed to open port
2025-10-10T11:34:28+02:00 nasi syno-letsencrypt[9760]: client_v2-base.cpp:603 Failed to do new authorization, may retry with another type. [{"error":110,"file":"client_v2-base.cpp","msg":"95.99.110.20: Invalid response from https://3in1winkel.droeska.nl/.well-known/acme-challenge/wyzx5KrWjkTGmzfyQ57S-N09WFOGrPckdsGsdc19y1I: 404"}

2 Likes
9

After further investigation, added a reverse proxy for port 80 for the 3in1winkel.droeska.nl. Turned of the server firewall - that did not solve anything. Could the "failed to open port" hint on something else? Did a test to see if the acme-challenge folder is accessible; it is. In nginx I have the following redirect script (http > https) for the hosted sites (forgot about it, is responsible for the 301 message mentioned at the topic start):

server {
listen 80;
server_name 3in1winkel.droeska.nl www.3in1winkel.droeska.nl;

# Allow Let's Encrypt challenge
location ^~ /.well-known/acme-challenge/ {
    allow all;
}

# Redirect www to non-www
if ($host ~* ^www\.(.*)) {
    return 301 https://$1$request_uri;
}

# Redirect to HTTPS
return 301 https://3in1winkel.droeska.nl$request_uri;

}

Any ideas? Is it the redirect, with the reverse proxy? I am in over my head here, overlooking something (forrest, trees...) It seems to be the 3in1winkel subdomain particularly. I am not seeing errors for the website at droeska.nl which has been setup the same way. Or does the process stop at the first error?

10

not sure, but it was may try to run standalone server at port 80 but failed to do so because nginx was already binding that port. unlikely though.

anyway, I still see redirect to http on acme-challenge subdir so that nginx config isn't what handling redirect to https.

11

Well presently I see

$ curl -k -i http://3in1winkel.droeska.nl/.well-known/acme-challenge/wyzx5KrWjkTGmzfyQ57S-N09WFOGrPckdsGsdc19y1I
HTTP/1.1 301 Moved Permanently
Date: Fri, 10 Oct 2025 22:12:48 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Keep-Alive: timeout=20
Location: https://3in1winkel.droeska.nl/.well-known/acme-challenge/wyzx5KrWjkTGmzfyQ57S-N09WFOGrPckdsGsdc19y1I

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

And following the redirect.

$ curl -k -i https://3in1winkel.droeska.nl/.well-known/acme-challenge/wyzx5KrWjkTGmzfyQ57S-N09WFOGrPckdsGsdc19y1I
HTTP/2 200
date: Fri, 10 Oct 2025 22:12:04 GMT
content-type: application/octet-stream
content-length: 6
last-modified: Wed, 04 Jun 2025 21:36:40 GMT
etag: "6840bc68-6"
strict-transport-security: max-age=15768000
accept-ranges: bytes
strict-transport-security: max-age=15768000; includeSubdomains; preload

hello
1 Like
12

Thanks for the checkup Bruce, Orangepizza. @Orangepizza, I tried figuring out what is handeling the redirect and influence it but on DSM that is a bit of a maze, the system has its limits. @Bruce5051 At least that confirms the location is reached following the redirect. I've put the file there manually to check this. Understanding it is the redirect that is causing trouble... So I'll try take that out completely (first the manual script, then the reverse proxy if needed, maybe webstation is involved) and see what it does.

13

Alright I finally fixed the issue and got my cert replaced. I'll explain for someone running into similar issues. Basic solution: making sure the custom config was accepted. Deleted the existing custom script (that didn't make a difference as orangepizza concluded) because it was ignored by nginx at startup. Didn't touch the reverse proxy (where all on port 443). I have not been able to track the issue of the "persistent https redirect" back to its origin. Maybe what synology calls the Login Portal > Applications was involved, but it could also lie in WebStation (all my sites are setup for 443 only), anyway happy to hear ideas. Checked the Nginx config to see if there was anything responsible for the redirect. Because it seemed the exception for the acme challeng on port 80 was twarded by the redirect to https - which I did not find in my nginx config - and that my custom config script (to circumvent this) was not picked up on (thanks again for the help there). By the looks of it because nginx was registring it as a 'double config' (same domain twice). Again, before I went down this lane I tripple checked both firewalls I have running. On the NAS the location of the certs is somewhere "deep" in the system, which location I had mistakenly scripted. So ultimately I placed one general script that is situated in the /etc/nginx/conf.d folder to rewrite the behavior for all "other domains" (other then functionality of the system is providing itself) to create an exception on the acme challenge on port 80 (normally redirected because all my hosted sites are at port 443), which includes the proper cert folder location for DSM 7. I'll add it here for use or improvement on the solution (happy to hear back on this, mind you I am no specialist):

server {
    listen 80;
    listen [::]:80;
    server_name ~^(.+)$;

    # Allow ACME challenge for Let's Encrypt
    location ^~ /.well-known/acme-challenge/ {
        root /var/lib/letsencrypt;
        default_type text/plain;
        try_files $uri =404;
    }

    # Redirect all other HTTP traffic to HTTPS (preserve hostname)
    location / {
        return 301 https://$host$request_uri;
    }
}

The fix will probably be overwritten when I update the system. Let me know what you think. Is this a solid solution? I am inclined not to further dive in, as my certs now work again. Also if you have tips on my first LE community interaction, let me know.

1 Like
14

Forgot to mention that near the end of the nginx configuration file (.../nginx/nginx.conf) there is a hook I used: include conf.d/http.*.conf; The script file name is based on that. (tried edditing my earlier post but can't)

15

@Dnango Would you mind explaining to a noobie how to make this work? I just hit this, I had a working cert and it would not renew, so I tried making a new one.. not working so now I have no cert.

I turned off all firewall, everything... ports are open, nothing works. LE on Synology is garbage.

thanks for the help!

16

@Ltek If you post a new thread here a volunteer may offer advice. Please answer as many of the questions you will be shown. There are any number of reasons it may not work. The details matter.

You might also try: https://community.synology.com/enu/forum/1
Or their Knowledge base

2 Likes
18

My setup is nearly identical to @Dnango ... I have 1 firewall (which I turned off to try making this work). The router's Port Forwarding sends all 443 and 80 TCP/UDP and Synology Reverse Proxy with port 443 in, and port 80 out for the apps - and the domain name itself sending 443 & 80 to the general domain name will be sent directly to the NAS's IP address.

I have been through everything for 2 days on this. Last year the cert renewed just fine with the same setup after I disabled the firewall, now it is not. What @Dnango posted sounds like will fix my problem I'm just not understanding what he means by this...

Forgot to mention that near the end of the nginx configuration file (.../nginx/nginx.conf) there is a hook I used: include conf.d/http.*.conf; The script file name is based on that. (tried edditing my earlier post but can't)

and where do I place the script, and what to name it...

server {
listen 80;
listen [::]:80;
server_name ~^(.+)$;

# Allow ACME challenge for Let's Encrypt
location ^~ /.well-known/acme-challenge/ {
    root /var/lib/letsencrypt;
    default_type text/plain;
    try_files $uri =404;
}

# Redirect all other HTTP traffic to HTTPS (preserve hostname)
location / {
    return 301 https://$host$request_uri;
}

}

20

Are you still using similar groups of domain names as you did in your prior thread?

Because the DNS settings for some of those domains differ considerably. Please start a new thread. We don't like to mix different problems in the same thread. It gets confusing for all concerned very quickly.

3 Likes
21

I just want a bit more info on the Solution from This Thread. I'm not trying to solve a different problem

Everything has been working fine for 2 years, until yesterday. I suspect its a change in the Synology DSM and the Op has the solution in this thread

btw, my last post was in 2023 and a totally different issue; I was putting 'www' on the domain list.

22

Thanks for the questions @Ltek.
First of let me stress: in my case I needed this fix because I want all web traffic to redirect to https. Your case is plausible to be different as @MikeMcQ already suggested. Now to answer your Q.

include conf.d/http.*.conf

  1. This means the file you place in the conf.d folder of the nginx environment on the NAS (you need to ssh into your machine and use root privileges to create the file there). In my situation the location was /etc/nginx/conf.d. Assuming you have some basic linux skills you will find this without too much trouble.
  2. Any name of that file that conforms to the format http.*.conf will be picked up by the general nginx config script when (re-) starting nginx. Again creating the file requires basic linux commands (vi) and root.

After creating the script in the conf.d folder you'll need to restart nginx (or webstation or the NAS). If it doesn't help remove it since it is a 'catch all' solution and it might intervene with the (system) webservices of the NAS.

1 Like