MQTT2_Client mit SSL u. Zertifikat

Begonnen von KölnSolar, 14 September 2019, 21:31:08

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Kannst du das Connect-String von MQTT.fx protokollieren?

KölnSolar

#16
müsste ich mit Wireshark hinbekommen.

Wo ich jetzt den Server ohne SSL laufen hab, meldet sich das device nicht mehr. Den Server will ich ja auch durch FHEM ablösen. Kannst Du in MQTT2_SERVER auch die sslargs einbauen ?  :-* :) :-*

Edit:
Jetzt bin ich etwas überrascht. Obwohl der Server OHNE SSL gestartet ist und ich auch KEINE SSL-Optionen im MQTT.fx-Profil angegeben habe, wird von MQTT.fx per SSL zugegriffen. Wg. Server-Port 8883 ???? ???
Ich denke, Dich interessiert nach dem TCP-ACK die MQTT-connection-messsage
0000   b8 27 eb e2 9a 1d dc 85 de 61 63 9f 08 00 45 00   .'.......ac...E.
0010   00 74 38 30 40 00 80 06 dc af c0 a8 b2 23 c0 a8   .t80@........#..
0020   b2 2f e1 ed 22 b3 73 1d ab 59 10 5f 7b 74 50 18   ./..".s..Y._{tP.
0030   02 01 81 66 00 00 10 4a 00 04 4d 51 54 54 04 c0   ...f...J..MQTT..
0040   00 3c 00 1c 66 68 65 6d 75 73 65 72 33 40 62 75   .<..fhemuser3@bu
0050   6d 70 65 72 2f 47 4c 42 31 39 33 39 36 65 38 36   mper/GLB19396e86
0060   00 18 77 65 62 6d 61 73 74 65 40 61 73 73 65 74   ..webmaste@asset
0070   63 6f 6e 73 75 6c 74 2e 64 65 00 06 31 32 33 34   consult.de..1234
0080   35 36                                            56

Danach sendet MQTT.fx  beharrlich mit TLS1.2, so dass wir mit den subscribe-messages nichts anfangen können.

Ich probier mal einen Nicht-Standard-Port.....

Edit2:
Auch nicht erhellend(für mich) zwar erfolgt nun tatsächlich keine SSL-Verbindung mehr, löst aber nicht das disconnect-Problem. Das einzig überraschende ist, dass der Server irgendwelche requests unverschlüsselt per TCP an Port 8883 stellt, obwohl doch der Server auf 8885 läuft.  :o ::)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

ZitatKannst Du in MQTT2_SERVER auch die sslargs einbauen ?
Warum? MQTT2_SERVER unterstuetzt doch SSL.
Wg. CONNECT: versuch mal mqttVersion auf 3.1.1 zu setzen.

KölnSolar

#18
Du mein Held.  ;D 3.1.1 liefert
2019.09.18 15:20:24 5: mybot: sending DISCONNECT (224)(0)
2019.09.18 15:20:24 5: SW: e000
2019.09.18 15:20:24 3: Opening mybot device 192.168.178.47:8885
2019.09.18 15:20:24 5: HttpUtils url=http://192.168.178.47:8885/
2019.09.18 15:20:24 4: IP: 192.168.178.47 -> 192.168.178.47
2019.09.18 15:20:24 5: mybot: sending CONNECT (16)K(0)(4)MQTT(4)(194)(0)(30)(0)(28)fhemuser2@bumper/GLB19396e86(0)(25)webmaster@assetconsult.de(0)(6)123456
2019.09.18 15:20:24 5: SW: 104b00044d51545404c2001e001c6668656d75736572324062756d7065722f474c42313933393665383600197765626d6173746572406173736574636f6e73756c742e64650006313233343536
2019.09.18 15:20:24 3: mybot device opened
2019.09.18 15:20:25 5: mybot: received CONNACK (0)(0)
2019.09.18 15:20:25 5: mybot: sending SUBSCRIBE (130)(6)(0)(23)(0)(1)#(0)
2019.09.18 15:20:25 5: mybot: received SUBACK (0)(23)(0)
2019.09.18 15:20:25 5: mybot: received PUBLISH (0)(19)$SYS/broker/versionHBMQTT version 0.9.5
2019.09.18 15:20:25 5: mybot: dispatch autocreate=simple\000fhemuser2_bumper_GLB19396e86\000$SYS/broker/version\000HBMQTT version 0.9.5

Ohne SSL funktioniert es schon mal. Dann guckn wir mal weiter....

ZitatWarum? MQTT2_SERVER unterstuetzt doch SSL.
Ja, aber doch "nur" wie zuvor MQTT2_CLIENT ohne sslargs-Argumente(hier: Zertifikate).

Aber nun, wo das grundlegendste Problem gelöst ist, teste ich mal weiter. Vielleicht kriege ich das ja auch über Zertifikatespeicher hin.

Ich berichte.....

Edit: Erste Nachricht vom bot empfangen  ;D sslargs hab ich gar nicht genutzt. Dem "Zertifikatespeicher" hatte ich bereits vor Tagen versucht das Zertifikat beizubringen.
2019.09.18 15:42:04 5: mybot: sending PINGREQ (192)(0)
2019.09.18 15:42:04 5: mybot: received PINGRESP
2019.09.18 15:42:34 5: mybot: sending PINGREQ (192)(0)
2019.09.18 15:42:34 5: mybot: received PINGRESP
2019.09.18 15:43:04 5: mybot: sending PINGREQ (192)(0)
2019.09.18 15:43:09 1: 192.168.178.47:8883 disconnected, waiting to reappear (mybot)
2019.09.18 15:43:10 5: HttpUtils url=https://192.168.178.47:8883/
2019.09.18 15:43:10 4: IP: 192.168.178.47 -> 192.168.178.47
2019.09.18 15:43:10 5: mybot: sending CONNECT (16)K(0)(4)MQTT(4)(194)(0)(30)(0)(28)fhemuser2@bumper/GLB19396e86(0)(25)webmaster@assetconsult.de(0)(6)123456
2019.09.18 15:43:10 5: SW: 104b00044d51545404c2001e001c6668656d75736572324062756d7065722f474c42313933393665383600197765626d6173746572406173736574636f6e73756c742e64650006313233343536
2019.09.18 15:43:10 1: 192.168.178.47:8883 reappeared (mybot)
2019.09.18 15:43:10 5: mybot: received CONNACK (0)(0)
2019.09.18 15:43:10 5: mybot: sending SUBSCRIBE (130)(6)(0).(0)(1)#(0)
2019.09.18 15:43:11 5: mybot: received SUBACK (0).(0)
2019.09.18 15:43:11 5: mybot: received PUBLISH (0)(19)$SYS/broker/versionHBMQTT version 0.9.5
2019.09.18 15:43:11 5: mybot: dispatch autocreate=simple\000fhemuser2_bumper_GLB19396e86\000$SYS/broker/version\000HBMQTT version 0.9.5
2019.09.18 15:43:17 5: mybot: received PUBLISH (0)Kiot/atr/GetIOTConnStatus/4532b934-c2b1-4277-9fa6-e4b4851c2688/02uwxm/Uq7d/j{"td":"GetIOTConnStatus","on":1,"conn":2,"ip":"192.168.178.47"}
2019.09.18 15:43:17 5: mybot: dispatch autocreate=simple\000fhemuser2_bumper_GLB19396e86\000iot/atr/GetIOTConnStatus/4532b934-c2b1-4277-9fa6-e4b4851c2688/02uwxm/Uq7d/j\000{"td":"GetIOTConnStatus","on":1,"conn":2,"ip":"192.168.178.47"}
2019.09.18 15:43:40 2: mybot: No PINGRESP for last PINGREQ (at 2019-09-18 15:43:04), disconnecting
2019.09.18 15:43:40 5: mybot: discarding DISCONNECT (224)(0)
2019.09.18 15:43:40 1: 192.168.178.47:8883 disconnected, waiting to reappear (mybot)
2019.09.18 15:43:40 5: HttpUtils url=https://192.168.178.47:8883/
2019.09.18 15:43:40 4: IP: 192.168.178.47 -> 192.168.178.47
2019.09.18 15:43:40 5: mybot: sending CONNECT (16)K(0)(4)MQTT(4)(194)(0)(30)(0)(28)fhemuser2@bumper/GLB19396e86(0)(25)webmaster@assetconsult.de(0)(6)123456
2019.09.18 15:43:40 5: SW: 104b00044d51545404c2001e001c6668656d75736572324062756d7065722f474c42313933393665383600197765626d6173746572406173736574636f6e73756c742e64650006313233343536
2019.09.18 15:43:40 1: 192.168.178.47:8883 reappeared (mybot)
2019.09.18 15:43:40 5: mybot: received CONNACK (0)(0)
2019.09.18 15:43:40 5: mybot: sending SUBSCRIBE (130)(6)(0).(0)(1)#(0)
2019.09.18 15:43:41 5: mybot: received SUBACK (0).(0)
2019.09.18 15:43:41 5: mybot: received PUBLISH (0)(19)$SYS/broker/versionHBMQTT version 0.9.5
2019.09.18 15:43:41 5: mybot: dispatch autocreate=simple\000fhemuser2_bumper_GLB19396e86\000$SYS/broker/version\000HBMQTT version 0.9.5
2019.09.18 15:44:10 5: mybot: sending PINGREQ (192)(0)
2019.09.18 15:44:11 5: mybot: received PINGRESP

mit autocreate simple:
define mybot MQTT2_CLIENT 192.168.178.47:8883
attr mybot SSL 1
attr mybot autocreate simple
attr mybot clientId fhemuser2@bumper/GLB19396e86
attr mybot mqttSubscribe #
attr mybot mqttVersion 3.1.1
attr mybot username webmaster@assetconsult.de
attr mybot verbose 5

per autocreate angelegtes device
defmod MQTT2_fhemuser2_bumper_GLB19396e86 MQTT2_DEVICE fhemuser2_bumper_GLB19396e86
attr MQTT2_fhemuser2_bumper_GLB19396e86 IODev mybot
attr MQTT2_fhemuser2_bumper_GLB19396e86 readingList fhemuser2_bumper_GLB19396e86:\$SYS/broker/version:.* version\
fhemuser2_bumper_GLB19396e86:iot/adr/test:.* test\
fhemuser2_bumper_GLB19396e86:iot/atr/BatteryInfo/4532b934-c2b1-4277-9fa6-e4b4851c2688/02uwxm/Uq7d/x:.* x\
fhemuser2_bumper_GLB19396e86:iot/atr/GetIOTConnStatus/4532b934-c2b1-4277-9fa6-e4b4851c2688/02uwxm/Uq7d/j:.* { json2nameValue($EVENT) }


Nicht wundern: disconnect/reappear kann an der schlechten Verbindung des Servers liegen(Powerline).

Jetzt muss ich mal gucken, wie ich das vernünftig bei MQTT2_DEVICE umsetze....

Und dann teste ich den Server mit SSL.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

ZitatJa, aber doch "nur" wie zuvor MQTT2_CLIENT ohne sslargs-Argumente(hier: Zertifikate).
Bei einem Server (FHEMWEB/telnet/MQTT2_SERVER) sind bei TLS Zertifikate Pflicht, die hatten wir schon "immer".

KölnSolar

Hi Rudi,
ich hab ja mittlerweile mein mqtt-device erfolgreich in FHEM eingebunden. :)

Nun möchte ich den Python-Server durch MQTT2_SERVER ersetzen. Das nicht funktionierende listInternals:
   CFGFN     
   CONNECTS   2147
   DEF        8883 global
   FD         19
   FUUID      5e3ec2da-f33f-5874-15f2-551e1c87e5483311
   NAME       myEcovacsServer
   NR         167436
   PORT       8883
   SSL        1
   STATE      Initialized
   TYPE       MQTT2_SERVER
   READINGS:
     2020-02-09 09:22:25   nrclients       -1
     2020-02-09 08:26:42   state           Initialized
   clients:
   retain:
Attributes:
   SSL        1
   autocreate simple
   room       Wohnzimmer
   sslCertPrefix bumper
   verbose    5
Zertifikat u. Key liegen in /opt/fhem bumpercert.pem u. bumperkey.pem u. werden meines Erachtens auch gefunden.

Der MQTT2_CLIENT bricht aber mit einem Reset immer wieder den TLS-handshake ab.  :'(
Einen Unterschied kann ich bei der Server-Antwort erkennen.
funktionierender Python-Server
Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 65
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 61
            Version: TLS 1.2 (0x0303)
            Random: 14428a45c1c529daad4894990eb2cf1daa4a07c0ca137754...
                GMT Unix Time: Oct  9, 1980 04:04:53.000000000 Mitteleuropäische Sommerzeit
                Random Bytes: c1c529daad4894990eb2cf1daa4a07c0ca137754444f574e...
            Session ID Length: 0
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
            Compression Method: null (0)
            Extensions Length: 21
            Extension: renegotiation_info (len=1)
                Type: renegotiation_info (65281)
                Length: 1
                Renegotiation Info extension
            Extension: ec_point_formats (len=4)
                Type: ec_point_formats (11)
                Length: 4
                EC point formats Length: 3
                Elliptic curves point formats (3)
            Extension: session_ticket (len=0)
                Type: session_ticket (35)
                Length: 0
                Data (0 bytes)
            Extension: extended_master_secret (len=0)
                Type: extended_master_secret (23)
                Length: 0
    TLSv1.2 Record Layer: Handshake Protocol: Certificate
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 1035
        Handshake Protocol: Certificate
            Handshake Type: Certificate (11)
            Length: 1031
            Certificates Length: 1028
            Certificates (1028 bytes)
                Certificate Length: 1025
                Certificate: 308203fd308202e5a0030201020202067a300d06092a8648... (id-at-commonName=Bumper Server,id-at-organizationName=Bumper)
                    signedCertificate
                        version: v3 (2)
                        serialNumber: 1658
                        signature (sha256WithRSAEncryption)
                        issuer: rdnSequence (0)
                        validity
                            notBefore: utcTime (0)
                            notAfter: utcTime (0)
                        subject: rdnSequence (0)
                        subjectPublicKeyInfo
                            algorithm (rsaEncryption)
                            subjectPublicKey: 3082010a02820101009aa36452a65c90cba553e36a7d8597...
                                modulus: 0x009aa36452a65c90cba553e36a7d859729624ac6afc3e8d7...
                                publicExponent: 65537
                        extensions: 6 items
                    algorithmIdentifier (sha256WithRSAEncryption)
                    Padding: 0
                    encrypted: 1c825c219cae97e6ed8e12c3acd21aba5ab3f9ba8aedefb5...
    TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 300
        Handshake Protocol: Server Key Exchange
            Handshake Type: Server Key Exchange (12)
            Length: 296
            EC Diffie-Hellman Server Params
                Curve Type: named_curve (0x03)
                Named Curve: x25519 (0x001d)
                Pubkey Length: 32
                Pubkey: 56ba8bfbff78ee1f0fc2878f6fbd3fcbd6d332b1b697d630...
                Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
                Signature Length: 256
                Signature: 384de35eabe1a11f02fa4354a2a23fc8a1d5863101de1273...
2. Paket
    TLSv1.2 Record Layer: Handshake Protocol: Certificate Request
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 52
        Handshake Protocol: Certificate Request
            Handshake Type: Certificate Request (13)
            Length: 48
            Certificate types count: 3
            Certificate types (3 types)
            Signature Hash Algorithms Length: 40
            Signature Hash Algorithms (20 algorithms)
                Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
                Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
                Signature Algorithm: ed25519 (0x0807)
                Signature Algorithm: ed448 (0x0808)
                Signature Algorithm: rsa_pss_pss_sha256 (0x0809)
                Signature Algorithm: rsa_pss_pss_sha384 (0x080a)
                Signature Algorithm: rsa_pss_pss_sha512 (0x080b)
                Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
                Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
                Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
                Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
                Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
                Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
                Signature Algorithm: SHA224 ECDSA (0x0303)
                Signature Algorithm: SHA224 RSA (0x0301)
                Signature Algorithm: SHA224 DSA (0x0302)
                Signature Algorithm: SHA256 DSA (0x0402)
                Signature Algorithm: SHA384 DSA (0x0502)
                Signature Algorithm: SHA512 DSA (0x0602)
            Distinguished Names Length: 0


Der MQTT2_SERVER stellt den certificate request nicht. Kann ich das mit SSL-Argumenten "provozieren" ?

Ein weiterer Unterschied liegt im Server Key Exchange(hier der MQTT2-Extrakt zum Vergleich zu obigen Python-Server)Handshake Protocol: Server Key Exchange
    Handshake Type: Server Key Exchange (12)
    Length: 329
    EC Diffie-Hellman Server Params
        Curve Type: named_curve (0x03)
        Named Curve: secp256r1 (0x0017)
        Pubkey Length: 65
        Pubkey: 04e73a969b68c652855742483f713b52600b6d1cc566acfc...
        Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
        Signature Length: 256
        Signature: 96a152cd9d77da69df6ed6cc875705ebfb8270d0c88bed04...
Der Unterschied ist in Pubkey Length u. Signature Algorithm. Macht das Probleme ? Kann ich das beeinflussen ?

Tappe da mal wieder ziemlich im Dunkeln.  :-[ :'(

Gibt es eigentlich irgendwo Dokuschnipsel zu SSL u. MQTT ? Ich hab mir da jetzt alles aus dem SourceCode ermittelt.  :(

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

ZitatDer Unterschied ist in Pubkey Length u. Signature Algorithm. Macht das Probleme ?
Ja, wenn der Client instruiert ist, Zertifikate mit diesen Daten abzulehnen.
Ich wuerde die gleichen Zertifikate wie beim python Server nehmen, um die Menge der moeglichen Fehler zu reduzieren.

ZitatKann ich das beeinflussen ?
Die obigen Parameter betreffen das Zertifikat, und die Prameter waehlt man beim Erstellen des Zeritifkats.
Weitere Algorithmen waehlt man per sslVersion Attribut, oder den im TcpServerUtils hartkodierten SSL_cipher_list.
Weiterhin sind die Module IO::Socket::SSL, NET::SSLeay, und die openssl Bibliothek relevant, Telegram hat z.Zt. Probleme mit veralteten Versionen dieser Dateien.

Es wird Zeit, dass jemand mit SSL Kenntnissen uns hilft.
Ich bin kein Krypto-Experte und will eigentlich auch nicht einer werden.

KölnSolar

#22
ZitatEs wird Zeit, dass jemand mit SSL Kenntnissen uns hilft.
Ich bin kein Krypto-Experte und will eigentlich auch nicht einer werden.
Versteh ich.  ;D Aber scheinbar bist Du noch der wissendste.  :'( ;D

ZitatIch wuerde die gleichen Zertifikate wie beim python Server nehmen
es sind sogar die selben.  ;)
daher hier
ZitatWeitere Algorithmen waehlt man per sslVersion Attribut, oder den im TcpServerUtils hartkodierten SSL_cipher_list.
weiter suchen ? :-\

ZitatGibt es eigentlich irgendwo Dokuschnipsel zu SSL u. MQTT ? Ich hab mir da jetzt alles aus dem SourceCode ermittelt
Da hast Du jetzt gar nichts zu gesagt. Ich würde sonst zumindest meine Erkenntnisse in einem Thread kommunizieren.

Danke&Grüße
Markus

Edit: Würde es Sinn machen MQTT2_SERVER auch ein sslargs-Attribut zu spendieren, um die verschiedensten Optionen nutzen zu können ? :-\
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

#23
ZitatGibt es eigentlich irgendwo Dokuschnipsel zu SSL u. MQTT ?
Ich weiss nicht, wonach du suchst, abgesehen von: bitte Doku mit Loesung fuer mein Problem :) .
MQTT2_SERVER hat die gleichen Moeglichkeiten wie FHEMWEB oder telnet, genauso wie MQTT_CLIENT die gleichen hat, wie HttpUtils*Get, weil jeweils die gleichen Bibliotheken verwendet werden, und zum Schluss landen alle bei IO::Socket::SSL->start_SSL.

Und meiner Ansicht nach sollte man da auch nichts aendern, hoechstens beim Server das Zertifikat, aber selbst das nur in aussergewohnlichen Faellen (wie mehrere FHEMs aus einem Verzeichnis).


ZitatWürde es Sinn machen MQTT2_SERVER auch ein sslargs-Attribut zu spendieren, um die verschiedensten Optionen nutzen zu können ?
Wenn du mir zeigst, welche dir helfen: gerne => ich glaube noch nicht daran, dass man das braucht.
Zum Experimentieren musst Du den start_SSL Aufruf direkt aendern.

KölnSolar

#24
ZitatIch weiss nicht, wonach du suchst, abgesehen von: bitte Doku mit Loesung fuer mein Problem :) .
so in etwa.  ;D Nein, ich meine etwas ausführlicher als die commandref zu z.B. sslargs, sslCertPrefix, sslVersion. Mit vielleicht Beispielen für den dummy. ;D

Mittlerweile habe ich Stunden verbracht und auch den Zertifikatespeicher noch einmal neu aufgebaut. openssl connected problemlos u. der Server zeigt mir auch den connceten client an(nrclients=1). :o ???
openssl s_client -connect meineIP:meinPort
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 O = Bumper, CN = Bumper CA
verify return:1
depth=0 O = Bumper, CN = Bumper Server
verify return:1
---
Certificate chain
0 s:O = Bumper, CN = Bumper Server
   i:O = Bumper, CN = Bumper CA
1 s:O = Bumper, CN = Bumper CA
   i:O = Bumper, CN = Bumper CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID/TCCAuWgAwIBAgICBnowDQYJKoZIhvcNAQELBQAwJTEPMA0GA1UEChMGQnVt
cGVyMRIwEAYDVQQDEwlCdW1wZXIgQ0EwHhcNMjAwMTA0MDgwNDU2WhcNMjIwMTA0
MDgwNDU2WjApMQ8wDQYDVQQKEwZCdW1wZXIxFjAUBgNVBAMTDUJ1bXBlciBTZXJ2
ZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCao2RSplyQy6VT42p9
hZcpYkrGr8Po1+9pqhp8TVeINDsPrML3IiGbr+LeBmgiNaftKU/0c6hSw2OvtsAA
XTx+kSSye4B8+zcmK3asLb1cwsCafmAmnbQ9KPq86mQZMY2giXRn7WjeczVhWSZ6
aHCC+itrBQsihaAwfbF7GdxDzGVwlQETOxxLRZPDGqDyvbAZzqqjQAFaygM4dJJG
iLc35eXcgSannhDAIXWs6+SVUGAMCUyoBsWvVCcgFcdJISFervd06CIc0dxfosMI
QcfHUaeUwHrdupwZW6AVQySZc/PZy2e61MOF9KCJby5AniQxgyARIatWxb4WU2gO
CY/NAgMBAAGjggExMIIBLTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFCO2TY8L83I4
2D46OE0G1Z678QprMB8GA1UdIwQYMBaAFIVuG+q2XWFwSF8q0Y3zjMg5AdIFMIGt
BgNVHREEgaUwgaKCC3Jhc3BiZXJyeXBpgglsb2NhbGhvc3SCC2Vjb3ZhY3MuY29t
gg0qLmVjb3ZhY3MuY29tggtlY291c2VyLm5ldIINKi5lY291c2VyLm5ldIILZWNv
dmFjcy5uZXSCDSouZWNvdmFjcy5uZXSHBH8AAAGHEAAAAAAAAAAAAAAAAAAAAAGH
BMCosjKHEP6AAAAAAAAA1mnbZ9Id2LSHBH8AAAEwDQYJKoZIhvcNAQELBQADggEB
AByCXCGcrpfm7Y4Sw6zSGrpas/m6iu3vtdaKNT7K5/yyc4PS8mgBKRwJjsDLpC4x
f2ydwL3G7qPey5dwa7plpSyW8BFiLfP8AlfQ5IQd3GyarmulgTOzRJxmoqoGhA4+
zvxqlFbrc/vaaimRXvykf8seRnm2Cp6I1WiA6h+jjU5qHSBgwrDxUgchM3Dyu5gy
UFvuhB1Pz2oI5ij0e9Hw5N8HXIeAHaBSdNsMCB5fnr/2x+S7GssQH9aQ8Yt58Ao6
l2OmuwAGHsklfvkET3OZuKvq8RW5uZ0MGuSKzrR8iby5z/3xUO5qFZDzkWDZ37v6
/VsEGzXgxpke3R5I06G0YBY=
-----END CERTIFICATE-----
subject=O = Bumper, CN = Bumper Server

issuer=O = Bumper, CN = Bumper CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2499 bytes and written 409 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: FA59BF5282A97D8E039FEFFDA2A9F1A4D4E38E870F3420F25741D80B9721287D
    Session-ID-ctx:
    Master-Key: 1CA53F99E6E78F20BCA40727E20AF96B1F8D91D42B6CE7E3134727CAD022737799FD46D4373A2B59B6167602EF8E4776
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 21 01 5f 81 a5 28 00 bc-e5 98 b8 fd f1 42 af 65   !._..(.......B.e
    0010 - 00 6f 34 1f 11 23 74 a1-10 60 d5 ca 85 6e 62 4b   .o4..#t..`...nbK
    0020 - 1a 0f 20 53 58 57 b4 df-2d 73 0a 46 87 87 e6 43   .. SXW..-s.F...C
    0030 - 3f 49 42 3d 90 8e b6 d1-ba 18 e3 98 49 47 60 3d   ?IB=........IG`=
    0040 - d3 ed 7f 41 36 4f 70 1b-bb ab 42 2f 77 f9 d3 e3   ...A6Op...B/w...
    0050 - 75 54 57 da bc 65 2d 88-41 26 1f 8e 2c 80 ab cb   uTW..e-.A&..,...
    0060 - 54 9d 11 0e c0 64 b8 83-34 4c 8c 10 40 69 98 90   T....d..4L..@i..
    0070 - 9c 34 08 33 e6 0f d4 93-e0 38 d6 b9 98 4a fc 7d   .4.3.....8...J.}
    0080 - 62 aa 00 66 42 02 26 61-56 82 d6 3e 96 62 03 5f   b..fB.&aV..>.b._
    0090 - d0 ad 57 40 6d 48 a3 00-59 0f ed 8e 3a ab 81 13   ..W@mH..Y...:...

    Start Time: 1581318249
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---


Ein "Testclient" define testClient MQTT2_CLIENT meineIP:meinPort
attr testClient SSL 1
attr testClient autocreate simple
attr testClient clientId fhemuser2@bumper/GLB19396e86
attr testClient mqttVersion 3.1.1
attr testClient sslargs SSL_version:TLSv12
liefert nun das im Log
2020.02.10 08:33:09 5: HttpUtils url=https://192.168.178.50:8884/
2020.02.10 08:33:09 4: IP: 192.168.178.50 -> 192.168.178.50
2020.02.10 08:33:13 4: Connection accepted from myEcovacsServer_192.168.178.50_34570
2020.02.10 08:33:16 4: HttpUtils: https://192.168.178.50:8884/: Can't connect(2) to https://192.168.178.50:8884:  SSL wants a read first
2020.02.10 08:33:16 1: [Freezemon] freezedetect: possible freeze starting at 08:33:10, delay is 6.08 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(RPi_OW_WWL)
2020.02.10 08:33:16 5: in:  CONNECT: (22)(3)(1)(0)(198)
2020.02.10 08:33:16 4:   myEcovacsServer_192.168.178.50_34570  CONNECT V: keepAlive:
2020.02.10 08:33:16 5: out: CONNACK:  (2)(0)(0)
2020.02.10 08:33:16 5: in:  RESERVED_0: (1)(0)
2020.02.10 08:33:16 2: myEcovacsServer_192.168.178.50_34570 RESERVED_0 before CONNECT, disconnecting

Hast Du dazu eine Idee ? Ist das nicht jetzt ein Fehler seitens MQTT u. die SSL-Verbindung hatte funktioniert ? Ist da evtl. MQTT nur zu schnell ?

Ich guck mal, was tcpdump jetzt dazu sagt...

Grüße Markus

Edit: Auch MQTTfx connected problemlos. Subscription funktioniert. Vom MQTT2_Server gepublischte topics werden empfangen. Sieht im Log dann so aus2020.02.10 08:50:44 4:   myEcovacsServer_192.168.178.35_60689 mqttfxuser2@bumper/GLB19396e86 DISCONNECT
2020.02.10 08:50:48 4: Connection accepted from myEcovacsServer_192.168.178.35_60799
2020.02.10 08:50:48 5: in:  CONNECT: (16)P(0)(4)MQTT(4)(192)(0)<(0)(30)mqttfxuser2@bumper/GLB19396e86(0)(25)myUsername(0)(9)myPassword
2020.02.10 08:50:48 4:   myEcovacsServer_myMQTTfx_:Client_IP_60799 mqttfxuser2@bumper/GLB19396e86 CONNECT V:4 keepAlive:60 usr:myUsername
2020.02.10 08:50:48 5: out: CONNACK:  (2)(0)(0)
2020.02.10 08:50:50 5: in:  SUBSCRIBE: (130)(6)(0)(1)(0)(1)#(0)
2020.02.10 08:50:50 4:   myEcovacsServer_myMQTTfx_:Client_IP_60799 mqttfxuser2@bumper/GLB19396e86 SUBSCRIBE
2020.02.10 08:50:50 4:   topic:# qos:0
2020.02.10 08:50:50 5: out: SUBACK: (144)(3)(0)(1)(1)
2020.02.10 08:51:08 5:   myEcovacsServer_myMQTTfx_:Client_IP_60799 mqttfxuser2@bumper/GLB19396e86 => iot/atr/test:blabla
2020.02.10 08:51:08 5: out: PUBLISH: 0(20)(0)(12)iot/atr/testblabla

Edit2: TLS läuft so ab
Client: Client Hello
Server: Server Hello
Server: Certificate, Server Key Exchange, Server Hello Done
Client: Client Key Exchange
Client: Change Cipher Spec
Client: Encrypted Handshake Message
Server: Change Cipher Spec, Encrypted Handshake Message

dann werden Daten verschlüsselt ausgetauscht

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

Hi Rudi,
ich glaub jetzt fast, dass das Problem gelöst ist.

Kann es sein, dass es UNSINN ist, ein MQTT2_DEVICE über einen MQTT2_CLIENT zu betreiben, wenn der Server ein MQTT2_SERVER ist ?

Ich sah, dass für den mqtt.fx-Client ein device per autocreate angelegt wurde. Und das funktionierte auch einwandfrei. Folglich habe ich das IODev meines MQTT2_DEVICE auf mein MQTT2_SERVER-device gesetzt und nun funktioniert alles wie es soll.

Was hat sich denn dann vorher "gebissen" ?

Danke&Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

ZitatKann es sein, dass es UNSINN ist, ein MQTT2_DEVICE über einen MQTT2_CLIENT zu betreiben, wenn der Server ein MQTT2_SERVER ist ?
Wenn CLIENT und SERVER in der gleichen FHEM Instanz definiert sind, dann sicher, duerfte auch nicht funktionieren :)

Sonst sollte es funktionieren.

rudolfkoenig

Nachtrag: habs gerade getestet, und zu meinem grossen Erstaunen kann man den CLIENT mit dem SERVER in der gleichen Instanz verbinden, nur mit SSL geht das nicht. Und das fixe ich auch nicht :)

Um es nochmal klar zu sagen: Ein MQTT2_CLIENT, der mit einem MQTT2_SERVER in der _gleichen_ FHEM Instanz verbunden ist, ist meiner Ansicht nach sinnlos, unerwuenscht und nicht supported.

KölnSolar

Hi Rudi,
ZitatUm es nochmal klar zu sagen: Ein MQTT2_CLIENT, der mit einem MQTT2_SERVER in der _gleichen_ FHEM Instanz verbunden ist, ist meiner Ansicht nach sinnlos, unerwuenscht und nicht supported.
Sehe ich JETZT auch so. Ist halt nur blöd, wenn man mit SSL rumhantiert.... und dabei dann, um eine Fehlerquelle auszuschließen... auf dieselbe Instanz wechselt und hat dann ein ganz anderes Problem, welches einem aber nicht in den Sinn kommt,  zu dem Zeitpunkt nicht gerade die do's and dont's von MQTT2 im Hinterkopf hat... ;)

Danke&Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt