FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
1,047 views 2 comments
by anonymous
Hi!
I've been seearching the forums and google for a while to figure out this.
First of I am very confused with the term .ca used here and there in the manuals. Is this a regulare .pem file renamed to .ca? Base64 encoded? Or is it a .p7b? https://wiki.teltonika-networks.com/view/TRB145_Data_to_Server

I'm using the TRB145 collecting data from several modbus devices which works great!
How ever the TLS options in Data to Server are not up to specc in my opinion.

If I ssh/telnet to the TRB I am easily able to curl a POST to my cloud server (using TLS) using the built in CA provided in the firmware/OS.
But the HTTPS post in "Data to Server" does not work, even if i supply the same CA as the unit is running.

The same goes for MQTT(S). If i connect to a non TLS broker it all works perfectly, how ever if I enable TLS it all goes south.

I saw the same things in: https://community.teltonika-networks.com/25578/cannot-publish-trb245-remote-broker-what-wrong-with-settings

The HTTPS/MQTTS should not require a client cert/key and should in my opinion use the built in CA if no CA is supplied in the configuration.

1 Answer

0 votes
by anonymous

Hello,

Is your server certificate self-signed? It sounds like the issue in this case is most likely TLS handshake not completing. To confirm this, could you do a packet capture when the router is attempting to connect to the provided server? 

Note: the "tcpdump" package will be necessary for this. If it's not already installed on the device, please navigate to the package manager at Services>Package manager>Packages then find the "tcpdump" package and install it.

1) Login to the router via WebUI and disable the "Data to Server" service at Services>Data to Server

2) Navigate to System>Administration>Troubleshoot. Once there, select the option "Enable TCP dump". Then, configure to capture only the most specific traffic by specifying the following parameters:

Select interface: <your mobile interface used for internet connectivity>

Select protocol filter: All

Select packets direction: Incoming/Outgoing

Host: <The data server IPv4 address>

Port: <Destination port used to connect to the server>

Select storage: RAM memory

When done, enable the TCP dump, then save & apply settings

3) Navigate back to the Services>Data to Server and enable the service. Give the router a minute to try and connect

4) Navigate back to System>Administration>Troubleshoot and download the TCP dump file

5) When TCP dump file has been downloaded, disable the tcpdump packet capture

6) Additionally, please generate a troubleshoot file and attach it as well

Once you have both the tcpdump and the troubleshoot file, please send these files over to me via private message.

Best regards,

Tomas.

by anonymous
Thanks for the reply. Had a week of work for skiing.

No, our server certificates are not self signed. They are Let's Encrypt.

With the correct CA for LE and no client cert and key assigned in the "Data to Server" the client can not connect.

I haven't digged through your source code to verify what client you are using but this seems like a configuration issue to me.

I have not come across a mqtt client needing to have client cert for the auth process.
 

Furthermore, while fiddling around to get this to work I generated some self-signed mTLS certificates for client authentication to test this.

With the same CA (LE) as before and now with some self-signed certs for client mTLS I can get this to work.

(Files sent privately :) )
by anonymous

Hi,

I've taken a look into this issue and unfortunately the only way to work around this issue right now is to use either real or dummy client certificate and a private key, similar to what svet has suggested in this thread. We are aware of this problem and it will be fixed in the future, the current milestone to fix this issue is set to firmware version 7.2 but we do not have a definitive ETA on its release date yet.

Best regards,

Tomas.