acme.sh / Synology DS1821 / dyndnsfree.de

[*kw*]

Was mich halt wundert, dass ich alles so umgesetzt habe, wie es beispielhaft für http-Variante dargestellt wird. Dennoch haut er beim issue die TOTP-Abfrage raus, obwohl nicht gesetzt.

1. TOTP
2. SYNO_Device_ID

wenn man beides skipped, weil nicht gesetzt, kommt der "user data & passwort error".

Fast ein bisschen wie "Katze <> Schwanz"

Dann setze ich für den nächsten Test 2FA und tippe es rein. Mal sehen, was dann passiert?

Wichtig: nicht mehr als 5 issues in 168 Stunden

 

[Benares]

@*kw* , ich denke, du hast dich inzwischen genauso "verbastelt" wie @FleischFlori. Wie gesagt, 2FA nutze ich nicht.
In meiner account.conf habe ich nur folgendes drin:

export NC_Apikey="key"
export NC_Apipw="passwort"
export NC_CID="cid"
export SYNO_Username="DS_AdminUser"
export SYNO_Password="DS_AdminUser_Passwort"
export SYNO_Certificate="*.example.com"

Die Zeilen kamen automatisch hinzu:

AUTO_UPGRADE='1'
DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'
SAVED_NC_Apikey='key'
SAVED_NC_Apipw='passwort'
SAVED_NC_CID='cid'
USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
UPGRADE_HASH='de14d59bb38acc66972787e1f4b058b02619c933'

export SYNO_Create="1"

ist m.W. nur beim ersten Issue, Deploy wichtig, kann aber auch ruhig drin bleiben.

export SYNO_Certificate="*.example.com"

bei mir so, Text beliebig, landet beim ersten Issue/Deploy in der Beschreibung des Zertifikats und adressiert es bei Verlängerungen weiterhin.

Eine Renew/Deploy löse ich aus mit acme_renew.sh

#!/bin/sh
export DOMAIN=example.com
export SYNO_Certificate="*.$DOMAIN"
acme.sh --renew "$@" -d $DOMAIN -d *.$DOMAIN --dns dns_netcup --dnssleep 600
status=$?
if [ $status -eq 0 ]; then
  echo "Deploying $DOMAIN ..."
  export SYNO_Hostname="DS1522"
  echo "Deploying $SYNO_Certificate to $SYNO_Hostname ..."
  acme.sh --deploy -d $DOMAIN -d *.$DOMAIN --deploy-hook synology_dsm
  export SYNO_Hostname="DS415"
  echo "Deploying $SYNO_Certificate to $SYNO_Hostname ..."
  acme.sh --deploy -d $DOMAIN -d *.$DOMAIN --deploy-hook synology_dsm
else
  echo "Renew of $DOMAIN failed"
fi

Optional kann ich da auch ein "--force" mitgeben, daher das "$@"

Nur das Deploy mit acme_deploy.sh

#!/bin/sh
export DOMAIN=example.com
export SYNO_Certificate="*.$DOMAIN"
echo "Deploying $DOMAIN ..."
export SYNO_Hostname="DS1522"
echo "Deploying $SYNO_Certificate to $SYNO_Hostname ..."
acme.sh --deploy -d $DOMAIN -d *.$DOMAIN --deploy-hook synology_dsm
export SYNO_Hostname="DS415"
echo "Deploying $SYNO_Certificate to $SYNO_Hostname ..."
acme.sh --deploy -d $DOMAIN -d *.$DOMAIN --deploy-hook synology_dsm

Klar, die Scripte könnten sich auch gegenseitig nutzen, aber soweit bin ich noch nicht.

Edit: @*kw*, deine TOTP-, SYNO_Device_ID-Abfrage rührt von der fehlenden
SAVED_SYNO_Device_ID='irgendwas'
aus der example.conf im UZ example.conf... her. Ich weiß aber nicht mehr, wie/wo/wann der Werte gesetzt wurde,

 

[*kw*]

Mit scripten hab ich ich gar nix am Hut.

export NC_Apikey="key"
export NC_Apipw="passwort"
export NC_CID="cid"
export SYNO_Username="DS_AdminUser"
export SYNO_Password="DS_AdminUser_Passwort"

Genau damit habe ich Nachmittag den issue/deploy ausgeführt, lediglich das export SYNO_Create="1" hatte ich nicht drin. Zertifikat wurde erstellt.

Auch die „feedback Einträge“ waren identisch. Aber der bisherige deployhook zur DS scheint nicht mehr so zu funktionieren.

Die in acme hinterlegten Cert Daten (PrivateKey, Zwischenzertifikat und Domain-Zertifikat) kann ich zumindest händisch „hooken“.

Hast du nach 01.01. schon mal versucht? Gefühlt scheint das eine möglich zeitliche Marke zu sein.

 

[plang.pl]

Also funktioniert es nun so oder nicht? Und wenn ja, mit welcher account.conf?
Irgendwie hab ich den Faden verloren

 

[Benares]

@*kw*, hast du nun 2FA aktiviert oder nicht? Wenn aktiviert, verstehe ich Zusammenhänge noch nicht so ganz.
Wie gesagt , dieses export SYNO_Create="1" scheint nur beim ersten Issue/Deploy wichtig zu sein, danach kann es raus oder auch drin bleiben.
Schau dir auch mal den Code vom Deploy an (#25). Da kann man erahnen, welche Einstellungen wo hergeholt werden. Aber verstehen tue ich nicht.

 

[*kw*]

Also nochmal.

1. Ich habe bei meinem Cert-Admin-User keine 2FA eingerichtet! (hab zur Sicherheit extra einen neuen angelegt)

Damit heute erfolgreich issue/deploy initiiert (lief so seit über einem Jahr fehlerfrei).

export NC_CID="user"
export NC_Apikey="key"
export NC_Apipw="pass"
export SYNO_Username='ds-user'
export SYNO_Password='ds-pass'

Zertifikat erfolgreich erstellt, account.conf im Anschluss

export NC_CID="user"
export NC_Apikey="key"
export NC_Apipw="pass"
export SYNO_Username='ds-user'
export SYNO_Password='ds-pass'
AUTO_UPGRADE='1'
DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'
SAVED_NC_Apikey='key'
SAVED_NC_Apipw='pass'
SAVED_NC_CID='user'
USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'

Und bisher hat dieser Befehl acme.sh --deploy --deploy-hook synology_dsm -d domain.de erfolgreich den deployhook in die DS umgesetzt. Bis jetzt.

Wenn ich das jetzt eingebe, rödelt er ein wenig und fordert mich dann auf:

1. TOTP
2. SYNO_Device_ID

einzugeben. Wenn ich das skippe (wegklicke), kommt eine Fehlermeldung mit den Userdaten der DS (die definitiv stimmen) und bricht den deployhook ab.

Edit: wie gesagt, ich kann die im docker/acme Ordner hinterlegten Zertifikatsdateien aber händisch als Standardzertifikat in die DS übertragen (gültig bis 06.05.)

Da stehe ich jetzt.

 

[Benares]

So, ich hab jetzt mein acme_renew.sh-Script nochmal mit "--force" durchlaufen lassen - einwandfrei.

Dann habe ich in der example.com.conf die beiden Zeilen

SAVED_SYNO_Device_Name='CertRenewal'
SAVED_SYNO_Device_ID='irgendwascryptisches'

gelöscht und das ganze nochmal probiert.

Diesmal kam dann die Abfrage

Enter OTP code for user 'nasadmin':                                 
Enter device name or leave empty for default (CertRenewal)

Bei OTP Code hab ich dann einfach nochmal das Passwort von nasadmin (mein Admin) eingegeben und die Frage nach dem "device name" einfach so bestätigt.
Danach liefs wieder durch und hinterher stehen in der example.com.conf die beiden Zeilen wieder drin und die OTP-Abfrage kommt nicht mehr.

 

[*kw*]

@Benares: ich habe deinen Edit zu spät gesehen:

deine TOTP-, SYNO_Device_ID-Abfrage rührt von der fehlenden
SAVED_SYNO_Device_ID='irgendwas'

Man hat ja die Möglichkeit, einmalig etwas eingeben zu können (müssen?)

which requires 1 additional step (executed only once) upon running the actual deploy command:

• manual input of the TOTP code for the user defined via SYNO_Username
• optionally entering a "device name", if you don't like the default CertRenewal one

Wenn ich das richtig verstehe, will DSM (künftig) eine 2FA-Anmeldung, lässt aber noch acme.sh mit einem "workaround" einen http-Login umsetzen. Weiterhin soll kein TOTP im Klartext mehr per API übermittelt werden.

Weiterhin müssten für einen 2FA/TOTP deploy alle Exports in die account.conf und auf TOTP parametriert sein. Dann käme beim deploy die TOTP-Abfrage --> Eingabe --> userspezifische Daten werden durch DSM-API lokal abgelegt.

Soweit mein begrenztes Verständnis im Thema.

 

[Benares]

Jetzt musst du aber meinen letzten Beitrag erstmal lesen

 

[*kw*]

Ja, das war zeitgleich.

Edit: nach so viel github qualmt mir dennoch erst mal der Kopf. Aber egal, wo man Neil Pang liest, werden viele Anfragen sinngemäß beantwortet: "Ja, das war mal so, das wird jetzt anders/neu."

 

[Benares]

Lies auch mal hier - als Ergänzung. Da ist die Geschichte mit der Device ID etwas erklärt.

 

[*kw*]

@Benares: vielen Dank, ich tu's mir gerne an (@Lernmodus).

PS: anhand nur dieser beiden Information (1. und 2.) würde ich es so verstehen, dass das deploy-script laufen muss und man dann den hook-Befehl absetzen kann.

Aber ich lese, hoffe zu verstehen und...ich komme eh nochmal.

 

[Benares]

und schau dir dann mal noch in 2. die Zeilen 127-143 an.

 

[alexhell]

Bei mir ist das schon sehr lange her, dass ich das mal eingerichtet habe, daher nur als Zwischenfrage
Funktioniert SYNO_DID nicht mehr bei 2FA? Das habe ich damals verwendet um 2FA zu "umgehen".

 

[*kw*]

Ich habe jetzt einfach mal das wesentlich aus dem "hook-Artikel" rüberkopiert

By default, Synology requires 2-factor authentication via TOTP (Time-based One Time Password) for each user upon API-based access to any recent DSM version - which basically breaks any automated deployment, if you (rightfully!) refuse to provide the TOTP secret in plaintext to some 3rd party CLI-based tool, generating the TOTP code for you.

While legacy setups of ACME.sh continue to work with such a risky workaround (until Synology ultimately pulls the plug on that), new as well as security-sensitive users are expected to only use the secured API access method - which requires 1 additional step (executed only once) upon running the actual deploy command (see step 3 above):

manual input of the TOTP code for the user defined via SYNO_Username
optionally entering a "device name", if you don't like the default CertRenewal one
After that one-time manual input of the TOTP code, the deploy script request a so called device ID from the DSM API for the specified user. That ID is saved to your local configuration file & used upon subsequent deployments, in turn eliminating the need for another TOTP code or, even worse, the TOTP secret as the previous script did.

Additionally, it's recommended to set SYNO_Scheme to https, SYNO_Port to 5001 & SYNO_Hostname to your actual DSM's FQDN, e. g. nas.example.com instead of http & localhost. That's because of increased security due to TLS-based connection instead of a plaintext one.

However, using https & localhost requires addition of the --insecure command line argument to successfully deploy the certificate to DSM. Though, enabling HTTP/2 still might give you a curl 16 error, although the script succeeded anyways.

 

[*kw*]

@alexhell: im Forum wurde an anderer Stelle nur mal am Rande erwähnt, "das ist jetzt alles so'n Script Kram..." (sinng.)

Edit: ich probiere gerne aus und mache (bewusst) Fehler, um am Ende was draus zu lernen. Doof sind nur die reglementierten Vorgaben der CAA, die das auf wenige Versuche (aus Sicherheit zu recht) beschränken.

 

[Benares]

Funktioniert SYNO_DID nicht mehr bei 2FA?

Im Code steht's noch drin, aber in einem Abschnitt, der als "DEPRECATED, only kept for legacy compatibility reasons" gekennzeichnet ist

Edit:
Der wichtigste Teil scheint mir der hier zu sein:

manual input of the TOTP code for the user defined via SYNO_Username
optionally entering a "device name", if you don't like the default CertRenewal one
After that one-time manual input of the TOTP code, the deploy script request a so called device ID from the DSM API for the specified user. That ID is saved to your local configuration file & used upon subsequent deployments, in turn eliminating the need for another TOTP code or, even worse, the TOTP secret as the previous script did.

Ich verstehe das so, dass, egal ob 2FA oder nicht, einmalig nochmal nach den TOTP bzw. Passwort gefragt wird. Daraus generiert die Synology-API dann diese kryptische Device_ID, die künftig dafür sorgt, dass keine 2FA mehr notwendig ist.

 

[alexhell]

Ahh ok. Weil im Wiki von denen schreiben sie es immer noch als Lösung. Aber ich bin da wie gesagt seit 2 Jahren oder so raus und weiß nicht mehr was sie genau haben wollen.
Danke aber für die Auflösung, dann weiß ich immerhin für die Zukunft bescheid, dass es nicht mehr benutzt werden soll.

 

[*kw*]

Ich war auch der Hoffnung, dass ich da nie mehr ran muss, nachdem EDvS mir das eingerichtet und ich es halbwegs geschnackelt habe. Sogar beim späteren Domainwechsel hab ich es alleine hinbekommen.

Jetzt steh ich wieder ausgebremst da. Aber wenn ich von vielen Dingen nicht viel habe, aber Zeit schon… (PS: wenn‘s nach meiner Frau ginge, nicht. )

 

[*kw*]

Nachdem die Docker-Version partout nicht wollte, habe ich nach diesem Video mir das "normale" acme.sh installiert (PS: das Schneckentempo beim Erklären kam meinem Alter näher ).

Damit konnte ich wenigstens ein Zertifikat erstellen, der deployhook funktioniert aber auch hier nicht.

Auch wenn das für den Moment nach "EDV zu Fuß schreit", kann ich mir so wenigstens die Cert-Files lokal händisch zur DS importieren. Bei nur einer DS im Privatgebraucht kann ich das viermal im Jahr verkraften.

Und bis dahin fließt noch viel Wasser... und hoffentlich neue Ideen.