acme.sh / Synology DS1821 / dyndnsfree.de

[*kw*]

Bei OTP Code hab ich dann einfach nochmal das Passwort von nasadmin (mein Admin) eingegeben

@Benares: nachdem ich jetzt wenigstens wieder "testen" kann, meinst du mit "OTP" das normale Benutzerpasswort? Also kein TOTP?

Im Moment ist es schwer zu differenzieren, wie a) die aktuelle account.conf auszusehen hat und b) inwieweit die aktuelle acme-Version hier - störend - die Finger im Spiel hat?

Ich bin im Thema "Zwangs-2FA" noch über den Tipp gestolpert, dass man sich mit den "Cert-Admin", obwohl der keinerlei Rechte benötigt, im DSM anmelden und hier den 2FA speichern soll (Häkchen setzen, keine Abfrage mehr). Das würde lokal gespeichert werden und steht im Zusammenhang mit dem deployhook.

Sind aber alles nur Brotkrumen, die kein wirkliches Ganzes ergeben.

 

[Benares]

Ach, ich weiß es nicht. Bei nicht vorhandener Device_ID wird ja initial nochmal nach einem Passwort für den Benutzer gefragt. Bei nicht vorhandener 2FA ist das einfach nochmal das Passwort des Benutzers (ähnlich wie bei ssh bei "sudo -i"), bei aktivierter 2FA das ein 2FA-Einmal-Passwort für diesen Benutzer, so wie ich das verstehe.
Daraus wird in beiden Fällen eine Device_ID erzeugt und gespeichert, die künftig dafür sorgt, dass es auch ohne 2FA geht. So zumindest mein Verständnis.

 

[*kw*]

Ich versuche mal, meine aktuellen Erkenntnisse nachvollziehbar aufzuarbeiten und fange am besten von hinten an.

Fakt ist, das acme.sh Script setzt künftig auf mehr Sicherheit, was sich in den verschiedenen Version bemerkbar macht, bzw. gemacht hat.

• 3.0.6 arbeitet(e) noch mit SYNO_TOTP_SERECT, kam mit weniger Parametern in der account.conf aus
• 3.0.7 hat als "Zwischenversion" ein paar Probleme verursacht, weshalb einige User wieder auf 3.0.6 zurückgewichen sind
• 3.0.8 setzt auf das neue "Script-Verfahren" beim deployhook

Bei der Stand-Alone Version sind viele Probleme mit der DS in v3.20 behoben, für Docker keine Infos

Fixed:
* fix 2FA support in Synology automation (#3627)

Für den deployhook sind für das acme.sh DSM-Script folgende Werte notwendig (DNS-API Daten sind kommen natürlich weiterhin in die account.conf)

# Usage:
# - export SYNO_Username="adminUser"
# - export SYNO_Password="adminPassword"
# - export SYNO_Certificate="" to replace a specific certificate via description
# - export SYNO_Scheme="http"
# - export SYNO_Hostname="localhost"
# - export SYNO_Port="5000"
# - export SYNO_Device_Name="CertRenewal" - required for skipping 2FA-OTP
# - export SYNO_Device_ID=""              - required for skipping 2FA-OTP

Um dem neuen/künftigen Verfahren Rechnung zu tragen, habe ich jetzt einen "acme-Admin" mit 2FA eingerichtet. Beim Passwort drauf achten, dass kein '$'-Zeichen vorkommt. Am besten erstmal mit einem Einfachen testen.

Ich hänge aber am OTP fest und es kommt zu Fehlermeldungen.

[Mon Feb 12 15:34:20 UTC 2024] Unable to authenticate to http://localhost:5000 - check your username & password.                                              
[Mon Feb 12 15:34:20 UTC 2024] If two-factor authentication is enabled for the user, set SYNO_Device_ID.                                                      
[Mon Feb 12 15:34:20 UTC 2024] Error deploy for domain:meinedomainde              
[Mon Feb 12 15:34:20 UTC 2024] Deploy error.

Beim --debug 2 kommt folgende Hinweis-Meldung:

webapi/entry.cgi?api=SYNO.API.Auth&version=7&method=login&format=sid&account=user&passwd=<password>&enable_syno_token=yes&device_name=CertRenewal&device_id=DS-NAME'

Das ist lt. DSM-API-Guide die Anforderung "Login with omitted OTP".

Ich würde ja gerne mit OTP, also DSM-Variane "Login with OTP".

webapi/entry.cgi?api=SYNO.API.Auth&version=6&method=login&account=<USERNAME>&passwd=<PASSWORD>&otp_code=<OTP_CODE>

Also Device_ID und Device_Name auskommentiert (s.o., required skipping), neu gestartet und dann kommt beim deploy die Aufforderung für OTP. Das ist lt. Neil Pang auch derzeit (noch) die Vorgehensweise, dass das Secret nicht mehr im Klartext an die CA übermittelt, sondern lokal abgespeicher wird.

Ganz wichtig (neu): im Gegensatz zum SYNO_TOTP_SECRET wird hier nicht - wie öfter gelesen - das Secret eingegeben

otpauth://totp/Nutzername?secret=XO5JKX9LNIP5UXXKQ4CPIX2TEFHG6&digits=6

sondern einmalig eine aktuelle 6-stellige TOTP-Zeichenfolge aus der User-Auth, bspw. 613 784.

Das einzig schöne, der Cert-Deploy lief fehlerfrei und mit dem derzeitigen kann ich wenigsten so viel den "hook" testen, wie ich will, sofern es nicht weiterhin an acme.sh liegt und...

“Es ist verrückt, immer wieder dasselbe zu machen und neue Ergebnisse zu erwarten.”

Es wird nicht langweilig...

PS: wer noch nicht renewen musste , hat evtl. Glück. Aber um die Jahreswende müssen die Probleme angefangen haben.

 

[*kw*]

Jetzt habe ich nur noch Unable to update certificate, error code {"error":{"code":5514},"success":false}.

Ich hatte auch den Tipp umgesetzt, sich mit dem "acme-Admin" (mit 2FA) im DSM anzumelden und die OTP-Eingabe "zu merken". Man ist sich noch uneins, ob's wirklich was bringt. Der händische "Workaround" wird auch in github beschrieben.

Ansonsten steht ein Entwickler (Eagle3386) in Kontakt mit Synology weil es einen bug gibt. Wer hätte das gedacht...