Lets Encrypt Zertifikate über acme.sh

[skeunig]

Hallo zusammen,

ich hatte zum Glück viel Unterstützung von dem sehr lieben User hier, aber jetzt bin ich auf ein Problem gestoßen und komme nicht mehr weiter. Eventuell hatte ja schon mal jemand das gleiche Problem.

In Prinzip möchte ich ein Wildcardzertifikat für meine Domain und Subdomain eintragen.
Mein Domainanbieter ist DO.de
Dazu bin ich der Anleitung "Renew Let’s Encrypt certificates on Synology using acme.sh" von "Christos Georgiadis" gefolgt
Nur gibt es jetzt einProblem in der account.conf Datei.
Eigentlich müsste man ja die Werte von Domain Hoster "export ....._Login=AccountID" "export ...._Authdata=Passwort usw. eintragen, allerdings bietet dies mein Domainanbieter "DO.de" nicht an, sondern er bietet nur einen "Let's Encrypt API-Token" an.
Wenn man den Link auf der Anleitung folgt und ich es richtig verstehe, dann soll man in die Datei "account.conf" nur
export DO_LETOKEN='FmD408PdqT1E269gUK57' eintragen....
Soweit auch alles gemacht aber wenn ich dann den Container starte, dann spuckt er mir eine Fehlermeldung beim Zertifikat anfordern aus ...
Scheinbar kommt er mit dem Token nicht zurecht?
Muss man eventuell den Code umschreiben oder so ?

Hätte da jemand eventuell einen Tipp?

 

[plang.pl]

eine Fehlermeldung

Welche?

 

[ctrlaltdelete]

Authentication failed.
Haben wir gerade gelöst.
Der Befehl für die DNS Api war falsch, das api hatte gefehlt:
./acme.sh --issue --dns dns_doapi -d example.com -d *.example.com

 

[Benares]

export DO_LETOKEN='FmD408PdqT1E269gUK57'
ist für do.de schon richtig, aber du musst natürlich deinen Eintragen und nicht den aus dem Beispiel

 

[skeunig]

Problem wurde gelöst.

Auch hier nochmal vielen Dank an @ctrlaltdelete der mir soviel weiter geholfen hatte und allgemein mich mega Unterstützt hat .

1. Das Problem war einma das der Befehl falsch war
2. Das für den User 2FA aktiviert war
3. Nach Löschung der 2FA immer noch der Zwang dazu da war, auch ein großes Problem
4. Nachdem dann alles ging, gab es immer noch einen Fehler und der Lag daran, dass ich noch ein altes abgelaufenes Zertifikat in meiner DS hatte.
Darauf muss man erstmal kommen und ich bin nicht darauf gekommen
Nachdem das gelöscht war, hat es dann tatsälich funktioniert.

 

[Kachelkaiser]

3. Nach Löschung der 2FA immer noch der Zwang dazu da war, auch ein großes Problem

Mich würde interessieren, wie ihr dieses Problem gelöst habt. Mein User hat auch keine MFA aktiviert trotzdem will der deploy einen OTP haben.

Auch nach der Neuinstallation des kompletten Containers komme ich nicht über die Eingabe des OTP drüber.

 

[Kachelkaiser]

Keiner ne Idee?

@ctrlaltdelete villeicht kannst du helfen?

 

[Janüscht]

Das ist kein Problem. Diese Abfrage wurde nur in den Deploy eingearbeitet und die Werte aus der account.conf entfernt. Wenn du keine 2FA nutzt und keinen OTP hast, einfach weiter "entern". Das Gleiche gilt auch für die Namensabfrage, welche darauf folgt. Es soll also nur die Verwendung von 2FA vereinfachen, mehr nicht!

 

[Kachelkaiser]

Ok das klingt ja gut. Dann versuch ich das mal. Hatte nicht gedacht, dass es so einfach sein kann ubd gar nicht weiter auf enter gedrückt.

 

[Kachelkaiser]

so habe es jetzt nochmal ausprobiert und scheitere wieder

habe es mit mehren Accounts probiert und leider wird der Login immer abgelehnt. Bin mit meinem Latein am Ende. Werde heute das Zertifikat manuell deployen, weil es morgen ausläuft.

EDIT: Der account hat keine 2FA aktiviert. Ich habe mal testweise meinen normalen Admin-Account benutzt, der 2FA aktiviert habe, auch bei diesem scheitere ich.

 

[Janüscht]

Eventuell probierst du einmal ein ganz einfaches Passwort als Erstes aus. Ein generiertes Passwort von Synology kann u.U. nicht unterstützte Sonderzeichen enthalten. Ein weiteres Problem kann natürlich auch die Firewall sein. Wenn dein "Dockernetzwerk" geblockt nicht, kann keine Verbindung zum Host aufgebaut werden.

Wenn es das gleiche Gerät wie der Host ist, brauchst du keine Adresse zu angeben. Dann wird automatisch"localhost" verwenden. Alternativ kannst du dazu auch einmal die IP ausprobieren.
Als minimal reicht der Username und Passwort in der account.conf zu hinterlegen. Wenn ein andere Port oder SSL verwendet werden soll, kommt das noch optional. Ich würde aber erst einmal mit dem einfachsten anfangen.

Für mehr Hilfe braucht man auch mehr Informationen um deinen Fehler zu reproduzieren.

 

[Benares]

Probiere auch mal den Parameter "--insecure" mitzugeben. curl error 60 könnte auf ein Zertifikatsproblem hindeuten, weil das Zertifikat z.B. nicht für irgendwas.fritz.box gültig ist

 

[ctrlaltdelete]

@Kachelkaiser leg mal einen frischen user an für acme.sh und probiere es damit.
Edit: Verwendest du für DSM den Port 5000?
edit2: Hat der user Admin Rechte?

 

[plang.pl]

Ich mache es einfach so: acme.sh läuft im Host-Netz. Der Deploy Hook läuft dann über 127.0.0.1:5000. Solange der Datenverkehr lokal bleibt, sehe ich keinen Grund, https zu nutzen.

 

[Benares]

Stimme zu. Die Frage wird kommen, was man dafür ändern/prüfen muss. Vermutlich

export SYNO_Scheme="http"
export SYNO_Port="5000"

in der account.conf

 

[plang.pl]

Jap. So sieht es bei mir aus (Netcup):

export NC_Apikey="KEY"
export NC_Apipw="PW"
export NC_CID="ID"
export SYNO_Username="Syno_User"
export SYNO_Password="Syno_PW"
export SYNO_Port="5500"
export SYNO_Hostname="127.0.0.1"
export SYNO_Scheme="http"
export SYNO_Create="1"
export SYNO_Certificate="Let's Encrypt"
AUTO_UPGRADE='1'

EDIT: Der http Port bei meiner DS ist 5500. Per default ist der auf 5000

 

[Benares]

zu ergänzen wäre vielleicht noch, dass SYNO_Certificate auf die Beschreibung des Zertifikats zeigt, das ersetzt werden soll.

 

[Janüscht]

Stimme zu. Die Frage wird kommen, was man dafür ändern/prüfen muss. Vermutlich

export SYNO_Scheme="http"
export SYNO_Port="5000"

in der account.conf

Das stimmt so nicht. Diese Werte sind vollkommen obsolet, weil diese gefault sind!
Für den Standardport (5000) auf einem Host-System reicht nur der Username und Passwort aus. Alles andere ist nur notwendig, wenn abweichende Werte genommen werden!

Auch eine Beschreibung muss man nur angeben, wenn man mehrere und unterschiedliche Zertifikate nutzen will z.B. für unterschiedliche Domains. Subdomain sind natürlich davon ausgeschlossen. Das gilt auch für den "Create"-Wert. Wenn kein Name gesetzt wird, wird automatisch das selbst signierte Synology-Zertifikat ersetzt.

Für einen lokalen Import reicht die minimal Config vollkommen aus:

export SYNO_Username="Syno_User"
export SYNO_Password="Syno_PW"

Dazu kommen nur noch wie DynDNS-Anbieter Daten und fertig ist das Ganze. Autoupgrade wird von acme.sh automatisch erzeugt. Oft ist weniger auch mehr! Macht die Sache nicht komplizierter las sie ist, das verunsichert nur die User.

 

[Benares]

Aber zusätzliche Angaben schaden auch nichts, oder? Woher willst du denn wissen, welchen Werte ein Anwender nutzt, der hier liest?
Nicht jeder nutzt deine Settings mit den (Default-)Werten und nur einem Host an den das Zertifikat deployed werden soll.

 

[Kachelkaiser]

Vielen Dank an alle für die gute Hilfestellung hier.

ich habe jetzt mal mein account.conf von

export NC_Apikey="key"
export NC_Apipw="PW"
export NC_CID="ID"
export SYNO_Username='Syno_user'
export SYNO_Password='Syno_PW'
export SYNO_Certificate="acme.sh certificate"
export SYNO_Scheme="https"
export SYNO_Port="https_port"
export SYNO_Hostname="xxxxx.fritz.box"
# export SYNO_Device_Name="CertRenewal"
# export SYNO_Device_ID=""
export SYNO_Create=1 # defaults to off, this setting is not saved.  By setting to 1 we create the certificate if it's not in DSM
AUTO_UPGRADE='1'

auf

]export NC_Apikey="key"
export NC_Apipw="PW"
export NC_CID="ID"
export SYNO_Username='Syno_user'
export SYNO_Password='Syno_PW'
export SYNO_Certificate="acme.sh certificate"
export SYNO_Scheme="http"
export SYNO_Port="http_port"
export SYNO_Hostname="127.0.0.1"
# export SYNO_Device_Name="CertRenewal"
# export SYNO_Device_ID=""
export SYNO_Create=1 # defaults to off, this setting is not saved.  By setting to 1 we create the certificate if it's not in DSM
AUTO_UPGRADE='1'

geändert, sprich statt des Hostnamens die Localhost-IP und das Ganze noch über https anstatt HTTPS. Jetzt war ich erfolgreich. Der User war der gleiche wie bisher, welcher auch Admin-Rechte hat.