Renewing failing on synology with Reverse proxies

I have a sinology where I created the current certificates right before the shutdown of the deprecated method back in Feb. When I got those certs I had several web-proxies that passed the certificate setup, but now that the certs need to be renewed, they are failing.

Renewal for the certs fails with

# /usr/syno/sbin/syno-letsencrypt renew -c <ID1>
{"error":200,"file":"client.cpp","msg":"new_authz: unexpect httpcode."}

Main server conf

server {
			listen 80;
			listen 443;
			     location /.well-known {
					proxy_set_header Host $host;
					proxy_set_header X-Real-IP $remote_addr;
					proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

One of the names in the second cert

server {
	listen 80;
	     location /.well-known {
             proxy_set_header Host $host;
             proxy_set_header X-Real-IP $remote_addr;
             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	return 301

(I actualy two different Ids to renew since there are too many for Synologies UI to accept, but they fail identically). I suspect there is something wrong in the main server conf file? I tried removing the listen 443; line, but no difference. I also tried simply moving the conf file for the main domain aside, but again, no difference.

Hi @LwsBtlr

I don’t understand your setup. Listen 80 and a proxy_pass to https - does that really work?

But checking your domain names there are things that can’t work.

Your sonarr ( ):

Domainname Http-Status redirect Sec. G 302 0.300 D 200 0.520 H -2 1.433 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 302 0.304 D
Visible Content: 302 Found nginx

/.well-known/acme-challenge is redirected to port 5000, Letsencrypt doesn’t follow such a redirect -> validation fails.

And your main domain ( ):

Domainname Http-Status redirect Sec. G 302 0.293 E 302 0.300 D 200 0.520 H 200 2.610 N
Certificate error: RemoteCertificateNameMismatch -2 1.443 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 200 2.520 A 302 0.304 E
Visible Content: Found The document has moved here . 302 0.300 D
Visible Content: 302 Found nginx 404 1.257 A
Not Found
Visible Content: Not Found The requested URL /.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de was not found on this server.

The non-www /.well-known/acme-challenge is redirected to https + www + - does your Letsencrypt client really saves there the validation file?

The www version /.well-known/ is redirected to the root and port 5000 -> that doesn’t work.

Looks like there are too much different things. The port 5000 isn’t visible in your definition. Same with the other domain.

You can’t listen to HTTP and HTTPS in the same block - choose one.

There are four W’s in that name… is that intentional?

Yeh, I have no idea what is going on here. There is not mention of anywhere in the entire nginx configuration, nor of port 5000 in any of the reverse proxy settings or the sites-enabled files, thought it is the default port the synology users for its DSM web face, nor any idea why is showing up for you anywhere as that is an entirely different IP (one of the name servers for my domain).

I copied the location block from another post here (minus the wwww tyop). About Letsencrypt behind a reverse proxy

Fixing the wwww issue results in a different error.

{"error":102,"file":"client.cpp","msg":"Invalid response from []: \"<html lang=\\\"en\\\">\\n<head>\\n    <title>SABnzbd - Log in</title>\\n\\n    <meta http-equiv=\\\"Content-Type\\\" content=\\\"text/html; charset=utf\""}

So the location block isn’t doing what I expected it to do, as that is the login page for sabnzbd (its sites-enabled file is essentially identical to the sonarr one, other than the server name).

The sub domains now load properly, so all of that configuration failure seems to have been caused entirely by the typo in the proxy line. One other thing that is not obvious here is that the main domain is setup for HSTS, so it is https: only.

changing the proxy to http:// and disabling HSTS has not made a difference.

Then your nameserver settings are wrong.

So every check (my tool or Letsencrypt) checks the wrong ip address.

All those errors in your check were caused by the wwww typo.

Your last check ( ) shows a new error:

http + /.well-known/acme-challenge/unknown-file is redirected to https (this is ok) and the “/”, that’s bad. Letsencrypt can’t find the validation file in your root directory.

A redirect shouldn’t remove the REQUEST_URI (folder and file name):

RewriteEngine on
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

(~~ same with nginx).

yes, the 301 is intentional. The purpose of the reverse proxy is to have these services on my synology on a https connection.

So proxy_pass; should be proxy_pass$request_uri;?

I’ll give that a shot.

Wel, that gets back to the {"error":200,"file":"client.cpp","msg":"new_authz: unexpect httpcode."} error. :smiley:

The main question: Does your Letsencrypt client knows that configuration?

What client do you use? Which authentication?

If the Letsencrypt client saves the validation file in another directory, that can’t work.

Synology has its own (somewhat opaque) letsencrypt setup. I’m getting 502 errors or 301 error, depending on the configuration, when trying to look at .well-known, it seems like the location /.well-known block is ignored if the return 301 is there.

If you use the Synology integrated solution:

Perhaps you should redirect http + /.well-known to your Synology http + /.well-known, not to https.

If Synology uses own location definitions (http + /.well-known), that can’t work if you create a https redirect.

I have “solved” the immediate issue by moving aside all the site-enable files, renewing the certs, and putting them back. Not ideal, but it’s either that or leave the subdomains open to http requests.

yes, I tried that.

I will continue to try various things now that I have another 90 days.

It’s possible, though usually sites should have separate server blocks with different settings. (E.g. a redirect to HTTPS in the HTTP block, and an HSTS header in the HTTPS block.)

listen 80;
listen [::]:80;
listen 443 http2 ssl;
listen [::]:443 http2 ssl;

You can do something like:

location / {
location /.well-known/acme-challenge/ {

Yeah, I did try that.

server {
	server_name ;
	listen 80 ;
	location /.well-known {
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	location / {
		    return 301 ;

Trying to access with curl returns a 502 error. Trying to access it in a web-browser redirects to ¯_(ツ)_/¯

Yep, that’s your last check-result.

But that’s the problem - your Synology may not understand that.

man, I thought I had this figured out. The Synology-created nginx.conf has the following:

OK, This DID work. I forgot to check specifically for the acme-challenge subdirectory.

location ^~ /.well-known/acme-challenge {
  root /var/lib/letsencrypt;
  default_type text/plain;

{EDIT} Certs renewed with this configuration

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.