Lets Encrypt Zertifikat erstellen/erneuern

[Benie]

Watchtower brauchst Du aber nicht wegen der Zertifikate, und wegen der Verlängerung eines Zertifikat für eine Synology DynDNS braucht kein Port offen stehen. Synology Adressen werden problemlos ohne offenen Port verlängert.

 

[Janüscht]

@wegomyway,
was hat Watchtower mit den Zertifikaten zu tun? Nichts!

Entweder du nutzt eine Synology Adresse und musst dich außer die Freigaben um nichts kümmern, der du nutzt acme.sh (empfohlen) oder machst das via Scripte. Alle 3 Möglichkeiten funktionieren je nachdem welche Voraussetzungen der einzelne User hat. Ich persönlich bin kein freund von einem Synology Konto und einer Synology. Adresse. Ich nutze eine Eigendomain (Netcup 1.58 im Jahr) zusammen mit acme.sh und zusätzlich noch eine DynDNS (dynv6.com) für weitere Dienste.

Somit bin ich unabhängig und kann jederzeit auch andere Hardware nutzen. Für ich der einzig richtige weg, auch wenn es ein paar Klicks mehr sind. Das Gleiche habe ich auch bei meinen anderen Containern und nutzte Synology nur die DSM & Backup. Dann gibt es auch kein gejammert, wenn Fotos etc. wieder verbastelt wird. Nicht immer ist der einfachste Weg auch der beste

 

[Benie]

@wegomyway
Du musst jetzt aber auch nicht unruhig werden, nicht jeder braucht acme.sh und eine nichtsynology DynDNS.
Ich fahre da jetzt schon über 10 Jahre gut damit. Simpler geht es nämlich nicht. Solange Du nur die DS nutz, gibt es keinerlei Probleme .
Bieg mal zb. mit einer nicht Synology DynDNS die interne IP auf die DS um, um zb. Vaultwarden ohne offenen Port zu nutzen, daß geht zb. dann ohne Synology DynDNS nicht.

 

[Janüscht]

Warum soll eine netzinterne Auflösung über ein Hosts-Date, DNS-Server, AdGuard oder Pi-Hole nicht funktionieren? Das sind ja wohl genügend Anwendungen, wie man etwas "umbiegen" kann. Dazu bekommt man bei den beiden letzteren genannten Beispielen noch zusätzliche Werbe- & Trackingfilter. Zusammen mit einer VPN-Verbindung ist man auch die Werbung auf den Mobilgeräten und Apps unterwegs los. Von der Sicherheit an öffentliche WLAN etc. ganz zu schweigen, gerade wenn man Banksingapps nutzt.

Ich finde wichtig, anderen die Möglichkeiten aufzuzeichnen. Entscheiden muss jeder das für sich selbst. Auch die Beschreibung von den Synology-Diensten und Quickconnect wurde mehrfach hier diskutiert. Dass dieser Dienst nicht ganz durchsichtig und die Whitepapers einige Fragen offen lassen, findet man in der Boardsuche. Nicht alles von Synology ist Gold. Ich behaupte jetzt einmal: Alles außer DSM & alles was mit Backup zu tun hat.

 

[wegomyway]

@wegomyway,
was hat Watchtower mit den Zertifikaten zu tun? Nichts!

Da hast Du völlig recht. Da hab ich in freudiger Überraschung dass das Zertifikat verlängert ist, völlig falsch "gedacht", hab eben noch , sorry dafür.
Aber da das LE-Zertifikat verlängert wurde, zeigt das das Script von hier aus dem Forum funktioniert hat und man damit "eine Sorge" weniger hat alle 3 Monate da einen/zwei Blick(e) drauf zu werfen.
@Benie , mein "Dingens" also alles was da auf der 224+ eingerichtet wurde, mit freundlicher Unterstützung von dem einen oder anderen User von hier, funktioniert ja. Das ist einerseits beruhigend und für mich als reiner privater Nutzer aktuell auch funktionierend. Muss ja immer meine anderen Nutzer, zwei Familienmitglieder, mit ins Boot nehmen. Nicht das die dann irgendwie nur noch "böhmische Dörfer" verstehen. Ist aktuell hier und dort eh schon der Fall .
Aber sicherlich immer mal über den Tellerrand schauen ist wichtig, denn 100%tig sicher gibt es nicht, außer man hat keine NAS und keinen Internetzugang

 

[*kw*]

Als mein Kalender heute morgen wegen des Zertifikats gemeckert hat, wusste ich anhand des Datums schon, was los war…

Ich habe mich beim letzten Abruf (erfolgreich) für die 2FA-Variante mit separatem Admin entschieden. Jetzt bekam ich beim manuellen Renew genau deswegen eine Fehlermeldung (Kurzversion). Auch hierfür hatte ich den Parameter „export SYNO_DEVICE_ID=""“ weggelassen, bzw. war bei TOTP obsolet.

Ein erneuter Blick in github ergab, dass der Prozess geändert/vereinfacht wurde, Stichwort „export SYNO_USE_TEMP_ADMIN=1“ (recommended). Hat das schonmal jemand nach dem neuen „Verfahren“ ausprobiert?

Edit: auch gibt es wohl Möglichkeiten, dass TOTP zu umgehen, bzw. anders umzusetze.

 

[*kw*]

Nur kurz als Feedback: ich habe für den Moment das Zertifikat mit der bestehenden account.conf und "--force" erfolgreich erneuern können. Der Haken beim hook (was ein Wortspiel... ) war, dass ich wieder händisch einen TOTP eingeben musste.

Edit: Uups...die DS hat jetzt ein gültiges Neues angelegt. Okay, das alte gelöscht und kann mich jetzt in Ruhe mal bis zum 12.08. mit den Neuerungen befassen.

 

[Kachelkaiser]

Fotos7Videos

die xxx.myds.me

Der Name ist hier Programm oder?

 

[Janüscht]

@*kw*

1. TEMP_ADMIN funktioniert nur bei einer nativen Installation von ACME, nicht in Docker oder einer Remote-Verbindung
2. gehe ich davon aus das die Ursache für den Ablauf nicht das Zertifikat war, sondern der Deplöy in der DS

Du solltest vorher überprüfen, ob das Zertifikat erneuert wurde. Das geht einfach in den Zertifikate-Ordner anhand der Dateien und der passenden Config. Auch das Log ist Hilfreiche. Bei auftretenden Problemen kann es hilfreich sein den Log extern zu speicher. Ansonsten wird bei Aktualisieren der Docker-Container den Log zurückgesetzt/gelöscht.

Wenn du ein Backup hast, würde ich noch einmal nachsehen. Auch wäre der erste Schritt den Deploy noch einmal auszuführen (3. Befehl) anstatt mit --force das alles zu erzwingen. Eine Lösungssuche ist das nicht, was du da betreibst. Nebenbei würden vor einigen Tagen 2 wichtige Änderungen in Bezug mit 2FA gefixt. Auf Github findest du mehr.

 

[*kw*]

@Janüscht: danke für die Rückmeldung.

Ich wollte mich kurz fassen, daher vielleicht die "Verwirrung" in meiner Beschreibung. Ich bin schon der Reihe nach vorgegangen.

nicht das Zertifikat war, sondern der Deplöy in der DS

Genau. Weil...

ob das Zertifikat erneuert wurde

...wurde es nicht. Letztes Datum der cert-files aus April

Auch das Log ist Hilfreiche.

Hab ich als erstes nachgeschaut, alles im grünen Bereich. Der tägliche "check" (hier: gestern) ohne Auffälligkeiten.

Auch wäre der erste Schritt den Deploy noch einmal auszuführen

Hatte ich so gemacht, da kam ein Fehler wegen "SYNO_DEVICE_ID="" ...obwohl nicht gesetzt, ebenso beim manuellen "einfachen" renew.

Erst danach habe ich per "--force" renewed. Die geladenen cert-files hatten allesamt das aktuelle Datum von heute und auch der anschließende deployhook (nochmalige Eingabe eines TOTP) wurde fehlerfrei ausgeführt. Nächster renew am 13.08.

Im Anschluss hatte ich zwei Zertifikate, wobei das neue als Standard gesetzt und das Alte gelöscht habe. Systemseitig funktioniert alles wieder.

2 wichtige Änderungen in Bezug mit 2FA gefixt.

Schau ich mir an

PS: an den config-files habe ich nichts geändert, ich konnte alles - wie beschrieben - mit den Bestandsdaten durchführen.

Edit: ich habe nochmal ins gesamte (verfügbare) Protokoll geschaut. Am 30.04 wurde eine neue Version installiert, seitdem aber keine fehlerhaften/error Einträge.

 

[Janüscht]

In deinem Log steht, dass das Zertifikat noch aktuell war und deshalb geskippt wird.
Interessant ist der Log wann das Zertifikat vorher abgelaufen war, also heute -30Tage als Beispiel.
Wenn du Watchtower für acme benutzt, sollte das Log zu diesem Zeitraum in der DS leer sein! Deshalb kann das bei mehrfachen Probleme, besonders in Docker, ratsam sein, ein externes Log anzulegen. Das geht auch ganz einfach in der account.conf.

Wenn du Probleme mit dem Deploy hast, ist es ratsam, die Syno-Einträge in der domain.conf im Zertifikatsordner zu löschen und den Deploy noch einmal auszuführen.
"--force" erzwingt das Erneuern des Zertifikates innerhalb der ersten 60 Tage, das hat aber nichts mit dem Deploy und der Device-ID zu tun.

Du bringst einiges durcheinander!

 

[Benares]

Hinweis: Bitte auch darauf achten, dass die Env-Variablen für den Deploy inzwischen alle großgeschrieben werden, früher war das mal "Hoppelschrift".
Ich habe mir kürzlich den Wolf gesucht, weil ein älteres Deploy-Script von mir, das das Zertifikat an mehrere DSen verteilt, es mehrfach nur an eine DS ausgeliefert hat.

 

[Fusion]

Eine neue Ausstellung mit nativer Installation und temp Admin (mit vorübergehender automatischer Deaktivierung von erzwungenem 2FA für admins) habe ich durch. Sehe ich dann ab Mitte Juni, ob die Erneurungen auch klappen.

Mal schauen, ob irgendwann mal eine Lösung da ist die ohne vorübergehende Deaktivierung von Sicherheitseinstellungen, Dritttools (oathtool, Klartext Shared Secret für TOTP), und Verrenkungen funktioniert.
Der zentrale Deploy war schon angenehm bzw. Webiger Pflegeaufwand als jetzt wieder native Installation auf jeder DS.

 

[Janüscht]

@Benares
Das wurde zwar geändert, hat aber aktuell keinen Einfluss und ist auch so im Script berücksichtigt (Zeile 58-66):

# Get username and password, but don't save until we authenticated successfully
  _migratedeployconf SYNO_Username SYNO_USERNAME
  _migratedeployconf SYNO_Password SYNO_PASSWORD
  _migratedeployconf SYNO_Device_ID SYNO_DEVICE_ID
  _migratedeployconf SYNO_Device_Name SYNO_DEVICE_NAME
  _getdeployconf SYNO_USERNAME
  _getdeployconf SYNO_PASSWORD
  _getdeployconf SYNO_DEVICE_ID
  _getdeployconf SYNO_DEVICE_NAME

 

[Benares]

Das portiert aber nur die in der domain.conf bereits gemerkten Variablen. Für den Deploy zu mehreren Zielen muss man immer noch was drum rum Scripten, da sich acme.sh leider nur einen Deploy merkt (den letzten).

 

[Janüscht]

Einen Deploy für die angefordertes Zertifikat. Bei einem anderen Zertifikat z.B. Subdomain oder andere Domain kann der Deploy anders sein. Alternativ kann man natürlich auch einen weiteren Container nutzen oder den anderen Client das Zertifikat selbst erstellen lassen. Notfalls eben manuell. Für jeden sollte also etwas dabei sein. Möglichkeiten gibt es genug.

Für die meisten User kommt das aber nicht infrage und die sind schon froh, wenn sie ACME überhaupt zum Laufen zu bekommen.

 

[*kw*]

@Janüscht: leider hatte sich mein Terminal-Fenster aufgehängt, so dass ich die jeweiligen Fehlermeldungen nach Absetzen der Befehle nicht rauskopieren konnte.

Ja, ich nutze Watchtower und ja, bisher war das Log leer. Was ich noch im DS-Log finden konnte, dass der letzte aktive Zugriff vom 13.04. und auch heute



Und ja, die Sache mit der "Syno_Device_ID" hat nichts mit dem deploy zu tun.

Du bringst einiges durcheinander!

Vielleicht drücke ich mich in dem Thema nicht immer zielorientiert aus, aber so lange ich verstehe, was IHR mir mit auf den Weg gebt.

Stand ist:

Le_CertCreateTimeStr='2024-05-14T06:54:58Z'
Le_NextRenewTimeStr='2024-07-12T06:54:58Z'

Und in der domain.conf u.a. diese Einträge:

SAVED_SYNO_USE_TEMP_ADMIN=''
SAVED_SYNO_USERNAME='ein-admin-user'
SAVED_SYNO_PASSWORD='xxxxxxxxxxxxxxxxxxxxxx'

die Syno-Einträge in der domain.conf im Zertifikatsordner zu löschen und den Deploy noch einmal auszuführen.

Werde ich beim nächsten Mal tun.

Gibt's jetzt noch irgendwas, was ich im Nachgang an Daten/Infos (sofern noch vorhanden) bereitstellen kann, um dem Problem auf die Schliche zu kommen? Was sollte ich an Daten im Auge behalten?

Wie gesagt, auch wenn das keine "wissenschaftliche Abarbeitung/Ursachenermittlung" war, das aktuelle Zertifikat im Sinne einer Neuinstallation zu deployen, hat funktioniert.

So, und jetzt immer feste druff...

 

[*kw*]

Okay, was ich jetzt im deploy-script zum Thema 2FA gefunden habe:

2FA-OTP optional variables (with your own admin user)
#   - export SYNO_OTP_CODE="XXXXXX" - if set, script won't require to
#                                     interactive input the OTP code
#   - export SYNO_DEVICE_NAME="CertRenewal" - if set, script won't require to
#                                             interactive input the device name

Was ich in der Vergangenheit rausgefunden hatte, dass acme beim deploy tatsächlich einen zeitlich gültigen TOTP-Wert haben möchte und nicht den TOTP-Code. Bedeutet, wennn ich jetzt in der Account-Conf unter "SYNO_OTP_CODE" den (bspw.) rot markierten Code

otpauth://totp/admin-user@DATENSERVER?secret=A8D8GJDKVNDLFIDN&issuer=Synology%20DSM&hwid=fe37bfd6ddb435bd65922494......

setze, dann fällt beim deploy die Fehlermeldung weg, weil aktuell eine händische Eingabe des sechsstelligen Zahlenwertes nicht vonnöten ist?

Das "CertRenewal" wiederum habe ich gesetzt.

 

[Janüscht]

Du kannst noch eine externe Log-Datei erstellen, um ein Logverlust durch ein Container-Update vorzubeugen. Alternativ würde auch das Herausnehmen von acme.sh in Watchtower den Verlust vorbeugen

Das Log-File ist aber am einfachsten einzustellen, ohne die Container bearbeiten zu müssen. Dazu musst du nur in deiner account.conf folgendes einfügen:

# Log
LOG_FILE='/acme.sh/acme.log'
LOG_LEVEL='1'

Log Level = Debug-Level (falls du nach einem Log in Github gefragt wirst). Für dein Problem reicht aber der einfache Log vollkommen aus. Erst wenn das nicht mehr ausreichend ist, kannst du auf Level 2 setzen. Das ist aber viel detailreicher und natürlich für ungeübte auch unübersichtlicher.

Nach der Änderung der account.conf führst du einfach noch einmal den Deploy aus und die acme.log sollte angelegt werden. Jetzt ist es egal, ob der Container ein Update bekommt und wenn keine Probleme mehr auftreten kann das Log auch einfach mit einer # deaktiviert werden:

# Log
#LOG_FILE='/acme.sh/acme.log'
#LOG_LEVEL='1'

Bei einem Deploy mit 2FA musst du nicht extra in der account.conf einstellen. Das wird interaktiv gemacht und in der domain.conf gesichert. Letztendlich musst du nur den TOTP eingeben und weiter "entern". Ob man auf der eingesetzt NAS (lokal) eine 2FA und HTTPS für den internen Import braucht, muss auch jeder selbst entscheiden. Ich sehe die Vorteile eher für einen Remote-Import auf ein anderes Gerät. Man oder Mann kann es auch oft übertreiben

 

[*kw*]

Das wird interaktiv gemacht und in der domain.conf gesichert.

nur den TOTP eingeben und weiter "entern".

Das habe ich gemacht und nach erfolgreichem deploy einen hash-Wert eingetragen bekommen. Ich dachte, danach wäre der Käse für die Zukunft erledigt.



Am Rande, ganz dunkel kommt mir einen Erinnerung um die Ecke, keine Ahnung ob die ursächlich ist. Wenn ja, ganz hessisch-like "Dabbischkeit"...

Beim letzten erfolgreichen deploy war in der Systemsteuerung keine Zertifikatsbeschreibung vorhanden. Wahrscheinlich, weil ich im Vorfeld keine angegeben hatte. Das habe ich im Nachgang händisch in der Systemsteuerung ("Let's Encrypt") eingetragen. Im Aktuellen steht's jetzt jedenfalls drin und ich warte mal den 12.08. ab.

PS: Die 2FA-Variante habe ich nur gewählt, weil ich in den github-Recherchen über eine Mitteilung gestolpert bin, dass Synology künftig keine TOPT-freien deployhooks mehr zulassen will.