CloudMatic baut keine Verbindung mehr auf mit aktuellen RM-Snapshots #2442
Comments
Ich denke du verwechselst hier etwas. In dem referenzierten Commit geht es um die
Wenn man die OpenSSL Fehlermeldung googled wird man sehr schnell fündig: https://superuser.com/questions/1737052/openssl-error0a00018essl-routinesca-md-too-weak Konkret sieht es so aus als ob hier wirklich das CA Zertifikat von CloudMatic bzw. Easy Smarthome nicht mehr ganz dem aktuellen stand der Technik entspricht. Denke hier müsste @DevEddy bzw. @m-scheffler oder @easysmarthome-eschaefer aktiv werden und das Zertifikat der CA erneuern bzw. auf aktuellen Stand bringen. Die entsprechenden Infos sind hier zu finden:
Bis das jedoch passiert sollte aber laut dem superuser Artikel es vielleicht auch möglich sein die Verbindung trotzdem mit dem folgenden Workaround aufzubauen. Probier mal in deiner Dann sollte er die Verbindung vielleicht trotz schwachem CA Zertifikat wieder aufbauen können. |
|
Tschuldige die Verwechselung... irgendwie kann ich heute nicht richtig gucken. Der Workaround funktioniert. Da das ja nun in der Tat ein CloudMatic-Problem ist...
|
Pass ihn an und lass ihn offen bis @DevEddy hier sich das mal angeschaut hat. Entweder (und das wäre das beste) passen die ihr CA Zertifikat an oder sie modifizieren die |
jens-maus
added
the
➡️ third-party issue
|
@Baxxy13, the issue you reported cannot be solved within this project or should be better directly solved in a third-party project RaspberryMatic just uses. So please consider creating an additional issue ticket in this third-party project. If still relevant we can keep this issue ticket open here for the time being so that you can use it as a reference in issue tickets for the third-party report. |
Baxxy13
changed the title
jens-maus
added
the
🧠 unstable-snapshot
|
@Baxxy13 Kannst du bitte mal die Ausgabe von folgenden Befehlen zeigen damit man auch hier sehen kann das das Und dann bitte auch noch die Ausgabe des Wenn da z.B. bei Und das erklärt auch die Fehlermeldung die jetzt kommt, denn seit OpenSSL 3.0 (welches beim aktuellen nightly snapshot ja dabei ist) ist SHA-1 explizit als deprecated vermerkt (siehe https://www.openssl.org/docs/man3.0/man3/SHA1.html). Hier sollte EasySmartHome/CloudMatic wirklich seitnah auf sha256 gehaste Zertifikate wechseln damit das alles wieder wasserdicht ist. |
|
Ich poste da jetzt mal nicht die gesamten Ausgaben weil ich nicht weiß wie sensibel die Daten sind. Na dann hoffen wir mal das da zügig für mehr Sicherheit gesorgt wird. Edit: |
|
Dann sollte mal jemand EasySmartHome sagen sie sollen ihren OpenSSL befehlen zum generieren der Zertifikate die Option "-sha256" hinzufügen damit ihr ältere OpenSSL Version die sie da anscheinend haben auch Zertifikate mit sha256 hashes generiert. Also sowas wie: |
|
Ich habe jetzt mal eine Mail zum Thema über das CloudMatic Support System gesendet. |
|
Danke für die Meldung. Wir prüfen das Problem auf unserer Seite und geben hier Feedback, sobald es was Neues gibt. |
Danke für die Rückmeldung @DevEddy. Bitte hier ggf. etwas schneller unterwegs sein, da spätestens sonst mit dem nächsten RaspberryMatic Release (aktuelle geplant für kommendes WE) es ggf. zu Problemen von Nutzer kommen wird. |
|
@DevEddy Schon irgendwelche Hinweise wann genau mit einer Änderung/Verbesserung diesbzgl. in CloudMatic zu rechnen ist? Ich möchte ungern hier den nächsten RaspberryMatic Release noch weiter hinauszögern... |
|
@jens-maus leider ist das nicht so einfach alle Zertifikate ohne Probleme und Unterbrechung für alle unsere Kunden auszurollen. Wir arbeiten daran, dass die Zertifikate in der Zukunft mit In der Zwischenzeit möchten wir den oben genannten Workaround für RaspberryMatic nutzen. Das Problem hier ist, dass wir die |
|
@DevEddy Das ihr nun stattdessen den Workaround (Anpassung der Bzgl. der Umsetzung dieses temporären Workarounds mittels Aktualsierung eures CloudMatic Addons habe ich folgende Hinweise:
|
jens-maus
added
the
👍 important
Läuft der "Auto-Update" Cronjob nicht alle 6h und überschreibt dabei die |
…tificate, otherwise remove the workaround. Copy client.conf to cloudmatic_openvpnc_client.conf to /var/etc and use it for openvpn to support downgrading. jens-maus/RaspberryMatic#2442
|
@jens-maus ich habe die Änderungen jetzt umgesetzt. Falls noch was sein sollte, gib kurz Bescheid. Wie schon oben erwähnt werden wir die Zertifikate aktualisieren und "schieben es selbstverständlich nicht auf die lange Bahn". @Baxxy13 nein, die |
|
Na ich bin ja mal gespannt. Grund: Das durch
Abhilfe würde der Cron-Job für Die Lösung wäre auch simpel. Schauen wir mal... |
|
Na dann gehen wir zurück auf Start und hoffen @DevEddy kann das Problem final beseitigen damit der nächste RaspberryMazic Release nicht wieder auf sich warten muss. |
Hab mir das jetzt mal selbst näher angeschaut und auch ich denke das der Workaround in Und die Versionsunterschiede bzgl. 4.0, 3.0 und 1.7 sehe ich hier bei meiner alten CloudMatic Testinstallation aus. Dort habe ich unter --- /opt/mh/user/loophammer.sh
+++ /usr/local/etc/config/addons/mh/loophammer.sh
@@ -2,7 +2,7 @@
#
# **************************************************************************************************************************************************
#
-# meine-homematic.de Hintergrund - Prozess Version 1.7, Stand 12.08.2010
+# meine-homematic.de Hintergrund - Prozess Version 3.0, Stand 05.04.2013
#
# Dies ist ein Benutzer - individualisiertes Skript
#
@@ -14,6 +14,10 @@
#
# Changelog:
# ===========
+#
+# Version 3.0
+# Anpassung an Datumsformat der CCU2
+#
# Version 1.7:
# Fehler in der Datumsauswertung behoben
#
@@ -23,15 +27,13 @@
#Dienst Status einlesen
dienst=`/bin/busybox cat $ADDONDIR/dienst`
- dienstngx=`/bin/busybox cat $ADDONDIR/dienstngx`
- dienstzbx=`/bin/busybox cat $ADDONDIR/dienstzbx`
#
# Teilbereich Hammering - Schutz
#
nowdate=$(date +%s)
# Enddatum wird individuell gesetzt, in Abhängigkeit der Schlüssel - Laufzeit
- enddate=$(date -d "010123592010" +%s)
+ enddate=$(date -d "2022-02-22 23:59" +%s)
if [ $enddate -ge $nowdate ]
then
#
@@ -44,37 +46,18 @@
ovstart=`/opt/mh/openvpn --daemon --config $ADDONDIR/client.conf --cd $ADDONDIR`
fi
fi
+ else
+ #
+ # Aktuelles Datum ist nach dem Enddatum. VPN beenden, um Hammering zu unterbinden
+ #
+ Processname=openvpn
+ if [ -n "`pidof $Processname`" ] ; then
+ /bin/busybox logger -t homematic -p user.info "Keine meine-homematic.de VPN Lizenz aktiv, openvpn wird beendet."
+ /bin/busybox logger -t homematic -p user.info "Diest dient zum Schutz Ihrer HomeMatic, um permanente, ungültige Verbindungsversuche alle 10 Sekunden zu unterbinden."
+ dummy=`/bin/busybox killall openvpn`
+ fi
+ fi
- if [ ! -e $ADDONDIR/zabbix.conf ] ; then
- Processname=zabbix_agentd
- if [ ! -n "`pidof $Processname`" ] ; then
- /bin/busybox logger -t homematic -p user.info "CloudMatic monitoring Dienst wird gestartet"
- ovstart=`/opt/mh/user/zabbix_agentd -c /etc/config/addons/mh/zabbix.conf >/dev/null 2>&1`
- fi
- fi
-
- Processname=nginx
- if [ ! -n "`pidof $Processname`" ] ; then
- /bin/busybox logger -t homematic -p user.info "Reverse Proxy Dienst wird gestartet"
- ovstart=`/opt/mh/user/nginx`
- fi
- else
- #
- # Aktuelles Datum ist nach dem Enddatum. VPN beenden, um Hammering zu unterbinden
- #
- Processname=openvpn
- if [ -n "`pidof $Processname`" ] ; then
- /bin/busybox logger -t homematic -p user.info "Keine meine-homematic.de VPN Lizenz aktiv, openvpn wird beendet."
- /bin/busybox logger -t homematic -p user.info "Diest dient zum Schutz Ihrer HomeMatic, um permanente, ungültige Verbindungsversuche alle 10 Sekunden zu unterbinden."
- dummy=`killall -9 openvpn`
- fi
- Processname=nginx
- if [ -n "`pidof $Processname`" ] ; then
- /bin/busybox logger -t homematic -p user.info "Reverse Proxy wurde herunter gefahren"
- dummy=`killall -9 nginx`
- fi
- fi
-
#Wenn Dienst läuft beenden, falls Dienst = 0
if [ $dienst -lt 1 ] ; then
@@ -82,13 +65,5 @@
if [ -n "`pidof $Processname`" ] ; then
/bin/busybox logger -t homematic -p user.info "VPN Dienst wurde ueber Systemsteuerung beendet"
dummy=`/bin/busybox killall openvpn`
- fi
- fi
-
- if [ $dienstngx -lt 1 ] ; then
- Processname=nginx
- if [ -n "`pidof $Processname`" ] ; then
- /bin/busybox logger -t homematic -p user.info "Reverse Proxy wurde herunter gefahren"
- dummy=`killall -9 nginx`
fi
fiUnd die Version die im GitHub liegt ist wohl auch Asbach-Uralt. Siehe: https://github.com/EasySmartHome/CloudMatic-CCUAddon/blob/master/user/loophammer.sh Insofern denke ich also auch das hier noch nachgearbeitet werden muss damit das ganze konsistent am Ende wird, da das einfach updaten der Und ehrlich gesagt hab ich noch nie wirklich kapiert warum die CloudMatic Dinge da teilweise zwischen |
Nachdem ich mir das ganze Durcheinander bzgl. CloudMatic Addon etwas mehr angeschaut habe, denke ich nicht das die Lösung so einfach wäre, denn die |
|
Ich hatte mich nicht getraut das ganze Konstrukt zu kritisieren. Das ist in der Tat ein ziemliches Durcheinander und ich habe für mich einen "Ablauf-Plan" erstellt um nachzuvollziehen wer / was /wie / wo passiert. Das ganze allgemein Aufzuräumen wäre natürlich auch nicht verkehrt. |
Wenn du diesen "Ablaufplan" hier mal teilen könntest wäre das IMHO sehr gut. Ist schon ziemlich verworren wie diese zich sh scripte miteinander interagieren und für mich sieht das so aus das es da auch zich skripte gibt die schon lange obsolete sind. Wenn du also mal dein Wissen teilen könntest wäre das super für das allgemeine Verständnis wie das CloudMatic Addon genau mit einer CCU interagiert, usw.
Das wäre definitiv mal ne Aufgabe für EasySmartHome. Zumindest mal alle obsoleten Teile des Addon rauszuwerfen wäre IMHO super. Auch sehe ich z.B. einige stellen wo immer noch via wget/curl Dinge (sogar die Keys) via unverschlüsseltem |
|
Der Workaround ist generell so wie dieser hier durchgeführt wurde in Ordnung und kann genutzt werden. @Baxxy13 das Problem ist, dass die vor dem Workaround generierten Schlüsseldateien der Nutzer den Workaround noch nicht haben - inklusive dir. Diese Schlüsseldatei wird nur mit der CloudMatic-Aktualisierung auf der Zentrale oder via direkter Installation ausgeliefert. Warum die Dateien so hinterlegt sind, hat interne und technische Gründe, da wir mehrere arten von Zentralen unterstützten. Wende dich bitte kurz an unseren Support oder teile mir deine CloudMatic ID damit ich deinen Schlüssel neu generieren kann. @jens-maus die |
|
Alles klar, ich werde dann später über den Support-Weg die Neugenerierung meines Key's beantragen. Das dürfte dann nach dem Release der nächsten RM für euren Support interessant werden wenn der Workflow so bleibt. |
@DevEddy |
|
In der Theorie ist es nicht ganz so kompliziert. Man müsste halt nur seinen Key updaten lassen, sollte das nicht eventuell doch automatisch durch CM gemacht werden. Tja, in der Praxis werden die Cron-Jobs nicht automatisch angelegt, es braucht einen CloudMatic Restart damit das passiert. |
|
Also das mit dem Support war ein Satz mit x. Mein Einwand, das der Workaround ohne aktualisiertes Schlüssel-Paket wirkungslos ist, blieb bisher unbeantwortet. Kein gutes Zeichen. Darum bitte ich @DevEddy hier direkt meinen persönlichen Schlüssel für CM-ID: xxx zu aktualisieren, damit ich final testen kann ob das dann alles wie geplant funktioniert. Edit: |
|
@Baxxy13 sorry für das Missverständnis - ich habe dir den Schlüssel neu generiert. Die Problematik mit den Cronjobs schauen wir uns auch an. Auf den ersten Blick sieht es so aus, als gab es Änderungen am System, was dazu führt, dass diese bei jedem Reboot neu angelegt werden müssten - ich denke, dass wir dazu ein init-Skript bräuchten - mehr Infos folgen dann in dem von dir erstellten Issue. @jens-maus so wie es im nightly ist, kann ausgerollt werden. Wir sind uns bewusst, dass dies einen erhöhtes Supportaufkommen für bestehende Konten bedeuten könnte. |
|
Danke @DevEddy , das mit dem aktualisierten Schlüssel hat nun geklappt.
Sorry für die harten Worte, aber ihr habt das nicht getestet! Zurück zum Workaround:Leider muss ich sagen das es mit dem Workaround direkt nach einem manuellen Update (mit meinem aktualisierten persönlichen Schlüssel) nicht funktioniert. Warum das nicht funktioniert ist auch schnell ergründet: Problem Nr.1: "Manuelles Update" führt Problem Nr. 2: Problem Nr. 3: Lösen lassen sich Problem 1 und 2 recht einfach, bei 3 bin ich auch überfragt. Wenn ihr eure Dateien auf Github mal aktualisieren würdet, könnte ich Diffs bereitstellen die 1 & 2 adressieren und den Workaround wenigstens lauffähig machen. |
|
@DevEddy EasySmartHome/CloudMatic-CCUAddon#14 Ich würde daher vorschlagen, @Baxxy13 sollte diese Umsetzung dieses PR einmal entsprechend auf Herz&Nieren testen der so IMHO wesentlich transparenter und nutzerfreundlicher sein sollte. Und dann merged du diesen PR, sodass ich die Umsetzung dann so in RaspberryMatic aufnehmen kann. Unabhängig davon aber nochmal die Warnung bzw. der Hinweis, das dies wirklich nur ein temporärer Workaround darstellen soll und ich diesen bei gelegenheit in zukünftigen Versionen (spätestens Anfang nächsten Jahres) zurückrollen werde. Ihr solltet euch also IMHO daran machen die Nutzerzertifikate schnellstmöglichst auf SHA256 (oder noch besser SHA384) umzustellen um wieder für bessere Sicherheit zu sorgen, denn meines Wissens hat eQ3 auch bereits ein Auge auf dieses Ticket hier geworfen und auch av-test.org wird sicherlich nicht amused darüber sein, das Ihnen in der letzten Testung der CloudMatic der Umstand der weiterhin breiten SHA1 Zertifikationsnutzung durch die Lappen gegangen ist (siehe https://www.iot-tests.org/de/2023/08/zum-2-mal-rezertifiziert-easy-smarthome-cloudmatic-smartha-app/) |
|
So, die Tests sind abgeschlossen. Hab's jetzt mit 2 Systemen getestet. (Nightly 3.71.12.20231010-969f2c) System A hat noch das alte Schlüsselpaket ohne den versemmelten Workaround, also mit "alter" System B hat das aktuelle Schlüsselpaket mit dem versemmelten Workaround, also mit "neuer" Zusammengefasst: Der PR funktioniert mit "neuen" und "alten" Schlüsselpaketen gleichermaßen problemlos.
Edit an @jens-maus |
|
Ok, danke für das Feedback. Hab inzwischen (wie du vllt. schon gesehen hast) schon den Commit mit dem PR als die neue CloudMatic Addon version für RaspberryMatic integriert. D.h. mit dem nächsten nightly snapshot wird mein wrapper script unter |
|
Nachdem mein PR nun im GitHub des Addons gemerged wurde mach ich nun auch mal wieder zu und würde bitten den nächsten nightly build nochmal auf Herz+Nieren bzgl. CloudMatic zu testen da ich vorhabe nun für kommendes Wochenende eine neue stable Version herauszubringen. |
|
Ich kann nicht versprechen das ich morgen noch zum testen des Nightly's komme, es sei denn er ist morgens nach dem Käffchen verfügbar. 😉 Da aber die Änderungen zum heutigen Nightly nicht so groß ausfallen bin ich guter Dinge das das läuft. |
Describe the issue you are experiencing
CloudMatic funktioniert aktuell nicht mit den letzten Nightly-Snapshots von RaspberryMatic.
So wie es aussieht ist das aktuelle CA-Zertifikat nicht mehr valide und die VPN-Verbindung wird darum nicht mehr aufgebaut.
Ich bekomme keinen Zugriff via CloudMatic-Connect auf die Zentrale und beim gestrigen Zentralen (Neu)Start sowie heutigem Cloudmatic-Update gab es ein paar ungewöhnliche Meldungen im Log.
Describe the behavior you expected
CloudMatic sollte auch im Nightly, bzw. in der folgenden Release-Version funktionieren.
Steps to reproduce the issue
...
What is the version this bug report is based on?
3.71.12.20230918 - Nightly
Which base platform are you running?
ova (Open Virtual Infrastructure)
Which HomeMatic/homematicIP radio module are you using?
RPI-RF-MOD
Anything in the logs that might be useful for us?
Additional information
Muss hier CloudMatic neue cert's verteilen?
Leider habe ich den vorigen Nightly [3.71.12.20230914-dd0caca] schon "entsorgt" so das ich nicht mit Sicherheit sagen kann das es an der Aktualisierung der openvpntools liegt.
The text was updated successfully, but these errors were encountered: