livetracking mit owntracks

[Sailor]

Hallo Otto

Sorry ich war ein wenig auf dem Holzweg.
Ich habe mal mit dem Tool getestet: http://mqtt-explorer.com/
in FHEM habe ich einfach einen Server definiert

Code: [Auswählen]

defmod mqtt2ssl MQTT2_SERVER 8883 global
attr mqtt2ssl SSL 1Der nimmt die key und cert aus dem Pfad certs.
1. Versuch
mit mqtt explorer die Verbindung getestet - Verbindung funktioniert erst wenn validate certificate ausgeschaltet (war zu erwarten)

Was ist bei dir der MQTT - Explorer? Habe ich was vergessen einzurichten?
Wo hast du das "validate certificate" ausgeschaltet?

2. Versuch
Die Datei certs/server-cert.pem habe ich mir ins Windows geholt

Code: [Auswählen]

scp pi@192.168.56.187:/opt/fhem/certs/server-cert.pem .Dann im mqtt explorer unter advanced / certificates / server certificate  eingelesen. (Die Stelle sieht exakt so aus wie bei owntracks)
Im Hauptfenster validate certificate angelassen.
Verbindung funktioniert.

Das lässt doch hoffen!

Die nächste Möglichkeit wäre noch Clientcertificate - aber das wolltest Du ja erstmal gar nicht.

Hab ich das gesagt?   
Also ich nehme jede Loesung! Haupsache die Verbindung ist abgesichert und kann nicht belauscht werden.

[Nachtrag]
Frage nach dem MQTT-Explorer hat sich erledigt. Scheint eine gute Software zum finden von Fehlern und Daten zu sein.

Ich frage mich langsam, ob es nicht besser ist, auf dem gleichen Server wo fhem läuft, noch einen MOSQUITTO - Server laufen zu lassen.
Wollte ich eigentlich vermeiden wenn es sich über fhem realisieren lässt, aber zumindest eine Alternative.
So wie ich das gelesen habe, kann man dann zwischen fhem und dem MOSQUITTO - Server eine Bruecke schlagen.

Gruß
    Sailor

[OdfFhem]

So wie ich das gelesen habe, kann man dann zwischen fhem und dem MOSQUITTO - Server eine Bruecke schlagen.

In dem Fall käme MQTT2_CLIENT zum Einsatz ...

[Otto123]

Moin,

das mit dem mosquitto würde ich nicht machen. Aus meiner Sicht bringt das keinen Sicherheitsgewinn. Ein mqtt Server separat von deinem Netz im Internet, das wäre sinnvoll.
Wenn sich Server und Client über ssl unterhalten ist es erstmal sicher. Client Zertifikat wäre eine zusätzliche Autorisierung.
Zu dem Thema gibt es diesen alten Beitrag https://forum.fhem.de/index.php?topic=27171.0
Der dort erwähnte Reverse-Proxy wäre auf alle Fälle empfehlenswert und ein echter Sicherheitsgewinn!

Gruß Otto

[Sailor]

Hallo Otto

Danke Dir und auch Rudi , Jamo und Odf für das "am Ball bleiben"!

das mit dem mosquitto würde ich nicht machen. Aus meiner Sicht bringt das keinen Sicherheitsgewinn.

Bedeutet dies, dass der lokale MOSQUITTO auch keine SSL Verbindung mit owntracks herstellen kann?

Ein mqtt Server separat von deinem Netz im Internet, das wäre sinnvoll.

Du schlägst also einen Cloud-Dienst wie beispielsweise diesen hier vor?
https://www.hivemq.com/mqtt-cloud-broker/

Eigentlich möchte ich auf Cloud-Dienste verzichten.
Meiner Erfahrung nach ist nach einer Weile Schluss mit kostenlosem Service und dann stehe ich wieder am Anfang.
Davon hatte ich in der Vergangenheit nun wirklich genug.
Einzige Alternative: Ein eigener Prozess bei meinem Webhoster IONOS. Wenn es das denn gaebe...

Wenn sich Server und Client über ssl unterhalten ist es erstmal sicher. Client Zertifikat wäre eine zusätzliche Autorisierung.

Genau das hatte ich ja gehofft mit dem MQTT - Server herstellen zu koennen.
Meine nächste Hoffnung war, dies mit mit dem MOSQUITTO - Server auf dem gleichen Raspi herstellen zu können.
Meinen Recherchen zur Folge gibt es hierzu (owntracks <-> MOSQUITTO)  ja bereits Erfolge.

Zu dem Thema gibt es diesen alten Beitrag https://forum.fhem.de/index.php?topic=27171.0
Der dort erwähnte Reverse-Proxy wäre auf alle Fälle empfehlenswert und ein echter Sicherheitsgewinn!

Auhauerha. Jetzt komme ich von den Hunderten in die Tausende... 

Mein Ziel ist Authorisierung (Klappt schon mit MQTT_SERVER in Kombination mit allowed.)
sowie Abhörsicherheit via SSL/TLS.

Sicherlich könnte ein Reverse-Proxy den Stand der Sicherheit noch erhöhen - Allerdings habe ich noch nicht verstanden in welchen Punkten.

Wie aufwendig ist es überhaupt noch einen Reverse-Proxy auf dem gleichen Raspi zu installieren?
Und ergibt dies überhaupt Sinn - Sollten diese nicht von der Hardware getrennt sein um Sinn zu ergeben?
Ich möchte nämlich vermeiden, eine ganze Server-Farm an Raspis in der Wohnung herumliegen zu haben. 

Schritt für Schritt.

Gruß
    Sailor

PS: Sobald wir das hier zum Laufen bekommen haben, schreibe ich einen Wiki - Eintrag. Das kann ja nicht nur mir so ergehen!

[Otto123]

Hallo Sailor,

irgendwie redest Du jetzt um den heißen Brei

Also jetzt mein dritter Versuch:
Mein Tablet geschnappt owntracks drauf installiert.
MQTT eingerichtet:
Hostname 192.168.56.187  (der wo ich gestern den MQTT2 Server mit SSL definiert habe
Port 8883
Client ID gid
Identifikation 
Geräte ID gid
Tracker ID ti
Sicherheit TLS aktiviert
CA Zertifikat server-cert.pem importiert

Fertig und schwups hatte ich ein owntracks MQTT2 Device

Also was gestern mit dem MQTT Explorer funktioniert hat und ich vermutet habe "sieht genauso aus" - funktioniert auch mit owntracks.

Eigentlich ganz easy

Gruß Otto

[Sailor]

Blutige Hölle ich hab es endlich hinbekommen!

Es war in der Tat ganz einfach, wenn man es denn konsequent richtig macht!

Die Lösung lag in der Kombination von:
[1]https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle
insbesondere in dem Absatz in:
[2]https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle#Bekannte_Probleme
sowie unter Zuhilfenahme von:
[3]https://forum.fhem.de/index.php/topic,97177.msg909085.html#msg909085
als auch
[4]https://mkyong.com/linux/ssl-convert-pem-and-private-key-to-pkcs12/

Mit kurzen Worten
Die Zertifikate müssen unbedingt mit "Subject Alternative Names (SAN)" versehen werden die dem Internet-Namen entsprechen, ansonsten fliegt einem das mit den bekannten Fehlermeldung um die Ohren.
Ich habe also die unter [1] beschriebene Datei "oats.extensions.cnf" wie folgt codiert:

Code: [Auswählen]

basicConstraints=CA:FALSE
subjectAltName=@my_subject_alt_names
subjectKeyIdentifier = hash

[ my_subject_alt_names ]
DNS.1 = localhost
DNS.2 = localhost.local
DNS.3 = localhost.fritz.box

DNS.4 = HomeServer
DNS.5 = HomeServer.local
DNS.6 = HomeServer.fritz.box

# Address of your dynamic DNS subdomain
DNS.7 = homeserver.domain.de

# IPv4 local host
IP.1  = 127.0.0.1

# your local IPv4 address of your fhem Server
IP.2  = 192.168.178.200

# local network IPv6 address of your fhem Server
IP.3  = fe80::dea1:dea2:dea3:dead

# local IPv6 address of your fhem Server without network prefix
IP.4  = ::dea1:dea2:dea3:dead

Damit habe ich anschließend die servercert.pem und serverkey.pem erstellt bzw. in  server-cert.pem und server-key.pem umbenannt, damit das auch mit dem sslCertPrefix funktioniert.

Abschließend habe ich aus server-cert.pem und server-key.pem mittels der Anleitung unter [4] das entsprechende server-cert.p12 erstellt.
Achtung! Hierbei unbedingt ein Passwort vergeben, da owntracks keine .p12 - Zertifikate ohne Passwort aktzeptiert - und zwar ohne eine Fehlermeldung zu erstellen. 

Die unter [1] erstellte Datei cacert.pem und die server-cert.p12 habe ich anschließend in owntracks eingebunden und et - voila - Es funzt!

Boah ey - Wat fuern aufriss!

Gruß
    Sailor

[Sailor]

Ein herzerfrischendes "Moin" vom achtern Diek vorweg.

Wie versprochen, die erweiterten Wiki Einträge:

https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Owntracks_GPS_Tracking_in_FHEM_direkt_an_den_eigenen_Fhem-Server

Dieser Wiki - Eintrag verweist auf den ebenfalls erweiterten Wiki - Eintrag
https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle#Schl.C3.BCsselcontainer_erstellen

Mögt Ihr bitte kurz drauf schauen und prüfen, ob ich mir irgendwelche dummen Schnitzer geleistet habe?

Die fhem-Gemeinde wird es Euch danken. 

Gruß
    Sailor