Synology Support Broken with 3.0.7 - Unable to auth - Works fine with 3.0.6 #4721
Comments
|
Please upgrade to the latest code and try again first. Maybe it's already fixed. |
|
Confirmed, 3.0.7 breaks it. Went back to 3.0.6 and success. EditL Well, see something else changed as well with wildcard. As per #4621 Below will work when using a wildcard cert:
Notice the -k 2048 that makes it work. No more a ecc cert. |
war59312
changed the title
|
@war59312 Secondly, if acme.sh --issue --dns dns_cf --server letsencrypt -k 2048 -d *.domain.comworks, but not with Thirdly, there's no value for Additionally, I suggest you to clean your configuration from lines regarding deployment, i.e. those with Lastly, there's no point in using |
|
Just noticed, the OP is using ZeroSSL - which seems to be broken, at least according to #4723. |
|
Thanks. Yeah this was just a quick example log. Indeed, not calling to localhost, using real IP. Cleaned log. Thanks. Not real passwords anyways. Just know the behavior of this is different between versions 3.0.6 and 3.0.7. Works as expected in version 3.0.6. |
|
Using real IP is still not much better. Use a domain name as that's what LE certificates are issued for. Also, why are you still on DSM 6 instead of 7? |
|
RGR, confirms works either way (FQDN vs IP) with 3.0.6; Thanks. As for why DSM 6, it's an older DS1815+ that still works great. Don't fix what ant broke. |
Nope, wrong! Each & every person has to fix what's broken or outdated if it improves security - which is the case here as there's even DSM 7.2 available for your "old" DS1815+: https://www.synology.com/de-de/releaseNote/DSM?model=DS1815%2B Among many things, this brings an updated Nginx as well as OpenSSL which both finally support ECC-based certificates - which alone is enough to force you to upgrade. Right. Now. At least that's my point of view & I designed the new hook for security, not laziness. |
|
Now that Synonology made it easy to upgrade. Now 7.1 appears as an upgrade option within the web console. I went ahead and upgraded. Looking good. Either way, sadly support is near the end... Note 7.2 is not supported.
|
|
At least 7.1 is supported, hence you've got Nginx with OCSP as well as OpenSSL with ECC support & therefore can switch to an ECC-based certificate for improved security with less resources consumed upon each HTTPS request. And last, but not least: the deployment script should work flawlessly for you now, too! 🥳 |
|
I'll give it a shot, thanks. |
|
Recently got a problem when deploy to DSM 6.2.3-25426 Update 3. While the acme.sh decided to use the api of "entry.cgi", as follows: And get a error code of 102, which accordin to Synology Knowledge Center refers to The requested API does not exist. |
|
Update to latest version which fixes this or if not yet released, fix the script yourself by changing Besides, update to latest DSM, i.e. 7.x where the problem wouldn't even occur. @war59312 Please, can you close this issue as your original issue was fixed a while ago, yet people are still abusing it for reporting already fixed bugs? |
|
Upgrade to the latest build or use 3.0.6. |
|
Acme.sh 3.0.7 (latest) (Docker Version) works without problems on the DiskStation. |
|
@nillebor - I was trying to get the 3.0.7 running with 2FA on DSM 7.2 and I'm also having an issue. Can you please clarify which DSM version you are using? |
|
Here is some debug 3 log (even before asking for otp). It seems that the script on my synology already fails to get the api version: [Sat Nov 18 02:15:20 UTC 2023] Getting API version
[Sat Nov 18 02:15:20 UTC 2023] GET
[Sat Nov 18 02:15:20 UTC 2023] url='https://FQDN:5001/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth'
[Sat Nov 18 02:15:20 UTC 2023] timeout=
[Sat Nov 18 02:15:20 UTC 2023] curl exists=0
[Sat Nov 18 02:15:20 UTC 2023] mktemp exists=0
[Sat Nov 18 02:15:20 UTC 2023] wget exists=0
[Sat Nov 18 02:15:20 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L --trace-ascii /tmp/tmp.w7g50fgTkp -g '
[Sat Nov 18 02:15:20 UTC 2023] ret='0'
[Sat Nov 18 02:15:20 UTC 2023] response='<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<style>body{font-family:Arial,Helvetica,sans-serif;font-size:12px;text-align:center}h1{color:#06C;font-size:25px;line-height:60px;margin-top:56px}img{margin-top:40px}
</style>
</head>
<body>
<img src="data:image/jpg;base64 ... >
<h1 id="a"></h1>
<hr>
<p>© 2023 <a href="http://www.synology.com">Synology Inc.</a></p>
</body>
<script type ="text/javascript">
/* Copyright (c) 2023 Synology Inc. All rights reserved. */
(function(){var a={en:"Sorry, the page you are looking for is not found.",zh:"\u62b1\u6b49\uff0c\u60a8\u6240\u6307\u5b9a\u7684\u9875\u9762\u4e0d\u5b58\u5728\u3002",it:"La pagina richiesta non \u00e8 stata trovata.","zh-HK":"\u62b1\u6b49\uff0c\u60a8\u6240\u6307\u5b9a\u7684\u9801\u9762\u4e0d\u5b58\u5728\u3002",cs:"Hledan\u00e1 str\u00e1nka nebyla nalezena.",es:"Lo sentimos, no se encuentra la p\u00e1gina que est\u00e1 buscando.",ru:"\u0418\u0437\u0432\u0438\u043d\u0438\u0442\u0435, \u0438\u0441\u043a\u043e\u043c\u0430\u044f \u0432\u0430\u043c\u0438 \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u0430 \u043d\u0435 \u043d\u0430\u0439\u0434\u0435\u043d\u0430.",nl:"Sorry, de pagina die u zoekt kan niet weergegeven worden.",pt:"Desculpe, a p\u00e1gina que procura n\u00e3o foi encontrada.",no:"Beklager, siden du leter etter finnes ikke.",nb:"Beklager, siden du leter etter finnes ikke.",tr:"\u00dczg\u00fcn\u00fcz, arad\u0131\u011f\u0131n\u0131z sayfa bulunamad\u0131.",pl:"Przepraszamy, nie znaleziono strony, kt\u00f3rej szukasz.",fr:"D\u00e9sol\u00e9, la page que vous recherchez est introuvable.",de:"Es tut uns Leid, die von Ihnen gesuchte Seite konnte nicht gefunden werden.",da:"Desv\u00e6rre, den side, du leder efter, kunne ikke findes.","pt-BR":"Desculpe, a p\u00e1gina que procura n\u00e3o foi encontrada.","zh-MO":"\u62b1\u6b49\uff0c\u60a8\u6240\u6307\u5b9a\u7684\u9801\u9762\u4e0d\u5b58\u5728\u3002",hu:"Eln\u00e9z\u00e9st, a keresett oldal nem tal\u00e1lhat\u00f3.",ja:"\u7533\u3057\u8a33\u3042\u308a\u307e\u305b\u3093\u304c\u3001\u635c\u3057\u3066\u3044\u308b\u30da\u30fc\u30b8\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093",nn:"Beklager, siden du leter etter finnes ikke.","zh-TW":"\u62b1\u6b49\uff0c\u60a8\u6240\u6307\u5b9a\u7684\u9801\u9762\u4e0d\u5b58\u5728\u3002",ko:"\uc8c4\uc1a1\ud569\ub2c8\ub2e4. \ucc3e\uace0\uc790 \ud558\ub294 \ud398\uc774\uc9c0\ub97c \ubc1c\uacac\ud558\uc9c0 \ubabb\ud588\uc2b5\ub2c8\ub2e4.",sv:"Sidan du s\u00f6ker hittades inte."};var b=window.navigator.browserLanguage||window.navigator.language;if(-1==["zh-TW","zh-MO","zh-HK","pt-BR"].indexOf(b)){b=b.split("-",1)}document.getElementById("a").innerHTML=a[b]||a.en})();
</script>
</html>' |
|
I have several DiskStation in use and in maintenance. The whole thing has been working for a long time. Pay attention to the special characters and use a simple password for testing. |
|
Thank you very much for the detailed response! This was giving me confidence and I did another round. Two key findings:
Not sure what the difference to my other Diskstations is (except DSM 7.2). However, now it works fine. |
|
I don't know your compose. You may want to publish them. Alternatively, I always install the containers easily via SSH or the task scheduler. I don't understand your problem. Try the same diskstation on the acme.sh is the certificate installed to install? Have you adapted the firewall for Docker? Have you set a (sub)domain for the login page? Do you use the standard ports? do you use macvlan (i hope no), bridge or host? |
|
Well, I'm actually using a macvlan for a few other services. I run the container on the very same synology that needs the certificate. And I enabled a custom domain. (I far as I know I did the same on my previous synology). Here is my config for acme - And inside the As said: It now works since I changed the An improvement that I could see is to get a specific error message if the webapi call fails. Because right now the error just says "username or password incorrect". And therefore, I invested a few hours and needed to go into |
|
P.S.: And just to be complete, I used the following commands to initialize everything:
and finally a monthly scheduled job with |
|
Are you Ghost108 in German Synology Forum? I have acme.sh installed in host mode and does not need to enter an address in local. By default, an attempt is made to connect to "localhost". But this only works in host mode and is a feature of docker. If you are using a DNS_Server like Adguard, Pi-Hole or Synology, you just have to set up a rewrite. You don't have to create an extra host. If the DiskStation issues the certificate itself, i.e. internally, it also works via port 5001. Oh, you have either specified a reverse proxy entry or the domain under the login data. Even if things are going well for you now, I see potential for improvement. You can simply and conveniently place the entries in the shell directly in the container via the Container Manager or Docker (old App). if it works for you, it's good. |
|
No, I don't know any Ghost108. You are right. I use the reverse proxy feature as well, because I run some services (like influxdb, grafana and some IoT stuff) on an internal network and expose their UI via SSL secured reverse proxy. For the sake of repeatability, I like to work with docker compose (even in the old docker app). However, thanks for the hint with the deamon. I'll have a look into that. EDIT: And, yes.. I also run a pihole instance. |
|
Forget about the deamon. that's the same with me. My task (task scheduler/SSH) looks like this: in the compose you can add this here: or (with static folder) |
|
account.conf; so it's enough for the minimum (same Device) "host-mode": for all values that are not set, the preset values are used: https://github.com/acmesh-official/acme.sh/wiki/deployhooks#20-deploy-the-certificate-to-synology-dsm Edit: Please use an extra admin user and revoke the rights for apps and folders. The import works anyway. |
|
simplified the config as proposed and it works. Thank you @nillebor ! |
Synology 2 Factor Support Broken? - Unable to auth - Worked 1 Month Ago
This worked fine a month ago. Made sure correct SYNO_Device_ID is set and it is, Can see it in the URL requested.
Debug log
Edit: Hell, even if I turn off 2 factor for the account I still get the same error. So for sure, something has broken. See in an email it was last successful back on July 10 with version 3.0.6. See now on version 3.0.7.
Edit 2: Confirmed, 3.0.7 breaks it. Went back to 3.0.6 and success.
The text was updated successfully, but these errors were encountered: