[wiregate] Timberwolf Server - Erste Schritte / Anfängerfragen

[brinchi]

Jetzt bin ich zwar stolzer Besitzer eines schicken blauen Timberwolf 2400-Servers (ohne WLAN), weiss jedoch nicht so recht, wie ich loslegen soll, zumal das Handbuch noch in Arbeit ist und mir momentan keine weitere Dokumentation bekannt ist.
Es stellen sich mir folgende triviale Fragen:

1) Worauf sollte man beim Anschluss von Timberwolf und TP-UART (Reihenfolge, Qualität der USB- und Ethernetkabel etc.) achten?

2) Wie erhält man Zugriff zum Timberwolf, sprich: Wo bekommt man die PIN zur Nutzung mit dem Token und wie ruft man den Server im Browser auf?

3) Wie setzt man den Timberwolf in der ETS auf?

Merci vielmal

[gbglace]

1)
TP-UART Busklemme abziehen, Busleitung rot in rot schwarz in schwarz, USB von TP-UART an TWS, Busklemme in TP-UART stecken.
Mitgeliefertes Patchkabel vom Router / Switch an TWS.
Stromversorgung an TWS dann Netzteil in Steckdose, TWS anschalten

2)
Im Browser https://timberwolfXXX.local/#/login eingeben. XXX steht für die lfd-Nummer Deines TWS. (DHCP am Router aktiviert!?)

ggf meckert dein Browser wg fehlendem Zertifikat, mit einigem Geklicke kann man einen Browser auch noch überreden eine nicht https Seite zu starten (im Beta gab es einen Link für den Zertifikat download, ggf goto Support)

3)
Im Beta bisher download einer ETS-Projektdatei mit dem TWS als Gerät (hier ebenfalls goto Support für download-link der Applikation oder vorerst Projektfile)


Anpassungen zum Vorgehen Beta vs Produktion ab offensichtlich jetzt wird Stefan sicher noch kundtun. Oder es gibt eine Kunden Mail mit kurzem Überblick Schnellstartanleitung.

[StefanW]

Hallo Brian,

Jetzt bin ich zwar stolzer Besitzer eines schicken blauen Timberwolf 2400-Servers (ohne WLAN), weiss jedoch nicht so recht, wie ich loslegen soll, zumal das Handbuch noch in Arbeit ist und mir momentan keine weitere Dokumentation bekannt ist.

Leider wurde Dir versehentlich die Doku mit den Hinweisen für die Beta-Tester (und im Moment sind alle Kunden, die während der Beta-Zeit einen Server bekommen auch automatisch Betatester) nicht übersandt. Das habe ich vorher nachgeholt.


Für Betatester gilt die Regel: Keine Details im Forum, wir klären alle Probleme im Support. Vor allem aus Vereinfachungsgründen, zudem möchte ich vermeiden, dass die ein oder andere Kinderkrankheit (die mancher vielleicht auch erst in zwei Jahren liest und den Connect zu derzeitigen Beta nicht bekommt) zu Missverständnissen beim Eindruck führt. Das ist etwas, dass wir aus dem WireGate Server gelernt haben, da entstehen sehr schnell unzutreffende Eindrücke.


==> Sollte noch ein Betatester ohne Beta-Newsletter sein, bitte im Support melden, wir schicken die Info umgehend nach.


Merci

Stefan

[StefanW]

Um nun auch die Fragen zu beantworten, weil das wird sicher den ein oder anderen interessieren:

1) Worauf sollte man beim Anschluss von Timberwolf und TP-UART (Reihenfolge, Qualität der USB- und Ethernetkabel etc.) achten?

Eigentlich (fast) nichts.

• Ethernet-Patch-Kabel OHNE Metallschirm an den Steckern an ETH0 anschließen. (Kein Schim, damit der TWS nicht über den Switch geerdet wird).
• USB bis 3 Metern Länge.
• Reihenfolge egal. Es sollte alles Plug´n´Play sein.

Allerdings: Wenn man Daten aus dem WireGate für Sensoreinstellungen und Aufzeichnungen übernehmen will, muss man ERST den Import aus dem WireGate komplett und fehlerfrei durchgezogen haben, BEVOR man den Busmaster mit den Sensoren ansteckt. Ansonsten: Meldung beim Support, wir setzen das dann zurück.

2) Wie erhält man Zugriff zum Timberwolf, sprich: Wo bekommt man die PIN zur Nutzung mit dem Token und wie ruft man den Server im Browser auf?

Das sind drei Themen.

1. Zuerst braucht man eine Verbindung:

Bei WLAN: Der Timberwolf startet (sofern mit WLAN ausgestattet) "out-of-the-Box" mit einer SSID die dem eigenen Gerätenamen entspricht, also "Timberwolf xxxx". Die xxxx sind die laufende Nummer. Einfach verbinden und dann im Browser "timber.wolf" eingeben (gilt nur bei WLAN)

Bei LAN: Der Server steht bei ETH0 auf DHCP, braucht also einen DHCP-Server. Ist keiner vorhanden, kann man das ETH-Kabel auch mit seinem PC verbinden. Sofern auch der PC auch auf DHCP steht, werden beide eine Adresse aushandeln (169.256.x.y).

Der Timberwolf Server sendet (wie beim WireGate Server auch) seinen Hostnamen nebst IP über Avahi / Bonjour / Zeroconf (ist alles das gleiche). Bei Betriebssystemen von Apple und bei linuxoiden Systemen ist das komplett implementiert, leider hat Microsoft das bei neueren Windowsversionen entfernt.

Will man also aus Windows über den Hostnamen zugreifen, empfehle ich, die Apple-Bonjouer Druckdienst zu installieren: https://support.apple.com/kb/DL999?l...ewlocale=de_DE

Damit sind dann auch die Browser unter Windows in der Lage, die per Avahi / Bonjour / ZeroConf avisierten Dienste zu nutzen und vor allem die Namensauflösung zu betreiben. Das mag auch für andere Boxen gelten, die headless sind.

Also ab in den Browser und timberwolfxxxx.local (xxxx ist die Seriennummer ohne führende Nullen) eingeben. Das sollte reichen.

Kommen wir zu SSL (eigentlich TLS, früher bekannt als https):


2. Das Thema SSL. Hierzu aus dem BETA-Newsletter:

Thema: SSL / TLS Zertifikate für gesicherte Verbindung für Konfigurationsoberfläche („Admin Tool“)

Wir wollen Ihnen mit unserem Beta-Newsletter auch Hintergrund-Informationen zu Entwicklungszielen und Entscheidungen sowie zu den eingesetzten Technologien geben.

Da es derzeit hierüber auch ein paar Diskussionen mit Betatestern gibt, greife ich heute das Thema „gesicherte“ Verbindung mit TLS (via https und http/2) und das vorinstallierte Zertifikat auf.

Vorwort:
Die in den letzten beiden Jahrzehnten immens angeschwollene staatliche Überwachung hat dazu geführt, dass freie Bürger und NGOs die Einführung einer massiven Verschlüsselung, auch in alltäglichen Nutzungsszenarien von IT, gefordert haben.
Golem: CCC fordert striktes Verbot unverschlüsselter Kommunikation
https://www.golem.de/news/crypto-war...01-111883.html
Die Browserhersteller haben nicht nur die Unterstützung von SSL/TLS zügig ausgebaut sondern führen mehrmals im Jahr deutliche Verschärfungen ein. Unverschlüsselte Verbindungen werden mit massiven Warnhinweisen gekennzeichnet, die für die Authentifizierung des Servers verwendeten Zertifikate penibel geprüft. Mittlerweile finden mehrere Dutzend Prüfungen statt, bevor eine Verbindung zwischen Browser und Server überhaupt aufgebaut werden kann.

Die Elaborated Networks GmbH betreibt mit dem ältesten Geschäftsbereich „IT Managed Security“ ein Dienstleistungsangebot für starke Authentifizierung, Verschlüsselung, Firewall und VPN. Selbstverständlich haben wir unser Wissen auch bei der Gestaltung des Timberwolf Servers genutzt und haben Sicherheitsmaßnahmen – soweit bezahlbar – umgesetzt. Hierzu gehört auch die Unterstützung für eine voll verschlüsselte Verbindung zwischen Webbrowser und Timberwolf Server.


Verschlüsselung nur mit Zertifikat:

Die mit TLS 1.2 (Nachfolger von SSL) gesicherten Verbindungen realisieren drei wichtige Sicherheitstechnologien:

• Vertraulichkeit (durch Verschlüsselung)
• Integrität (durch Prüfsummen) und
• Authentizität (durch Identitätsprüfung des Servers via Zertifikat).

Für letzteres, die Authentizität ist ein Zertifikat erforderlich.


Was ist eigentlich ein Zertifikat:

Bei symmetrischen Verschlüsselungen wird der gleiche Schlüssel für das Ver- und Entschlüsseln benutzt. Diese Verfahren (z.B. AES) sind zwar sehr effizient, aber der Austausch des Schlüssel zwischen beiden Seiten ist der kritische Punkt, denn dies könnte abgefangen werden. Um dieses Problem zu umgehen, wurden asymmetrische Verfahren erfunden, die auf zwei Schlüsseln basieren. Dem privaten und dem öffentlichen Schlüssel. Beide Schlüssel bilden ein Keypair, die in einem mathematischem Zusammenhang stehen. Was mit dem einen Schlüssel verschlüsselt wurde, lässt sich nur mit dem dazugehörigen anderen Schlüsseln entschlüsseln – und umgekehrt.

Ein Zertifikat ist nichts anderes als ein Datenformat, dass einen öffentlichen Schlüssel (eines Keypairs) enthält, dazu einige Angaben zum „Besitzer“, Gültigkeit usw. sowie eine Signatur. Diese Signatur ist lediglich eine komplexe Prüfsumme des Zertifikates, die mit dem privaten Schlüssel eines anderen Keypairs verschlüsselt wurde.


Für was wird das Zertifikat genutzt:

Beim Verbindungsaufbau über TLS (https bzw. http/2) ruft der Client das Zertifikat des Servers ab und prüft den Inhalt, insbesondere die Angaben zur Gültigkeit und es prüft die Signatur und wer diese Signatur ausgestellt hat.

Für die Funktionalität – der gesicherte Zugriff auf den Timberwolf Server - kommt es auf zwei Dinge an:

• Das Zertifikat muss die URL enthalten, mit welcher der Server (hier der Timberwolf Server) aufgerufen wird
• Das Zertifikat muss von einer Stelle signiert sein, der man vertraut.

Der Client verfügt damit über den öffentlichen Schlüssel des Servers (weil das im Zertifikat enthalten ist). Der Server selbst verfügt über den passenden privaten Schlüssel. Damit kann nun der Client die Authentizität des Servers prüfen und danach den für die Verschlüsselung eigentlich notwendigen symmetrischen Schlüssel austauschen (stark vereinfachte Darstellung).


Individuelle Zertifikate ab Werk:

Damit wir Ihnen eine verschlüsselte Verbindung zum Timberwolf Server ermöglichen können, werden alle Server mit einem individuellen Zertifikat ausgestattet. Dieses wird bei der Installation vom Timberwolf Server erzeugt und von unserer werkseigenen Certificate Authority („Timberwolf Web CA“) signiert.

Wir benutzen diese Parameter:

• Schlüssellänge des öffentlichen Schlüssels: 4096 Bit
• Public-Private-Key Algorithmus: RSA
• Signatur-Algorithmus: SHA-256
• Gültigkeit: Bis 28. Oktober 2037

Festgelegte URL im Zertifikat:

Die Browser akzeptieren nur Zertifikate mit URL. Wir sind daher gezwungen, diese URLs bei der Erzeugung des Zertifikates anzugeben.

Jeder Timberwolf Server erhält ein Zertifikat mit den folgenden beiden URLs:

• timber.wolf
• timberwolfxxx.local (wobei xxx der Seriennummer des Servers entspricht)

Browser bauen nur dann eine gesicherte Verbindung auf, wenn die URL im Browser mit einer dieser drei im Zertifikat gespeicherten URLs übereinstimmt (und das Root-Zertifikat unserer CA einmalig importiert wurde)!


Vertrauensstellung für Zertifikate:

Zertifikate werden signiert. Für hunderte von offiziellen Zertifikatausgabestellen sind die Root-Zertifikate zur Überprüfung der Signatur bereits im Betriebssystem / Browser integriert. Die CA von ElabNET gehört nicht zu solchen offiziellen Stellen, daher muss der Kunde diese Vertrauensstellung selbst herstellen. Wie im Installationsleitfaden (vormaliges Mail) bereits beschrieben, müssen Sie dazu das Zertifikat von update.timberwolf.io herunterladen und im Browser / Betriebssystem ablegen und – abhängig vom System – entsprechend aktivieren.

Unser Root-Zertifikat laden Sie von hier: https://update.timberwolf.io

Hinweis: In iOS ab 10.3 muss diese Vertrauensstellung nach dem Installieren des Root-Zertifikates zusätzlich eingestellt werden.

Wenn Sie das Vertrauen für dieses Zertifikat aktivieren möchten, wählen Sie "Einstellungen" > "Allgemein" > "Info" > "Zertifikatsvertrauenseinstellungen". Aktivieren Sie unter "Volles Vertrauen für Root-Zertifikate aktivieren" das Vertrauen für das Zertifikat.

Aus Apple Support: https://support.apple.com/de-de/HT204477


Nutzung der gesicherten Verbindung auch quer über das Internet:

Für eine Nutzung über das Internet, ist ein Zertifikat mit der richtigen URL, passend zu Ihrem Internetanschluss, erforderlich. Wir werden Ihnen hier noch die technische Möglichkeit geben, eigene Schlüsselpaare zu erzeugen und auf Basis des öffentlichen Schlüssels ein Zertifikat erstellen zu lassen (self signed oder von einer öffentlichen Zertifizierungsstelle. Wir arbeiten hierzu mit Swisssign zusammen.


Zusammenfassung zum Thema „gesicherte Verbindung über Browser“:

Eines der Entwicklungsziele des Timberwolf Servers war die Konfiguration ausschließlich über verschlüsselte Verbindungen. Daher baut der Timberwolf Server Verbindungen über TLS 1.2 via https bzw. dem effizienteren http/2 auf.

Gesicherte Verbindungen benötigen ein Zertifikat, das von einer vertrauenswürdigen Stelle unterzeichnet ist und die URLs des Servers enthält.

Die Vertrauensstellung zu unserer ausstellenden Zertifizierungsstelle „Timberwolf Web CA“ konfigurieren Sie, indem Sie unser Root-Zertifikat von update.timberwolf.io herunterladen und importieren und – je nach System – die Vertrauensstellung bestätigen. Das gilt dann „lebenslang“ für dieses System und für alle Timberwolf Server. Integratoren: Das müssen Sie also nur einmal auf Ihrem Service-Notebook machen, bei allen Timberwolf Server gilt dies dann.

Damit der Verbindungsaufbau mit TLS erfolgen kann, ist es notwendig als URL im Browser „timber.wolf“ (wenn Sie das Inbetriebnahme WLAN benutzen) oder „timberwolfxxx.local“ (xxx ist die Seriennummer) zu benutzen.


3. PIN für den mitgelieferten Token:

Die Authentikatoren werden vermutlich erst ab Beta 8 funktionieren.

3) Wie setzt man den Timberwolf in der ETS auf?

Hier wieder ein Ausschnitt aus dem Newsletter:


Nächster Schritt: Programmierung der KNX Objekte mit der ETS

Für alle diejenigen, die bisher den WireGate Server kennen: Nun ist alles anders.

Historisches aus der Entwicklung WireGate Server:

Der WireGate Server basierte hinsichtlich der KNX-Kommunikation auf dem eibd („EIB Daemon“). Als Daemon bezeichnet man unter Linux / Unix ein Programm, das Services / Dienste zur Verfügung stellt und dabei vollständig im Hintergrund abläuft. Solche Daemon werden i.d.R. mit dem System gestartet und beendet und sind aus der Sicht anderer Komponenten „immer“ verfügbar.

Dieser eibd ist eine Entwicklung von Martin Koegler an der TU Wien bis 2011. Diese für den WireGate Server essentielle Softwarekomponente wurde von Michael Markstaller (damaliger Entwickler des WireGate Server und Geschäftsführender Gesellschafter bei ElabNET bis vor ein paar Jahren) für den Dauereinsatz tauglich gemacht. Mittlerweile gibt es unter der Bezeichnung knxd einen Fork.

Der eibd ist kein kompletter KNX Stack im Sinne der Zertifizierungsvorschriften der KNX Association, insbesondere fehlt es an der Unterstützung für die Programmierung durch die ETS. Deshalb konnte man den WireGate Server nicht aus der ETS programmieren, sondern es wurde im Programm direkt mit Gruppenadressen gearbeitet, anstatt mit deren Abstraktion in Objekten.

Diese Herangehensweise war die einzige, die preislich günstig verfügbar war, mit dem Nachteil, dass die Integration in den KNX nicht dem Objektmodell entsprach und Dummy-Applikationen angelegt werden mussten von denjenigen, die ein ordentliches und sauberes KNX Projekt haben wollten. (Ordentlich und sauber in der Hinsicht, dass in der Dummy-Applikation Objekte angelegt wurden, für jede GA die vom WireGate Server genutzt wurde.


Timberwolf Server mit offiziellem KNX Stack:

Für den Timberwolf Server wollten wir einen ordentlichen zertifizierten KNX Stack, der eine Programmierung durch die ETS ermöglicht. Zudem ist hierdurch auch eine zertifizierte Kompatibilität gegeben.

Dieser KNX Stack wurde in den letzten Jahren komplett neu entwickelt. Es ist einer der modernsten und leistungsfähigsten 32 / 64 Bit Linux KNX Stacks weltweit.


Leistungsmerkmale des Timberwolf KNX Stack:

In Beta 3 unterstützt der KNX Stack derzeit

• WireGate KNX Busankoppler USB TP-UART 2+
• 1.000 Objekte
• 64.000 Assoziationen
• KNXnet/IP Tunneling mit einer (1) Tunneling Connection (pro Instanz und pro KNX Busankoppler)
• mehrere parallele Instanzen des KNX Stacks, dabei einer im Datenmode
• die Applikation ist noch nicht zertifiziert

Geplant bis zum Final Release der Version 1.0

• Unterstützung für TP mit KNX Busankoppler und KNX Schnittstelle
• Unterstützung für KNXnet/IP (also Datenmode via Ethernet)
• 8.000 Objekte pro Instanz
• 64.000 Assoziationen pro Instanz
• KNXnet/IP Tunneling mit einer (1) Tunneling Connection (pro Instanz und pro KNX Busankoppler)
• KNXnet/IP Tunneling mit bis zu fünfundzwanzig (25) Tunneling Connections (pro Instanz und pro KNX Schnittstelle)
• mehrere parallele Instanzen des KNX Stacks, dabei einer im Datenmode
• Logging auf allen Instanzen
• parallele Unterstützung für den eibd für Legacy-Anwendungen in Docker Container
• Konfigurationsoberfläche
• Stack und Applikation sind vollständig zertifiziert

Geplant bis zum Final Release der Version 2.0

• Wie bei Version 1.0, jedoch bis zu drei Instanzen gleichzeitig im Datenmodus (je nach Lizenz)

Zusätzliche Erweiterungen werden zu einem späteren Zeitpunkt kommuniziert.


Anlegen von KXN Projekten im Timberwolf Server (mit Projektfile):

Da die Applikation für den KNX Stack sich noch in Bearbeitung befindet, ist diese noch nicht abschließend zertifiziert. Daher können wir Ihnen noch keine Applikation zur Verfügung stellen, sondern zunächst nur ein Projektfile. Bitte gehen Sie wie folgt vor:

• Laden Sie das Projektfile hier herunter: [Link entfernt, bekommen nur Beta-Tester]
• Bitte speichern Sie diese Datei und entfernen in der Dateibezeichnung das '.bin' am Ende
• Importieren Sie es in die ETS (5.6.x)
• Kopieren Sie unter Geräte den Timberwolf Server 2400
• Öffnen Sie Ihr Projekt und fügen Sie das Gerät mit „Einfügen“ ein.

Programmieren der phy. Adresse des Timberwolf Servers:

Auf der Admin Oberfläche gehen Sie bitte zu Einstellungen / KNX / Schnittstellen
Auch wenn diese Seite noch nicht fertig programmiert ist, können Sie den Programmierknopf in der Spalte „Medium“ benutzen.


Programmieren der KNX Objekte im Timberwolf Server:

Wenn Sie das Gerät in Ihr Projekt importiert haben, können Sie KNX Objekte in der ETS anlegen
Bei der Wahl des Datenpunkttyps sind Sie frei, dieser muss allerdings später zur Nutzung passen

Hinweis zu den Datenpunkttypen: Unter Einstellungen / 1-Wire / Einstellungen finden Sie eine Auflistung der Defaults für Datenpunktypen üblicher Sensorwerte. Bitte orientieren Sie sich daran.


Wenn Sie Einstellungen und Werte von Sensoren aus einem WireGate Server übernehmen wollen:

Für die Übernahme der Einstellungen aller 1-Wire Sensoren, bisher aufgezeichneten Werte usw. erhalten Sie (voraussichtlich mit Beta 4 oder 5) ein Importtool, das die Daten aus dem Exporttool des WireGate Servers verarbeiten kann.

Eines wird dieses Importtool nicht können, die KNX Objekte anlegen. Das müssen Sie leider manuell in der ETS tun.

(Hinweis: Hier arbeiten wir derzeit an einer App in der ETS, die das erledigen wird, das vereinfacht erheblich die Migration. Geplant für Beta 8 oder 9).


Sie können das ab sofort schon vorbereiten:

• Prüfen Sie, dass Sie am WireGate Server die Version 1.4 installiert haben, ansonsten bitte Update auf 1.4 (mittlerweile 1.4.2)
• Bereiten Sie einen professionellen USB Stick vor (ab 2 GB freie Kapazität, Dateiformat FAT32, Verzeichnis „WireGateExport“ darf dort nicht existieren, keine Billigware von Werbegeschenken usw.)
• Bitte starten Sie am WireGate Server das „Export Tool“ (unter Globale Einstellungen, ganz unten)
• Sie erhalten nun eine Liste aller GAs, die vom WireGate Server benutzt werden, diese können Sie auch als CSV herunterladen
• Legen Sie nun mit der ETS (nach Import des Gerätemodelles) Objekte an mit den entsprechenden Datenpunkttypen und verknüpfen diese mit den GAs

Mittlerweile: Im Timberwolf Server gehen Sie auf Einstellungen / 1-Wire / Import und lesen dort die ANleitung und nehmen den Import vor. Sensoren erst DANACH einstecken.


lg

Stefan

[Dante]

Jeder Timberwolf Server erhält ein Zertifikat mit den folgenden beiden URLs:

• timber.wolf
• timberwolfxxx.local (wobei xxx der Seriennummer des Servers entspricht)

Browser bauen nur dann eine gesicherte Verbindung auf, wenn die URL im Browser mit einer dieser drei im Zertifikat gespeicherten

1. Ein kleiner Rechtschreibfehler (drei statt zwei), damit's in der Doku dann gleich richtig steht ;-)
2. Gedanken zu den Hostnames / URLs:
   1. gegen timberwolfxxx.local spricht IMHO nichts
   2. die Nutzung von .wolf könnte später problematisch werden, falls sie sich jemand als gTLD sichert - ich vermute, ihr selbst werdet das aus Kostengründen eher nicht machen - siehe dazu auch die Probleme der Fritzboxen durch die Einführung der gTLD .box
   3. Ist es zulässig mehrere Hundert / Tausend Zertifikate auf den gleichen Hostname (timber.wolf) auszustellen? Klar, das sind keine öffentlich erreichbaren Adressen und es gibt keine Regeln einer übergeordneten Stelle oder "Marktmacht" wie sie die von Browsern supporteten CAs haben. Aber war das nicht auch mit ein Grund, wieso das beA (besondere elektronische Anwaltspostfach) gegen die Wand gefahren wurde!? Denn:
   4. Wird durch den gleichlautenden Hostname verschiedener Systeme ein MITM-Angriff erleichtert, ich muss mir auch nur einen TW holen und die Anfragen an timber.wolf auf diesen Umleiten: URL passt, Zertifikat gültig und für diesen Host ausgestellt, alles grün
      evtl. wäre hier HPKP (HTTP Public Key Pinning) ein Ansatzpunkt für Schutz (hier ist aber timber.wolf ungeeignet), aber das wird ja wohl auch schon wieder abgeschafft
   5. Lösung gegen 3. und 4. wäre evtl. eine einfache Umleitung von timber.wolf (nur HTTP) auf timberwolfxxx.local, dann müsste das allgemeine timber.wolf auch nicht in das Zertifikat
   6. Das waren nur kurz die Gedanken, die mir beim Lesen des Posts und der Hostnames gekommen sind.
      Das ist nicht dringend und ihr habt euch ja sicher auch ein paar Gedanken dazu gemacht.

[r3dbull]

Hallo zusammen,

habe heute auch meinen 2500er bekommen.
Leider war keine Schnellstartanleitung im Paket. Per Mail habe ich auch noch keine bekommen.
Sind wir noch im Beta Status? Die Infos bekomme ich dann per Mail ?

Gruß
Chris

[FabKNX]

Schau Mal auf YouTube. :-)

[StefanW]

Leider war keine Schnellstartanleitung im Paket. Per Mail habe ich auch noch keine bekommen.

eMails an alle Besteller des Timberwolf Servers 2500 sind nun abgeschickt.

Es gibt dort Links zu zwei Videos, eines kannst Du auch so auf Youtube finden und das andere ist nicht öffentlich, der Link steht dann im eMail

lg

Stefan

[irgendwer]

Das mit dem trust auf eure CA meint ihr ernst? Stand nicht irgendwo das ihr Zertifikate der Swiss CA nutzt? Ich war aud dem Stand das hier "richtige" Zertifikate einer vertrauenswürdigen CA im Einsatz sind.

Bitte nicht falsch verstehen - ich möchte nicht sagen das ich euch nicht vertraue. Ich habe nur Bauchschmerzen sowas aus dritten Quellen anzunehmen. Dann wird auch die Funktion des Reverse Proxy geschmälert.

[StefanW]

Das mit dem trust auf eure CA meint ihr ernst? Stand nicht irgendwo das ihr Zertifikate der Swiss CA nutzt? Ich war aud dem Stand das hier "richtige" Zertifikate einer vertrauenswürdigen CA im Einsatz sind.

Bitte - bevor Du jemand angehst - nochmal kurz nachdenken. Womöglich zu erst informieren...

Stichworte: privates Netz, private Adressen, Server aus dem Internet nicht erreichbar, Regeln der Zertifikatsausgeber zur Validierung des Besitzers einer Domain.

Oder kurz: Für Appliances in privaten Netzen die nicht aus dem Internet erreichbar sind, gehen keine offiziellen Zertifikate.
https://www.swisssign.com/de/news/an...verfahren.html


==> Die SwissSign-Zertifikate werden - auf Wunsch des Kunden ausgestellt - sofern der Kunde eine EIGENE Domäne hat und die Administration daran nachweisen kann. Das ist also optional und nicht out-of-the-Box - eben weil der Kunde dafür Domäne und Durchschaltung seiner Firewall benötigt.