Kirschiaub08

Are you using the latest version?

Th application got updated on April 24.

 Hello! I just tested again with the new version (you mean March 24 I guess). And again the same problem.

I would have been very surprised if this new version would fix the timestamp in the tls handshake. I dont know for sure but I bet that the handshake is not done on the application layer. The firmware has to do this. In the differen firmware versions of my S7 1200 I saw that openssl was added in FW version 4.3.

Therefore we would need a differen FW version (or new TCON version) which sends the correct timestamp. Since this most probably is done in the TCON Functionblock this would mean that no TLS secured communication would work. If enough people would have problems with this then siemens would be force to fix this soon. But I guess it will only be fixed if important customers need it.

My test environment: PLC: S7 1200 1212C AC/DC/Rly. Tia 16. LMQTT version from 24.03.2020. Borker: mosquitto with self created CA and client certificate.

Hi,

March, for sure 

I think, the best way to get the problems solved is to send feedback on the bottom of the application and/or create a support request. 

I believe the guys are doing there best to help us! 
Theoretically the applications are only a free gift for us and we should be happy for everyone 

EDIT:
The documentation says: "Alternatively you can use an S7-1200 CPU with firmware V4.3 or higher".

Are you using V4.3 and the newest OUC-blocks?

Kirschiaub08

Hi,

March, for sure 

I think, the best way to get the problems solved is to send feedback on the bottom of the application and/or create a support request. 

I believe the guys are doing there best to help us! 
Theoretically the applications are only a free gift for us and we should be happy for everyone 

EDIT:
The documentation says: "Alternatively you can use an S7-1200 CPU with firmware V4.3 or higher".

Are you using V4.3 and the newest OUC-blocks?

 What angers me a bit is the general trend to where software is no well tested and should be tested by the customer (the whole industry). I am also aware that software can never be bug free and every situation can be tested but this is such a general stuff it should be tested.

I forgot to mention that I am using FW4.4 (the newest). I dont know how to find new versions of OUC blocks if there are any. My TCON is V4.0

Puh, i dont know what the solution can be. The last time i tested the example (encrypted) it worked for me. but is is some time ago.
Siemens Support maybe is able to help.

The problem is: The customer wants the products/solutions fast and cheap ...

I got it working! In my case the problem was the TLS version required in the mosquitto broker. I set it to TLS1.3 but the PLC only supports version 1.2!

I set the tls version accordingly and it worked. What is still strange though is, that if I set the id for the server certificate the PLC connects nevertheless. Shouldnt it fail to connecte since the certificate 0 does not exist?

It's great that it works now. I forgot that it could also be because TLS version...

Hmm, it should get an error, i think.

Thanks to this post I was able to get the PLC talking to VerneMQ over TLS.

I've done some packet sniffing on the S7-1200's TLS handshake and for everyone's benefit here's what I found:

1. gmt_unix_time is out of whack as of firmware 4.4.1 I have not verified if this value is generated by PRNG or is derived from actual time. However, it should be noted that most modern TLS servers will disregard this value and it should not cause any connection issues (letter in defense of removing gmt_unix_time: https://tools.ietf.org/id/draft-mathewson-no-gmtunixtime-00.txt)

2. TLS version: 1.2 only

3. Supported cipher suites: