DSM 7.0 Selbsterstellte Zertifikate erneuern DSM7

ChiliApple

Benutzer
Mitglied seit
04. Dez 2013
Beiträge
240
Punkte für Reaktionen
7
Punkte
24
Hallo,

nachdem in DMS7 scheinbar keine Möglichkeit mehr gegeben ist über die GUI ein selbsterstelltes Zertifikat zu erneuern, wäre eine Lösung dazu super.
Wie erneuert man mittels Key und CSR das Zertifikat?

Hab das Standard und Directory Zertifikat zu erneuern.

Danke



Bildschirmfoto 2021-07-12 um 11.55.18.png

Bildschirmfoto 2021-07-12 um 11.51.36.png
 

Anhänge

  • Bildschirmfoto 2021-07-12 um 11.51.36.png
    Bildschirmfoto 2021-07-12 um 11.51.36.png
    53,1 KB · Aufrufe: 26

DeepNAS

Benutzer
Mitglied seit
09. Jul 2021
Beiträge
20
Punkte für Reaktionen
9
Punkte
3
Kann man denn in DSM 7 überhaupt noch ein selbstsigniertes Zertifikat erstellen?
Ich habe aktuell nur ein virtuelles DSM 7 laufen. Dort gibt es die Option gar nicht mehr. Nur noch import und Let's Encrypt sind möglich.
 

ChiliApple

Benutzer
Mitglied seit
04. Dez 2013
Beiträge
240
Punkte für Reaktionen
7
Punkte
24
wäre mir nirgends unter gekommen, passt angeblich nicht zu TLS 1.3
Aber erneuern wäre ja möglich mit KEY und CSR, nur weiß ich nicht wie, Zertifikate is nicht so meins
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.291
Punkte für Reaktionen
2.860
Punkte
423

Peter_Lehmann

Benutzer
Mitglied seit
10. Jun 2013
Beiträge
176
Punkte für Reaktionen
10
Punkte
24
Hier meine Erfahrungen zu diesem Thema.
Vorbemerkungen:
  1. Meine beiden (privat betriebenen) NAS laufen rein intern in meinem Heimnetz. Sämtliche Zugriffe aus dem Internet laufen über mein ebenfalls privat betriebenes Wireguard-VPN. Damit dürfte klar sein, dass die Zertifikate von LE "außen vor" sind, denn ich möchte ja keinen direkten Zugriff aus dem Internet. Trotzdem, schon weil moderne Browser einfach TLS verlangen, betreibe ich auch intern alle Verbindungen verschlüsselt.
  2. Ich habe meine letzten 15 Arbeitsjahre vor der Pensionierung in leitender Tätigkeit in einem großen TrustCenter verbracht, und auch als Pensionär betreibe ich weiterhin eine privat betriebene CA und generiere für Interessenten jedes Jahr mehrere 100 Zertifikate für S/MIME und TLS.
Als ich meine DS220+ auf DSM 7 aktualisiert hatte, hatte ich auf einmal das Problem, dass ich nicht mehr deren GUI erreichte. Dummerweise war die Umleitung von http auf https aktiviert. Zum Glück konnte ich das Problem per ssh lösen. Näheres dazu steht in einem gesonderten Thread.

Ich habe also zuerst (nachdem ich wieder das GUI erreichte) sofort vor dem Import der neuen Zertifikate die Umleitung auf https deaktiviert => Empfehlung!
Dann habe ich mit dem von mir genutzten tollen Programm "XCA" ein reines TLS-Serverzeritifikat (ohne kritische Einschränkungen) generiert. (Ich nutze Templates für S/MIME-, Server-, VPN- und sonstige Zertifikate.)
Dieses Zertifikat wurde selbstverständlich mit meinem üblichen vorhandenen und 20 Jahre geltenden CA-Zertifikat signiert, welches auch als vertrauenswürdiger Herausgeber in allen meinen Gerätschaften und denen meiner "Kunden" importiert ist.

Nun habe ich im .pem-Format exportiert:
- cert.pem (also das eigentliche Server-Zertifikat)
- key.pem (den private-key des Servers, selbstvertändlich ohne Transport-Verschlüsselung)
- zwischencert.pem (was nichts anderes als das _öffentliche_ Zertifikat meiner CA ist)
Diese 3 Dateien per GUI importiert, einen reboot gemacht und alles lief wieder per https. Nach einigen Tests dann wieder die Umleitung mit dem Zwang von https aktiviert.
Eigentlich genau so, wie ich das schon alle Jahre vorher gemacht habe.

Selbstverständlich kann man das auch in Handarbeit auf der Konsole mit keygen und den entsprechenden Parametern machen, aber per XCA geht es eben (zumal ich ja sehr viel damit mache) viel einfacher. Und ich bestehe auch (so wie ich das ja viele Jahre gewohnt war!) auf die Signatur durch ein eigenes CA-Zertifikat. Schon damit mein Browser und die anderen Geräte dauerhaft "zufrieden" sind. Ausnahmeregelungen und das Generieren eines cert als CA-Zertifikat widerstreben mir.

Viel Erfolg!
MfG Peter
 
  • Like
Reaktionen: ErichBV228

DeepNAS

Benutzer
Mitglied seit
09. Jul 2021
Beiträge
20
Punkte für Reaktionen
9
Punkte
3
Ich habe die Option in DSM7 auch schon gesucht und nicht gefunden.

OK. Dann gibt es die Option in der GUI des DSM 7 nicht mehr… Dachte evtl. liegts nur an der VM Version.

Immerhin hat gerade das testweise importieren beliebiger Zertifikate noch funktioniert. ;)


Wenn du ein Zertifikat erneuern willst, ist das im Grunde auch der gleiche Vorgang wie das neu erstellen – außer das man nicht die ganzen Werte für Namen und DNS Namen etc. neu eingeben muss.

Habs gerade probiert. Wenn man bei einem Zertifikat in DSM auf erneuern klickt, bekommt man einen Download mit einer ZIP-Datei, welche einen neuen privaten Key (*.key) und den Zertifikatrequest (*.csr) enthält. Diese würde man dann zu einer kommerziellen Zertifizierungsstelle schicken und bekäme dann von denen das Zertifikat zurück – oder man erzeugt sich das Zertifikat halt selbst - was dann aber aufgrund der nicht in den Betriebssystemen vorhandener „ist schon so in Ordnung“ root Zertifikate als „nicht vertrauenswürdig“ abgestempelt wird. Will man das vermeiden, muss man wie in dem Post zuvor von Peter beschrieben ein entsprechendes Root Zertifikat im Betriebssytem und/oder den benutzen Browsern/Software hinterlegen.


Die grundsätzliche Vorgehensweise ist wie folgt (wenn du aus DSM heraus erneuerst überspringst du die ersten beiden Schritte – das hat DSM quasi schon erledigt):

Vorab braucht man Openssl. https://www.openssl.org/source/
In Linuxen ist das meist schon installiert, oder kann über die Paketverwaltung nachinstalliert werden. Für Windows gibt es aber auch einen fertig kompilierten Installer (https://slproweb.com/products/Win32OpenSSL.html)

  1. privaten Schlüssel erstellen (Beispiel für 4096 Bit langen RSA-Key):
    openssl genrsa -out test_key.pem 4096

  2. Certificate Signing Request für den Key erstellen:
    openssl req -new -key test_key.pem -out test_request.pem

  3. selbst signiertes Zertifikat erstellen (Beispiel für 365 Tage Gültigkeit):
    openssl x509 -req -days 365 -in test_request.pem -signkey test_key.pem -out test_cert.pem

Die Dateiendungen können statt .pem auch anders lauten wie z.B. bei den von DSM erstellten .key / .csr oder was auch immer - das sind alles im Grunde Textdateien.
Die Gültigkeitsdauer würde ich ehrlich gesagt richtig lang machen. Mir fällt eigentlich kein vernünftiger Grund ein, bei einem selbstsignierten Zertifikat eine regelmäßige Erneuerung einzubauen. Da du ja selbst dafür „gerade stehst“ und es in deiner eigenen Kontrolle liegt, kannst du bei Bedarf jederzeit das Zertifikat löschen/erneuern, wenn du der Meinung bist es wurde irgendwie kompromittiert o.ä.
 

ChiliApple

Benutzer
Mitglied seit
04. Dez 2013
Beiträge
240
Punkte für Reaktionen
7
Punkte
24
Danke für Eure Antworten!

Mit openssl hat es wunderbar geklappt.

bG
 

roterteufel81

Benutzer
Mitglied seit
30. Nov 2012
Beiträge
252
Punkte für Reaktionen
59
Punkte
28
Uff, dass bedeutet auch, dass man ab nun auf jedem OpenVPN Client (z.B. iPhone, iPad oder Laptop) alle 3 Monate das Client-Zertifikat von Hand erneuern muss, wenn man nicht noch auf einem alten Langzeit-Bestands-Zertifikat von Synology sitzt.

Habe für OpenVPN das Let's Encrypt Zertifikat bislang aus Bequemlichkeit als Einziges ausgeschlossen. Immerhin konnte man das vorhandene Zertifikat mit Laufzeit bis 2038 beim Update übernehmen.

Bei FTPS muss man im FileZilla ja lediglich "Vertraue dem geänderten Zertifikat" klicken

Bei WebDAV hab ich es noch gar nicht verstanden, da WebDAV erst gar keine Meldung oder Hinweise zum Zertifikat bringt (z.B. KyPass App vom iPhone zum Zugriff auf Keepass) und einfach klappt?

Einzig für Synology Moments, bzw. jetzt Photos war es unabdingbar, da mit dem selbst unterschriebenem Zertifikat keine Videoausgabe (außer HTTP und das will ich sicherlich nicht für unterwegs) möglich war.

Im LAN muss man dann sowieso immer eine Ausnahmeregelung für Browser hinzufügen, weil niemand zu Hause den Loop über Dyn zur DS nutzt.

Und TLS 1.3 Only ist auch noch ein wenig witzlos auf der Synology, da viele Apps (zumindest iOS) noch kein TLS 1.3 können (bei DS File hat man es jetzt mal hinzugefügt, Drive, Photos Mobile und DS Finder klappt auch, DS Audio z.B. nicht und DS Cam auch nicht).

Alles irgendwie noch halbgar umgesetzt.

2021-07-13 23_14_07.png
 
Zuletzt bearbeitet:

whocares

Benutzer
Mitglied seit
10. Okt 2018
Beiträge
52
Punkte für Reaktionen
1
Punkte
8
Hallo und danke für die hilfreichen Beiträge. Ich bin auch dabei, mir ein Zertifikat zu erstellen, damit die Fehlermeldungen verschwinden. Des Weiteren funktioniert das Öffnen von Videos per App "Photos" vom Handy aus nicht. Ich vermute, dass hat etwas mit dem Nicht-Vorhandensein eines gültigen Zertifikats zu tun. Ich nutze das NAS ausschließlich im privaten Netzwern; kein Zugriff von außen möglich.
Ich habe, wie DeepNas es dankenswerterweise super beschrieben hat, die drei Dateien erstellt und das Zertifikat als Standard eingestellt. Auch habe ich das Zertifikat Google Chrome hinzugefügt. Nach einem Test erscheint jedoch noch immer der ein Fehler in Chrome:
Zertifikat ungültig: Dieses Zertifizierungsstellen-Stammzertifikat ist nicht vertrauenswürdig. Installieren Sie das Zertifikat in den Speicher vertrauenswürdiger Stammzertifizierungsstellen, um die Vertrauensstellung zu aktivieren.
Ich vermute, hier muss ich ein Root-Zertifikat erstellen / hinzufügen? Hier weiß ich leider nicht, wie weiter vorzugehen ist.
Bei den Einstellungen im NAS wusste ich übrigens nicht, welche der drei selbst erzeugten Dateien ich als "Zwischenzertifikat" angeben muss. Dort habe ich dann die Datei, die im 3. Schritt (= das Zertifikat) von DeepNas' Beschreibung erzeugt wird, angegeben.
 

roterteufel81

Benutzer
Mitglied seit
30. Nov 2012
Beiträge
252
Punkte für Reaktionen
59
Punkte
28
Selbst erstellte/signierte Zertifikate sind, wie es in der Meldung steht, nicht vertrauenswürdig, können sie auch nicht, da niemand überprüfen kann, ob sie vertrauenswürdig sind. Daher die Fehlermeldung.

Offizielle Zertifikate (z.B. Let's Encrypt) funktionieren immer nur mit einer echten URL, prinzipbedingt niemals mit LAN IPs.

Für DSM heißt das im Browser: Entweder man übergeht die Fehlermeldung unter hinzufügen einer Ausnahme, oder aber man legt sich eine DynDNS Adresse und ein offizielles Zertifikat zu und ruft die DSM Weboberfläche aus dem eigenen LAN über DynDNS mit Zertifikat via NAT-Loopback auf.

Zu der HTTPS Wiedergabe mit Photos habe ich gestern eine Anleitung (ich nutze es so wie dort beschrieben) geschrieben, wie es funktionieren kann. Hier kann man keine Ausnahme hinzufügen und die Fehlermeldung übergehen. Das klappt nur mit Zugriff via DynDNS + offiziellem Zertifikat (z.B. Let's Encrypt). Auch hier aus dem eigenen LAN dann eben als NAT-Loopback.

Siehe:

https://www.synology-forum.de/threa...sache-mit-der-portfreigabe.116446/post-959516
 
  • Like
Reaktionen: whocares

whocares

Benutzer
Mitglied seit
10. Okt 2018
Beiträge
52
Punkte für Reaktionen
1
Punkte
8
Selbst erstellte/signierte Zertifikate sind, wie es in der Meldung steht, nicht vertrauenswürdig, können sie auch nicht, da niemand überprüfen kann, ob sie vertrauenswürdig sind. Daher die Fehlermeldung.
Ich dachte genau diese Tatsache könnte man mit einem Root-Zertifikat "umgehen"?

Dein Lösungsvorschlag (vielen Dank!) per DynDNS: setzt das voraus, dass mein Router Fritzbox 7590) per Internet erreichbar ist?
 

Peter_Lehmann

Benutzer
Mitglied seit
10. Jun 2013
Beiträge
176
Punkte für Reaktionen
10
Punkte
24
Die Frage aller Fragen ist doch, wer sich per TLS mit einem Dienst auf der DS (oder überhaupt im eigenen Hausnetz) verbinden soll oder darf.
Darf es "Hinz & Kunz", dann ist es schon gut und empfehlenswert, wenn im Browser das Ausstellerzertifikat eines etablierten Zertifikatsausstellers gespeichert ist. So, wie es bspw. bei LE oder einem anderen Aussteller der Fall ist.

Handelt es sich aber bei den Zugangsberechtigten um eine definierte Menge von persönlich bekannten Personen (ich selbst, Familie, Freunde usw.) dann steht absolut nichts dagegen, das viele Jahre gültige Ausstellerzertifikat der eigenen "Privat-CA" an diese Personen zu verteilen (kann ja, weil nur den öffent. Schlüssel enthaltend, per Mail oder per eigener Webseite erfolgen) und von diesen (die ja genau wissen, dass es von mir kommt und mich persönlich kennen!) unter den vertrauenswürdigen Herausgebern im Browser und auch im Mailclient (bei Nutzung von S/MIME) installiert werden.
Und so wie ich es aus meiner beruflichen Tätigkeit gewohnt war, erzeuge ich jährlich (!) neue Schlüssel für TLS und S/MIME. Von ersteren bemerken die Nutzer meiner Dienste nichts, denn mein Herausgeberzertifikat ist noch eine Weile gültig.
Das beliebte Hinzufügen einer so genannte "Ausnahmegenehmigung" ist IMHO eine schlechte Krückenlösung.
 

roterteufel81

Benutzer
Mitglied seit
30. Nov 2012
Beiträge
252
Punkte für Reaktionen
59
Punkte
28
Ich dachte genau diese Tatsache könnte man mit einem Root-Zertifikat "umgehen"?

Dein Lösungsvorschlag (vielen Dank!) per DynDNS: setzt das voraus, dass mein Router Fritzbox 7590) per Internet erreichbar ist?

Ich kenne keine andere Lösung für eine von Synology akzeptierte Umsetzung zur Wiedergabe von Videos über Synology Photos (und auch vorher Moments).

Und ja, die Fritz, bzw. viel mehr das Gerät des weitergeleiteten Ports dahinter, würde dann über z.B. MyFritz DynDNS von außen erreichbar sein.

Aber halt nur auf dem einen Port, den man für Synology Photos (oder bei 6.2.4 Moments) freigibt (der Port ist aber halt der DSM Port und somit auch gleichzeitig für DSM/Calendar/Drive in Nutzung).

Die Synology wird somit von außen auch für einen Fremden erreichbar, sofern er a) die DynDNS Adresse und b) gleichzeitig den weitergeleiteten Port und c) den passenden Benutzernamen, der das Recht für den Zugriff und d) das Passwort dazu (und optional, aber dringend empfohlen e) den aktuellen 2FA Key) kennt.

Außerdem braucht man, wie beschrieben den Port 80 aus dem Internet Richtung Synology über die DynDNS Adresse offen, wenn man das Let's Encrypt Zertifikat nutzen möchte.

Die Port Übersicht gibt es hier: https://kb.synology.com/de-de/DSM/tutorial/What_network_ports_are_used_by_Synology_services

Und deshalb habe ich in meiner Beschreibung auch so ausführlich alles dokumentiert.

Wer sich natürlich nie mit ordentlichem Benutzer(gruppen)management, Zugangs- und Firewallregeln, sowie Zertifikat etc. beschäftigt und einfach nur seine Synology sperrangelweit in seinem LAN genutzt hat, der hat - sofern er solche Dienste korrekt nutzen möchte - jetzt ein Problem erst mal seine Synology auf Vordermann zu bringen.


Die Frage aller Fragen ist doch, wer sich per TLS mit einem Dienst auf der DS (oder überhaupt im eigenen Hausnetz) verbinden soll oder darf.
Darf es "Hinz & Kunz", dann ist es schon gut und empfehlenswert, wenn im Browser das Ausstellerzertifikat eines etablierten Zertifikatsausstellers gespeichert ist. So, wie es bspw. bei LE oder einem anderen Aussteller der Fall ist.

Handelt es sich aber bei den Zugangsberechtigten um eine definierte Menge von persönlich bekannten Personen (ich selbst, Familie, Freunde usw.) dann steht absolut nichts dagegen, das viele Jahre gültige Ausstellerzertifikat der eigenen "Privat-CA" an diese Personen zu verteilen (kann ja, weil nur den öffent. Schlüssel enthaltend, per Mail oder per eigener Webseite erfolgen) und von diesen (die ja genau wissen, dass es von mir kommt und mich persönlich kennen!) unter den vertrauenswürdigen Herausgebern im Browser und auch im Mailclient (bei Nutzung von S/MIME) installiert werden.
Und so wie ich es aus meiner beruflichen Tätigkeit gewohnt war, erzeuge ich jährlich (!) neue Schlüssel für TLS und S/MIME. Von ersteren bemerken die Nutzer meiner Dienste nichts, denn mein Herausgeberzertifikat ist noch eine Weile gültig.
Das beliebte Hinzufügen einer so genannte "Ausnahmegenehmigung" ist IMHO eine schlechte Krückenlösung.

Das Problem ist, dass Synology Photos (und auch vorher Moments) keine selbst erstellten Zertifikate mehr akzteptiert. Man kann es nicht einfach übergehen. Ich habe ja, dank 6.2.4 auch noch mein Synology Zertifikat, welches bis 2038 gültig ist. Für Photos ist das Ding absolut nutzlos. Es funktionieren nur offiziell anerkannte Zertifikate, sonst keine Video-Wiedergabe, nicht mal im eigenen LAN (per NAT-Loopback).

Neue eigene Zertifikate kann man seitens Synology sowieso gar nicht mehr erstellen. Diese Option wurde mit 7.0 ersatzlos gestrichen.

Neue offizielle Zertifikate sind seit der neuesten Anpassung vom 01.09.2020 (https://www.heise.de/news/Browser-H...rtifikats-Lebensdauer-auf-1-Jahr-4796599.html) auch nur noch maximal 12 Monate gültig, die von Let's Encrypt sogar nur 3 Monate.
 
Zuletzt bearbeitet:

Peter_Lehmann

Benutzer
Mitglied seit
10. Jun 2013
Beiträge
176
Punkte für Reaktionen
10
Punkte
24
Gut, ich nutze kein Synology Photos, kann deswegen weder damit etwas testen noch deine Aussage bestätigen oder verneinen.
Ich nutze die von mir per XCA hergestellten Zertifikate "nur" für das mir zugängliche Zertifikat der DS. Also, ich ersetze damit das von der DS selbst generierte angebliche Synology-Zertifikat.
Ich erzeuge ein ganz normales Serverzertifikat im PEM-Format (private-Key und public-Key mit den üblichen Begrenzern in einer pem-Datei). Und dann füge ich in dieser Datei noch das (öffentliche) Zertifikat meiner CA, welche ja dieses Serverzertifikat signiert hat, hinzu.
Und selbstverständlich ist bei allen berechtigten Nutzern das Herausgeberzertifikat meiner CA im Browser (und im Mailclient) installiert.
Aber, wie schon oben geschrieben, k.A., ob das mit "Photo" so funktioniert. Und eigentlich kann man das nur verhindern, wenn in diesem Programm ein eigener Zertifikatsspeicher mit einer Serie von Herausgeberzertifikaten etablierter TrustCenter vorhanden ist und abgeprüft wird. Wenn das so ist, dann müsste man ja auch dort per scp sein Herausgeberzertifikat ablegen können. Aber genau das kann und will ich (mangels Bedarf) nicht testen.
 

whocares

Benutzer
Mitglied seit
10. Okt 2018
Beiträge
52
Punkte für Reaktionen
1
Punkte
8
Tja schade, dann wird das nichts mit Videos streamen bei mir. Denn das NAS per Internet zugänglich zu machen per DynDns, um ein Let's Encrypt Zertifikat nutzen zu können, führt das Thema Sicherheit komplett ad absurdum. Davon abgesehen ist es, Deutsche Glasfaser sei Dank, wegen der öffentlichen ipv6 Adresse, recht umständlich, per Internet auf das Heimnetzwerk zuzugreifen.
 

Peter_Lehmann

Benutzer
Mitglied seit
10. Jun 2013
Beiträge
176
Punkte für Reaktionen
10
Punkte
24
... sei Dank, wegen der öffentlichen ipv6 Adresse, recht umständlich, per Internet auf das Heimnetzwerk zuzugreifen.
Ist mir noch gar nicht aufgefallen, dass das mit IPv6 "umständlicher" ist.
TIPP: Vielleicht mal intensiv mit IPv6 befassen? JA, es bedarf eines dgewissen Umdenkens. Aber umständlicher?
 

whocares

Benutzer
Mitglied seit
10. Okt 2018
Beiträge
52
Punkte für Reaktionen
1
Punkte
8
Die öffentliche ipv6 Adresse war nur die halbe Wahrheit. Wollte hier jetzt nicht die Details breittreten, aber es ist eben nicht ganz ohne, einen Anschluss der Deutschen Glasfaser von außen erreichbar zu machen. Wen es interessiert, findet hier weitere Infos (1. Antwort). TIPP: Vielleicht mal mit Deutsche Glasfaser befassen. ;-)
 

synfor

Benutzer
Sehr erfahren
Mitglied seit
22. Dez 2017
Beiträge
8.583
Punkte für Reaktionen
1.433
Punkte
288
Auch wenn man nicht ins Detail gehen will, muss man keinen Unsinn erzählen. Die öffentliche IPv6-Adresse ist nach wie vor nicht das Problem.
 

roterteufel81

Benutzer
Mitglied seit
30. Nov 2012
Beiträge
252
Punkte für Reaktionen
59
Punkte
28
Tja schade, dann wird das nichts mit Videos streamen bei mir. Denn das NAS per Internet zugänglich zu machen per DynDns, um ein Let's Encrypt Zertifikat nutzen zu können, führt das Thema Sicherheit komplett ad absurdum.
Es ist eher umgekehrt. Ein https Zertifikat für eine interne LAN IP-Adresse als vertrauenswürdig zu zertifizieren, würde Zertifikate ad absurdum führen.

Wäre das erlaubt, wäre ein Zertifikat für z.B. 192.168.1.10 auf jedem System dieses Planeten mit selber IP zertifiziert und Du könntest jedes System durch Änderung seiner IP zu einem vertrauenswürdigen Client erklären.

Ein Zertifikat auf lokaler IP Ebene würde die Sicherheit an dieser Stelle gegen 0 runterschrauben.

Und mit Let‘s Encrypt hat das nichts zu tun. Es gilt für alle Zertifizierer aller Zertifikate.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Wildbill


 

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