As part of OL Connect’s security improvement strategy, support for HTTPS connections was introduced in OL Connect Server in the 2021.1 release. In this article, we’ll explain why this change is important, how to enable it, and how to use it from clients such as OL Connect Workflow and the OL Connect Designer.

Secure Connections

Adding https support to OL Connect Server is an important step in improving the security of OL Connect as a product. Client software* that communicates with OL Connect Server can now do this without the risk of data being intercepted. This is essential for authentication, i.e., to keep a password secret, but also to keep data private over untrusted networks.

* Client software: OL Connect Workflow, OL Connect Designer, Node-RED or any other tool that directly uses the REST API.

OL Connect Server and https

Https support only applies to external clients connecting to OL Connect Server. The internal communication between Server and its engines (and its Server Extensions in the case of a clustered PReS Connect setup) does not use https and must be set up to use different ports when configuring https.

Having the internal communication on separate ports means it can be shielded with firewall rules if needed. In most OL Connect deployments, the internal communication all happens locally on the server, which means that a malicious user would need access to the server to be able to eavesdrop on the conversaion between the Server and its modules. And if someone has access to the Server, well then all bets are off anyway.

Configuring https

Https is not enabled by default. To start using it you need to configure OL Connect Server as well as each client that connects to it.

OL Connect Server Configuration

To configure OL Connect Server to use https, start the OL Connect Server Configuration tool and go to the Connections page. This page changed considerably from what it looked like prior to version 2021.1. The other changes are explained below.

The defaults for these settings are different from what is shown above, and their initial settings can also be different in case of an updated installation. To set OL Connect to use https, simply select https from the Protocol dropdown. This enables the settings below it so you can configure the certificate to use.

At the very least, you need to configure a Server certificate, and a Private key file. If the private key file is password protected, the password must also be provided. And if the certificate is not a self-signed certificate, the root certificate file has to be provided as well.

Note! Make sure to keep private key files private.

When using https for client connections, you must set the internal communication ports to different values. Internal communication is the communication between OL Connect Server, its engines, and Server Extensions (in case of clustering). You may pick any valid, unused port.

Applying these settings and restarting the Server is all that is needed to make it accept only secure connections. All that remains is to configure the clients of the OL Connect Server to use https as well.

Using https between OL Connect Workflow and OL Connect Server

Once OL Connect Server has been configured for https, OL Connect Workflow must be configured to use https as well, or they will not be able to communicate. Go to the OL Connect Workflow preferences and select the Behavior/OL Connect page. Simply select https from the Protocol drop-down.

After selecting https, the port may automatically change to 443. Make sure that the port matches whatever port was configured in the OL Connect Server configuration.

Designer connection settings

In OL Connect Designer, go to the preferences and open the Server/Connect Servers preference page. Simply change the prefix of the url from http to https.

Obtaining a certificate

For production purposes, it is highly recommended that you obtain a proper certificate issued by an official Certificate Authority. These certificates are associated with a specific domain, so this is usually handled by the person managing that domain, typically someone from your IT department.

Such certificates can be obtained from many different commercial parties, but it’s likely that you are already dealing with a preferred Certificate Authority if you already use certificates for other applications. Alternatively, you may turn to a service like Let’s Encrypt, which provides an easy way of obtaining an official certificate for free (but you will have to renew the certificate more frequently).

Sometimes a server has not been added to a domain, or a local domain is used for internal servers. In cases like that, the IT department is either managing and creating their own certificates (i.e., they are the Certificate Authority), or you have to use a self-signed certificate.

Creating self-signed certificates

The easiest way to create a self-signed certificate is to simply go to selfsignedcertificate.com. Just type a server name, domain, or even just localhost, and download the certificate and its private key.

Alternatively, you can create your own certificate locally by using OpenSSL. Getting OpenSSL may be a bit of a pain, because you either compile it yourself, or get it from a third party that you trust. A nice source can be Git, because that has OpenSSL bundled.

Creating the certificate and private key is a single command. For example:
openssl req -x509 -sha256 -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt

Or like this if you don’t want a password for the key file:
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt

You can also create self-signed certificates directly with Windows PowerShell. But you still must export these from the certificate store and use OpenSSL to get the certificate and key separately from the .pfx file.

Keep in mind that when using a self-signed certificate, clients connecting to OL Connect Server might need to be told to trust it. OL Connect Workflow trusts self-signed certificates without specifically being told to (some exceptions might be tasks such as Render Email Content, Download EML Messages). OL Connect Designer has the option “Ignore certificate errors on https connections” for this.

Note that the OL Connect Server supports TLS version 1.2 or higher. TLS version below 1.2 or SSL are not supported, because they are no longer considered secure.

Changes to OL Connect Server Connections

The introduction of https support for OL Connect Server required several additional changes to make sure that all of the components that make up OL Connect Server (engines, server extension, the server itself) could still talk to each other.

When comparing the previous and current preferences page, besides the new settings for https, you’ll notice some things were renamed, and others were moved.

REST Services

The “primary connection” is now labeled with its main purpose: to provide REST services to clients such as OL Connect Workflow and OL Connect Designer. OL Connect can still handle all its communication on a single port if “Internal communication on separate ports” is disabled, but then it’s not possible to enable https.

Internal communication on separate ports

OL Connect Server needs to be able to communicate with its engines. Since engines are not necessarily running on the same server (PReS Connect supports clustering), this is all done through network communication.

While previous versions allowed that communication to take place on a secondary port, the more current versions introduced yet another additional port for this. Using three ports is the recommended setup for OL Connect Server. The benefits:

• better for security – separate ports can be firewalled to block or limit external access, while still allowing clients from other systems to connect;
• better for stability under load – on very busy systems, a flood of requests from clients cannot cause communication drops with the engines if these communicate on separate ports.

Note that https is not supported for internal communications.

Advanced

These settings were set aside because they act on all ports that are being used, so this layout better reflects that. As before, only touch these settings if you know you have a reason to do so.

Server Extensions

In a clustered PReS Connect setup, the Server Extension and the engines running on the extension’s node need to match their connection setup with the settings on the main server. All the communication between OL Connect software components qualifies as internal communication. So, if the server is set to use separate ports for internal communication, the Server Extension’s Connection settings must match the ports for internal communication.