acme.sh / Synology DS1821 / dyndnsfree.de

*kw*

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
2.840
Punkte für Reaktionen
1.370
Punkte
174
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

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
13.734
Punkte für Reaktionen
3.717
Punkte
468
@*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:
Code:
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:
Code:
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'

Code:
export SYNO_Create="1"
ist m.W. nur beim ersten Issue, Deploy wichtig, kann aber auch ruhig drin bleiben.

Code:
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
Code:
#!/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
Code:
#!/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,
 
Zuletzt bearbeitet:

*kw*

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
2.840
Punkte für Reaktionen
1.370
Punkte
174
Mit scripten hab ich ich gar nix am Hut. 🙈

Code:
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

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
15.029
Punkte für Reaktionen
5.400
Punkte
564
Also funktioniert es nun so oder nicht? Und wenn ja, mit welcher account.conf?
Irgendwie hab ich den Faden verloren :ROFLMAO:
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
13.734
Punkte für Reaktionen
3.717
Punkte
468
@*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*

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
2.840
Punkte für Reaktionen
1.370
Punkte
174
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).

Code:
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

Code:
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

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
13.734
Punkte für Reaktionen
3.717
Punkte
468
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
Code:
SAVED_SYNO_Device_Name='CertRenewal'
SAVED_SYNO_Device_ID='irgendwascryptisches'
gelöscht und das ganze nochmal probiert.

Diesmal kam dann die Abfrage
Code:
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.
 
  • Like
Reaktionen: *kw*

*kw*

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
2.840
Punkte für Reaktionen
1.370
Punkte
174
@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

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
13.734
Punkte für Reaktionen
3.717
Punkte
468
Jetzt musst du aber meinen letzten Beitrag erstmal lesen ;)
 

*kw*

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
2.840
Punkte für Reaktionen
1.370
Punkte
174
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

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
13.734
Punkte für Reaktionen
3.717
Punkte
468
Lies auch mal hier - als Ergänzung. Da ist die Geschichte mit der Device ID etwas erklärt.
 
  • Like
Reaktionen: *kw*

*kw*

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
2.840
Punkte für Reaktionen
1.370
Punkte
174
@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

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
13.734
Punkte für Reaktionen
3.717
Punkte
468
und schau dir dann mal noch in 2. die Zeilen 127-143 an.
 

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
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*

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
2.840
Punkte für Reaktionen
1.370
Punkte
174
Ich habe jetzt einfach mal das wesentlich aus dem "hook-Artikel" rüberkopiert

acme.sh@github schrieb:
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*

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
2.840
Punkte für Reaktionen
1.370
Punkte
174
@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

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
13.734
Punkte für Reaktionen
3.717
Punkte
468
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.
 
Zuletzt bearbeitet:

alexhell

Benutzer
Sehr erfahren
Mitglied seit
13. Mai 2021
Beiträge
2.831
Punkte für Reaktionen
853
Punkte
154
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*

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
2.840
Punkte für Reaktionen
1.370
Punkte
174
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*

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
2.840
Punkte für Reaktionen
1.370
Punkte
174
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.
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat