acme.sh / Synology DS1821 / dyndnsfree.de

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
14.414
Punkte für Reaktionen
5.034
Punkte
544
Ja, genau mit diesen 2 Punkten hatte ich zu Beginn auch zu kämpfen.
Solange der Datenverkehr lokal bleibt (was ja hier der Fall ist), ist das mit http statt https kein Problem.
Danke für die Rückmeldung und ein schönes Wochenende!
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.536
Punkte für Reaktionen
2.988
Punkte
423
Wobei man dazu sagen muss, das SYNO_Create="1" nur beim ersten Deploy wichtig ist, falls das Zertifikat noch nicht existiert. Danach ist nur noch SYNO_Certificate (landet in der Beschreibung der Zertifikats beim ersten Deploy) wichtig, um auch das richtige Zertifikat zu aktualisieren. Beides immer zu setzen geht natürlich auch.
 
Zuletzt bearbeitet:

FleischFlori

Benutzer
Mitglied seit
12. Jul 2014
Beiträge
22
Punkte für Reaktionen
3
Punkte
3
Guten Abend,

ich würde mich auch einmal gern hier mit einklinken. Ich habe alles nach den Infos hier aus dem Forum und nach der verlinkten Anleitung von Christos gemacht. Ein neuer Benutzer wurde angelegt, in die Admin-Gruppe gepackt, alle Berechtigungen entzogen und 2FA-Status steht auf deaktiviert. Domainanbieter ist All-Inkl.

Sobald ich im Terminal deployen will, erhalten ich folgenden Fehler:
Code:
/ # acme.sh --deploy -d meinedomain --deploy-hook synology_dsm
[Sun Feb  4 19:22:19 UTC 2024] The domain 'meinedomain' seems to have a ECC cert already, lets use ecc cert.
[Sun Feb  4 19:22:19 UTC 2024] Logging into xxx.xxx.xxx.xxx:http-port
Enter OTP code for user 'acme':
Enter device name or leave empty for default (CertRenewal):
[Sun Feb  4 19:22:21 UTC 2024] Unable to authenticate to xxx.xxx.xxx.xxx:http-port - check your username & password.
[Sun Feb  4 19:22:21 UTC 2024] If two-factor authentication is enabled for the user, set SYNO_Device_ID.
[Sun Feb  4 19:22:21 UTC 2024] Error deploy for domain:meinedomain
[Sun Feb  4 19:22:21 UTC 2024] Deploy error.
/ #

Die OTP- und Devicename-Abfrage habe ich mit zweimal Enter übersprungen.
Hier noch meine account.conf:

Code:
export KAS_Login="login"
export KAS_Authdata="password"
export KAS_Authtype="plain"
export SYNO_Username="acme"
export SYNO_Password="passwort"
export SYNO_Certificate="Let's Encrypt"
export SYNO_Scheme="http"
export SYNO_Port="http-port" # aus dem Anmeldeportal
export SYNO_Hostname="xxx.xxx.xxx.xxx"
export SYNO_Create="1"
AUTO_UPGRADE='1'

Ich dachte ja, dass 2FA für Admins jetzt aktuell verpflichtend sei, aber anscheinend ist das nicht so. User löschen und neu anlegen, einfacheres PW etc. brachte alles keinen Erfolg. Auch egal, ob ich localhost, die IP der Syno oder 127.0.0.1 angebe. Immer das exakt gleiche Verhalten.

Wo liegt mein Denkfehler?

Besten Dank für die Hilfe im Voraus.

VG
FleischFlori
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.536
Punkte für Reaktionen
2.988
Punkte
423
Lies mal hier. Passt das alles?
 

*kw*

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
1.678
Punkte für Reaktionen
694
Punkte
134
Du brauchst definitiv kein 2FA, das hab ich auch die vergangenen Tage leidvoll durchgemacht (Randnotiz).

Laut dnsapi benötigst du zum Einrichten eigentlich nur in der account.conf:

Edit: So bei mir, analog nur in netcup, mit einem Zertifikat

Code:
export KAS_Login="<ACCOUNTID>"
export KAS_Authdata="<PLAINTEXTPASSWORD>"
export KAS_Authtype="plain"
export SYNO_Username="user"
export SYNO_Password="passwort"

Vorher würde ich aber standardmäßig acme.sh von ZeroSSL auf Lets Encrypt umstellen:
acme.sh --set-default-ca --server letsencrypt

Danach das Zertifikat anfordern und deployen
acme.sh --issue --dns dns_kas -d example.com -d *.example.com --dnssleep 1200 <Zeit ablaufen lassen

Und dann das Zertifikat auf die DS übertragen
acme.sh --deploy -d example.com --deploy-hook synology_dsm

Vorher natürlich das alte Cert rausschmeißen
 
Zuletzt bearbeitet:

ctrlaltdelete

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
30. Dez 2012
Beiträge
10.291
Punkte für Reaktionen
3.763
Punkte
414

*kw*

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
1.678
Punkte für Reaktionen
694
Punkte
134
@FleischFlori: Wichtig deswegen, weil dein derzeitiges Zertifikat mit OTP deployed, also eingerichtet wurde. Auch wenn du 2FA wieder entfernt hast, benötigt die CA eine Weile, bis sich die Änderungen nach dem erneuten Abruf des Zertifikats anpassen.

Wenn es dir nichts ausmacht, lege einfach einen neuen Admin-User mit PW an, dann sollte es mit den neue Daten zu keinen Komplikationen kommen.

Und nicht zu oft "falsch" abrufen, 5x in 24 Stunden bekommst du zwei Tage Zeitstrafen. 😜
 
  • Like
Reaktionen: ctrlaltdelete

FleischFlori

Benutzer
Mitglied seit
12. Jul 2014
Beiträge
22
Punkte für Reaktionen
3
Punkte
3
Danke erstmal für die ganzen Ausführungen. Ich habe mich jetzt daran gehalten und leider weiterhin keinen Erfolg.

Was habe ich nun nochmal gemacht?

1. Neuen Benutzer angelegt, keinen Zugriff auf Ordner und Apps, nur zur Gruppe "administrators" hinzugefügt.
2. alle Zertifikate bis auf QC und synology Standard rausgeschmissen
2. account.conf angepasst auf folgendes:

Code:
export KAS_Login="xxx"
export KAS_Authdata="xxx"
export KAS_Authtype="plain"
export SYNO_Username="xxx"
export SYNO_Password="xxx"
export SYNO_Certificate="Let's Encrypt"
export SYNO_Scheme="http"
export SYNO_Port="http-port"
export SYNO_Hostname="127.0.0.1"
export SYNO_Create="1"

3. Auf den Container per Terminal und sh.
4. Umstellung auf LE laut dem Befehl von *kw*
5. Zertifikat angefordert (2. Befehl von *kw*)
6. Ausrollen über den dritten Befehl. Wieder die gleiche Fehlermeldung.

Code:
[Mon Feb  5 11:05:01 UTC 2024] The domain 'example.com' seems to have a ECC cert a
lready, lets use ecc cert.                                                      
[Mon Feb  5 11:05:01 UTC 2024] Logging into 127.0.0.1:5xx0                      
Enter OTP code for user 'xxx':                                          
Enter device name or leave empty for default (CertRenewal):                    
[Mon Feb  5 11:05:02 UTC 2024] Unable to authenticate to http://127.0.0.1:5xx0 -
check your username & password.                                                
[Mon Feb  5 11:05:02 UTC 2024] If two-factor authentication is enabled for the us
er, set SYNO_Device_ID.                                                        
[Mon Feb  5 11:05:02 UTC 2024] Error deploy for domain:example.com             
[Mon Feb  5 11:05:02 UTC 2024] Deploy error.

Ich raffe es einfach nicht.
 
Zuletzt bearbeitet:

*kw*

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
1.678
Punkte für Reaktionen
694
Punkte
134
Ich hab das seinerzeit quasi auch "intravenös" einverleibt bekommen, das Verständnis kam später. ;)

Nimm für die account.conf einfach nur die fünf Zeilen aus meinem o.g. Beispiel, den Rest lass weg (mehr sollte ich "damals" auch nicht machen). Hat geklappt.

Edit: Fakt ist aber, die Nutzerdaten machen Probleme. Alles mal im Text-Editor gecheckt?
 
Zuletzt bearbeitet:

FleischFlori

Benutzer
Mitglied seit
12. Jul 2014
Beiträge
22
Punkte für Reaktionen
3
Punkte
3
Ja, alles gecheckt in der Conf und stimmt auch alles.

Es läuft gerade der nächste Versuch nur mit den 5 Zeilen, wie von Dir beschrieben. Ich melde mich nach dem DNSSleep nochmal.
 

*kw*

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
1.678
Punkte für Reaktionen
694
Punkte
134
PS: der "dritte Befehl" Cert > DS klappt natürlich nur, wenn die Anforderung erfolgreich durchgelaufen ist. Nach Befehl "2" darf im Terminal nix Rotes stehen.
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.536
Punkte für Reaktionen
2.988
Punkte
423
Schau auch mal in die conf-Dateien im Unterverzeichnis "example.com...". Da merkt sich acme.sh einiges, was dann beim nächsten Lauf wieder verwendet wird. Nicht dass da noch Einstellungsleichen von deinen vorherigen Versuchen enthalten sind.

Mich stören da die Fragen nach "OTP Code" und "device name". Die kenne ich so nicht.
 
  • Like
Reaktionen: *kw*

*kw*

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
1.678
Punkte für Reaktionen
694
Punkte
134
Guter Hinweis, den ich für mich als "Selbstverständnis" angesehen habe.

Ich habe bei jedem neuen Anlauf zur Sicherheit den kompletten Inhalt des acme-Ordners gelöscht und nur wieder "nackte", unergänzte account.conf reingelegt.
 

FleischFlori

Benutzer
Mitglied seit
12. Jul 2014
Beiträge
22
Punkte für Reaktionen
3
Punkte
3
Leider wieder kein Erfolg. Genau die gleichen Meldungen.

Das Zertifikat wurde sauber kreiert, keine Fehlermeldung oder rote Aussagen im Terminal. Deployment wieder nicht möglich mit den gleichen Fehlern. Er verlangt auch bei einem neuen User immer OTP.

Muss ich mich mit dem Acme-User initial einmal anmelden?

In den Confs auch im Unterordner ist nichts zu finden, außer der falsche HTTP-Port. Ich nutze nicht den Standard von 5000. Selbst wenn ich den anpasse, resultiert es in den gleichen Fehlermeldungen.

Ich werde es jetzt noch ein letztes Mal mit einen komplett neuen User versuchen, danach lasse ich es und muss halt weiter manuell die Zertifikate erneuern 🤷‍♂️.
 

*kw*

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
1.678
Punkte für Reaktionen
694
Punkte
134
Wie geschrieben, lösch vorher den kompletten Inhalt des acme Ordners und füge nur wieder die account.conf ein.

Der User muss nicht angemeldet sein, nur Admin-Rechte haben. Du kannst versuchsweise dem User noch den Vollzugriff auf den Docker-Ordner geben, auch wenn über die Gruppenrechte kommt.

Edit: wenn ich mit den fünf Zeilen anlegen, bekomme ich in der "bestätigten" account.conf nur "saved" Bestätigung und den Servereintrag. Nix http, o.ä.
 
Zuletzt bearbeitet:

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.536
Punkte für Reaktionen
2.988
Punkte
423
Du musst ja nicht immer gleich das ganze Zertifikat erneuern, nur um den Deploy zu testen. In dem in #25 verlinkten Dokument ist das ja beschrieben.
 

FleischFlori

Benutzer
Mitglied seit
12. Jul 2014
Beiträge
22
Punkte für Reaktionen
3
Punkte
3
Edit: wenn ich mit den fünf Zeilen anlegen, bekomme ich in der "bestätigten" account.conf nur "saved" Bestätigung und den Servereintrag. Nix http, o.ä.
Das bekomme ich danach auch. Die account.conf wird um folgenden Zeilen ergänzt:

Code:
AUTO_UPGRADE='1'
DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'
SAVED_KAS_Login='xxx'
SAVED_KAS_Authtype='plain'
SAVED_KAS_Authdata='xxx'
USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'

In den im Cert-Ordner angelegten Confs verweisen auf den Standardport 5000 im SAVED-Ausdruck. Dieser wäre hier eigentlich verkehrt, da ich einen anderen Port im Anmeldeportal für HTTP hinterlegt habe.

Und auch mit dem ganz neuen User (einfach angelegt und im Anlagevorgang nur die Gruppe "administrators" gewählt) kein Erfolg. Es kommt weiterhin eine OTP- und Devicename-Abfrage und die gleichen roten Fehler wie oben. Dass mich ein solches Tool hier sowas von hasst kenne ich sonst nur von meiner Frau :ROFLMAO:.

Aber wahrscheinlich soll es nicht sein. Dann muss ich mir andere Wege suchen.

Edit:
Du musst ja nicht immer gleich das ganze Zertifikat erneuern, nur um den Deploy zu testen. In dem in #25 verlinkten Dokument ist das ja beschrieben.
Ich bin das Dokument nochmal durchgegangen und habe zusätzlich noch die einzelnen Punkte zur account.conf hinzugefügt. Jetzt kommt keine OTP Abfrage aber das hier:

Code:
SYNO_Device_Name set, but SYNO_Device_ID is empty

Die Device ID ist mir aber nicht bekannt, wird ja auch eigentlich laut Link automatisch gesetzt. Wo bekomme ich die her?
 
Zuletzt bearbeitet:

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.536
Punkte für Reaktionen
2.988
Punkte
423
Bei mir steht in der example.com.conf ein Eintrag SAVED_SYNO_Device_ID='irgendwascryptisches', also muss die irgendwann mal ermittelt worden sein, und SAVED_SYNO_Device_Name='CertRenewal' :unsure:
Aber ich verstehe auch im Code nicht ganz, was die da treiben.
 

*kw*

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
10. Aug 2013
Beiträge
1.678
Punkte für Reaktionen
694
Punkte
134
Bei mir kam das zurück:

SYNO_Device_ID='DATENSERVER'

...der "glorreiche" Name meiner DS. ;)
 


 

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 

 
 
  AdBlocker gefunden!

Du bist nicht hier, um Support für Adblocker zu erhalten. Dein Adblocker funktioniert bereits ;-)

Klar machen Adblocker einen guten Job, aber sie blockieren auch nützliche Funktionen.

Das Forum wird mit hohem technischen, zeitlichen und finanziellen Aufwand kostenfrei zur Verfügung gestellt. Wir zeigen keine offensive Werbung und bemühen uns um eine dezente Integration.

Bitte unterstütze dieses Forum, in dem du deinen Adblocker für diese Seite deaktivierst.

Du kannst uns auch über unseren Kaffeautomat einen Kaffe ausgeben oder ein PUR Abo abschließen und das Forum so werbefrei nutzen.

Vielen Dank für Deine Unterstützung!