I don't know if this post can even be called a blog. Basically, I'll write about a single screenshot :).
When I wrote a blog Communication - MQTT in practice some time ago, I described using the Stunnel utility to TLS encrypt MQTT communication and thus create MQTTS communication - similar to how HTTP can be wrapped in a TLS envelope to create HTTPS.
In another blog, Communication - encryption, I described the enhancement of the configuration of TCP/IP-TCP and TCP/IP-TCP Redundant lines. The configuration now includes the option to specify a certificate and private key for the D2000 KOM process as well as the communication partner's certificate. If they are specified, the D2000 KOM process will create a TLS connection. If the communication partner's certificate is also specified, it will verify the identity of the other party.
So today I want to show you a screenshot from a colleague who configured a TCP/IP-TCP Redundant line in a new production application so that the communication is encrypted. The line contains stations with the MQTT protocol, which is used to control the PIXII battery storage.
You can see the path to the certificates and private key. The symbolic constant #APPDIR# is replaced with the name of the application directory, e.g. /opt/d2000/app/tlfc on the Linux platform on which this particular application (tlfc) is running.
In the future, it is also possible to increase the protection of the private key by password-protecting it and entering the password in the “Shared key” field. If the key were stolen from the server disk, password protection will reduce the possibility of its misuse.
And another new feature: In order for a redundant station with the MQTT protocol to be on the TCP/IP-TCP line, support for a redundant TCP line had to be implemented in this protocol.
This happened during this summer. It is currently possible to configure redundant connections - i.e. two TCP connections are created at the same time, each to one MQTT broker. If both MQTT brokers do not have a certificate signed by the same certification authority, it is possible to specify multiple partner certificates (separated by a comma) in the line configuration; alternatively, there may be multiple certificates in the CRT file.
What are two parallel TCP connections to two MQTT brokers good for? They allow you to create a redundant system (2 x D2000 Server, 2 x MQTT broker) by using a simple MQTT broker such as Eclipse Mosquitto (instructions for its configuration, including creating certificates and setting access rights, are in our documentation). It is therefore not necessary to use any of the commercial MQTT brokers, which are interconnected, exchange messages and thus create an MQTT cluster. Since the D2000 KOM process can connect to both MQTT brokers in parallel, it is sufficient for other MQTT clients (e.g. PLC) to be able to connect to one of them (i.e. they must be able to enter at least 2 IP addresses in the configuration, but only a single TCP connection to one of MQTT brokers is created at a time).
By the way, the D2000 KOM can also try multiple IP addresses or symbolic names. They can be entered in the TCP/IP-TCP or TCP/IP-TCP Redundant line configuration in the Host field, separated by a comma or semicolon. So, if we have two redundant MQTT brokers that are together with D2000 Servers on two redundant networks, then each of the MQTT brokers has two IP addresses that can be entered in the Host field. At any time, two TCP connections can be open, each of them to one of the two IP addresses of the redundant MQTT brokers.
The situation will be similar to the following figure, borrowed from our IEC 870-5-104 protocol documentation. SrvA and SrvB can represent MQTT servers, ClientC and ClientD can represent D2000 Servers.
The line configuration would look like this:
Another note on D2000 redundancy. The line configuration would look identical regardless of whether the D2000 system was non-redundant or whether it contained 2, 3 or more redundant D2000 servers. In any case, only the active D2000 KOM process (connected to the active D2000 Server) would establish connections to the MQTT brokers. The same applies in a configuration with multiple instances of D2000 KOM processes (e.g. located on dedicated communication servers). At any time, only the active instance of the D2000 KOM process communicates with the MQTT broker.
Conclusion
Today's blog showed two new features in D2000 used in practice. Support for the TCP/IP-TCP Redundant line in the MQTT protocol as well as support for encryption on this line allow creating redundant and secure communications with devices - whether with the MQTT protocol or other protocols, e.g. mentioned IEC 870-5-104. Thus contributing to improving the safety of control systems built on the Ipesoft D2000 real-time application server technology.
And the cherry on top: Using the newly implemented tell command CHECK CERTS, it is possible to check all certificates configured on the lines of the respective D2000 KOM process. The validity period, issuer and subject are displayed on the console and in the log. This way you can easily check whether any of the certificates are about to expire.
September 26, 2025, Ing. Peter Humaj, www.ipesoft.com
