Secure communication

Securing communication channel between the client and the service is of utmost importance. Thriot supports HTTP and WS (Websockets) protocols with their secure counterparts: HTTPS and WSS. Security is achieved by using (X509) certificates. Certificates are used to encrypt the communication channel via TLS (HTTPS and WSS) besides certifying the service identity.

For more information about certificates please refer to the following sites:

Obtaining or Creating X509 certificates

You can obtain the certificate from a trusted certificate authority or create a self-signed one.

Thriot has some non-production self-signed certificates that this documentation and the test environments rely on:

In the rest of this page these certificates and private keys are referred.

The way you can create self-signed certificates on Windows is described in the following document:

In case of Thrit the CreateRootCA.cmd is responsible for creating root certificates while the other commands are used to create server specific certificates. The password for the root CA primary key is: ThriotRootCAPwd123, while for the host certs are ThriotIoPwd123.

Securing HTTP(S) services

IIS on Windows and nginx on Linux must provide HTTPS channel, too. Of course it’s free to serve content from IIS in HTTP and put an nginx reverse proxy in front of IIS to provide HTTPS traffic, but this scenario can be derived from the below description.

IIS on Windows

To be able to support certificates on IIS first we need to install the Root CA cert and the host specific cert and private key to the certificate store, also described in this document: .

The following document describes how to  setup HTTPS on IIS: .This page also describes the way to obtain for a trusted root CA certified certificate.

nginx on Linux

The following example describes how to setup HTTPS on nginx and supposes that the cert and the private key is placed under the /opt/thriot/certs directory:

crt and key files from the pfx can be created using openssl the following way:

Websocket service

Secure Websocket (WSS) is support can be easily added to Thriot Websocket service by adding the -security tls switch to build.ps1 or using such template for buildconfigure.ps1.


Having set the security tls switch on Windows the recommended way the select the right certificate (along with the private key, of course) is to look it up by its thumbprint. Eg.

<certificate storeName=”My” storeLocation=”LocalMachine” thumbprint=”3A5A91823363B8FD2A9A26DD9C5E851A1677211A”/>

Only those endpoints will have enabled tls where the Tls flag is set. See config/supersocket.tls for more information.

To let this work the pfx file should be added to the key store. Ensure that the root CA cert is also added to the keystore (especially for self-signed certificates)


On Linux the situation is quite similar except for the fact that the certificate is preferred to be loaded from a file system. The build processes prefer also this way.

Supporting TLS on Client

Both .NET and Linux C++ client support security communication. Of course Urls starting with HTTPS or WSS will be secured.

.NET client

The .NET client requires to have the client certificate to be added to the certificate store.

Linux C++ client

Thriot Linux C++ client is using OpenSSL. There are two options to support TLS-based communication:

  1. Install the self-signed certificate to the certificate store
  2. Use the ClientSettings class to disable certificate validation. Host name validation can be also disabled for HTTPS.