As our dependency on the internet has grown, the risks have also grown. Unencrypted HTTP requests reveal information about a user’s behavior, and the interception and tracking of unencrypted browsing has become commonplace.

When properly configured, HTTPS can provide a fast, secure connection that offers the level of privacy and reliability that users should expect.

Therefore, we highly recommend that you configure Orchestra to use HTTPS / SSL / WSS for all communication.

First, let’s go through the basics.

Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted.

Secure Sockets Layer (SSL) is a standard security protocol for establishing encrypted links between a web server and a browser in an online communication. The usage of SSL technology ensures that all data transmitted between the web server and browser remains encrypted.

WebSocket Secure (WSS) is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. WebSocket is designed to be implemented in web browsers and web servers, but it can be used by any client or server application.

When you request a HTTPS connection to a web page, the website will initially send its SSL certificate to your browser. This certificate contains the public key needed to begin the secure session. Based on this initial exchange, your browser and the website then initiate the 'SSL handshake'. The SSL handshake involves the generation of shared secrets to establish a uniquely secure connection between yourself and the website.

When creating a certificate, the certificate is only valid for the actual host name that it is created for (the "CN" attribute).

This should be the only host name which is used when communicating securely with an Orchestra system.

For example, if the host orchestra-central.company.com is used when setting up SSL for the Central system, all distributed Queue Agents should be configured (in agent.conf) to communicate towards that hostname and not the IP-address of the host.

If a mix of hostnames and IP-address needs to be used for self-signed certificates, the "-ext san=..." flag should be used when creating the certificate.

In this manual, we distinguish between the following kinds of certificates:

For both a)-versions above, the truststore needs to be updated. For both b)-versions above, the Queue Agent already trusts the certificate, so no changes are needed on the Queue Agent.

The instructions below describe what to do, depending on what kind of certificate you are using.

 

The purpose of the truststore is to verify credentials and the purpose of the keystore is to provide credential.

In other words, the main difference between a truststore and a keystore is that truststore is used to store certificates from trusted Certificate Authorities (CA) which are used to verify certificates presented by the Server in SSL Connection, while keystore is used to store private key and own identity certificates which a program should present to other parties (Server or client) to verify its identity.

Orchestra is installed with a default keystore and a default truststore. The truststore is a copy of the Java Runtime Environment (JRE) truststore and the keystore is empty.

Both files are located in the folder <installation directory>/conf/security.

Keystore files for standalone Queue Agents also follow the same structure and the files are included in the default Queue Agent profiles.

In order to use another keystore or truststore, the settings are located in the following files:

 

The values that affect keystore and truststore settings:

 

The following image illustrates the ports and protocols used in Orchestra:

In the instructions below, we will go through the image above and how to set up secure communication for each part.