# Set up secure connections between DataSource applications

Here are some examples that show you how to configure secure connections between two DataSource applications using the Secure Sockets Layer (SSL)

The [first example](#ssl-connections-for-c-based-datasource-applications) shows configuration for an SSL connection between [Liberator](../liberator/index.md) and a _C-based_ [Integration Adapter](../platform-architecture/putting-data-into-the-platform.md), and the [second example](#ssl-connections-for-java-based-datasource-applications) is for Liberator connecting to a _Java-based_ Integration Adapter. The examples assume you know how to obtain an SSL certificate, private key and public key, and, for the Java-based Integration Adapter, that you know how to set up a Java KeyStore.

These examples of DataSource SSL configuration apply to **release 6.2 and later** of the following APIs and Caplin Platform components:

* C DataSource API
* Caplin Integration Suite
* Liberator
* Transformer

Older versions of these APIs and components use an earlier, incompatible version of the configuration. For details, see section 12.8 "Direct connections using SSL" of the **[Liberator 6.0 Administration Guide](https://docs.caplin.com/developer/docs/Liberator60AdminGuide.pdf)**.

## SSL connections for C-based DataSource applications

Assume you have two DataSource applications, one is a Liberator called **MyLiberator** and the other is a C-based Integration Adapter called **MyIntegrationAdapter**. The following configurations allow MyIntegrationAdapter to connect to MyLiberator through a secure connection using SSL. For the sake of clarity, the Liberator configuration doesn’t include any [data services](datasource-data-services.md), though you’d normally add some to a real setup.

**Peer SSL connnection configuration for MyIntegrationAdapter (the Adapter is the SSL client):**

```
datasrc-name           MyIntegrationAdapter-%h
[[myintegrationadapter]]xref:datasource-datasource-peers-configuration-part-2.md#datasrc-local-label[datasrc-local-label]    MyIntegrationAdapter

add-peer
   remote-name   MyLiberator
   remote-label  MyLiberator
   addr         <MyLiberators-hostname>
   port         <MyLiberators-portnumber>
   ssl TRUE
   ssl-present-certificate  %r/certs/MyIntegrationAdapterCert.pem
   ssl-accept-certificate   %r/certs/rttpd.pem
   ssl-privatekey           %r/certs/MyIntegrationAdapterPkey.key
   ssl-passwordfile         %r/certs/MyIntegrationAdapterPassword.pwd
end-peer

ssl-config-name /etc/pki/tls/openssl.cnf
```

Here’s an explanation of what the ssl options in MyIntegrationAdapter’s add-peer are for:

* `[ssl](datasource-datasource-peers-configuration-part-1.md#ssl) TRUE` tells the Adapter to initiate an SSL connection with its peer (the Liberator).
* [`ssl-present-certificate`](datasource-datasource-peers-configuration-part-1.md#ssl-present-certificate) must be present. It specifies the SSL certificate file that MyIntegrationAdapter sends to MyLiberator when initiating the secure connection. This is the certificate that identifies MyIntegrationAdapter to MyLiberator.
* [`ssl-privatekey`](datasource-datasource-peers-configuration-part-1.md#ssl-privatekey) must be present too. It specifies the SSL private key associated with the certificate specified by `ssl-present-certificate`. MyIntegrationAdapter uses the key to decrypt messages from MyLiberator.
* [`ssl-accept-certificate`](datasource-datasource-peers-configuration-part-1.md#ssl-accept-certificate) specifies the SSL certificate file that MyIntegrationAdapter uses for certificate pinning. When the SSL connection is being established with MyLiberator, MyIntegrationAdapter compares the public key in the certificate received from the Liberator against the public key in the `ssl-accept-certificate` file. If the keys don’t match, the adapter terminates the (probably unauthorised) connection.

  You can supply a chain of certificates for certificate pinning, as long as they’re concatenated together into a single SSL certificate file that’s supplied to `ssl-accept-certificate`. The certificates must be added to the file such that the highest level CA is last in the chain; for example: `MyCertificate -> Intermediate-CA-1 -> Intermediate-CA-2 -> Root-CA` where `Root-CA` is the highest level CA.

  Once you’ve produced the certificate file, you should verify that the chain of certificates it contains is correct. You can do this with the OpenSSL `verify` command (use the `-CAfile` option).
* [`ssl-passwordfile`](datasource-datasource-peers-configuration-part-1.md#ssl-passwordfile) specifies a file that contains a plain text (unencrypted) password used to access the private key file and the certificate files specified by `ssl-privatekey` and `ssl-passwordfile`.
* And finally, the global item [`ssl-config-name`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#ssl-config-name) specifies the OpenSSL configuration file that’s loaded by MyIntegrationAdapter. You don’t have to supply a configuration file for OpenSSL, but if you don’t, OpenSSL will use its default settings.

**📌 NOTE**\
The two certificate files and the private key file must be in PEM format.

**💡 TIP**\
For more about certificate pinning, see the Wikipedia article at [https://en.wikipedia.org/wiki/Certificate_pinning#Certificate_pinning](https://en.wikipedia.org/wiki/Certificate_pinning#certificate-pinning).

**💡 TIP**\
You might also need to [seed the Open SSL random number generator](datasource-seed-the-openssl-random-number-generator.md).

**Peer SSL connection configuration for MyLiberator (Liberator is the SSL server):**

```
datasrc-name        MyLiberator-%h
datasrc-local-label MyLiberator

datasrc-ssl-enable       TRUE
datasrc-ssl-port         25001
datasrc-ssl-certificate  %r/certs/rttpd.pem
datasrc-ssl-privatekey   %r/certs/rttpd.key
datasrc-ssl-passwordfile %r/certs/rttpd.pwd
ssl-config-name          /etc/pki/tls/openssl.cnf

add-peer
   remote-name  MyIntegrationAdapter
   remote-label MyIntegrationAdapter
   ssl TRUE
   ssl-accept-certificate %r/certs/MyIntegrationAdapterCert.pem
end-peer
```

Here’s an explanation of what MyLiberator’s ssl configuration items do:

* `[datasrc-ssl-enable](datasource-datasource-secure-sockets-layer-ssl-configuration.md#datasrc-ssl-enable) TRUE` tells the Liberator to accept incoming SSL connections from Datasource peers.
* [`datasrc-ssl-port`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#datasrc-sslport) specifies the network port that the Liberator is to listen on for Secure Sockets Layer (SSL) connection requests from DataSource peers. You must specify a port, otherwise the Liberator won’t accept incoming SSL connections, regardless of whether datasrc-ssl-enable is set to TRUE.
* [`datasrc-ssl-certificate`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#datasrc-ssl-certificate) specifies the certificate that the Liberator sends to an SSL client (in this case, MyIntegrationAdapter) when the client requests the server’s (Liberator’s) certificate for the SSL handshake.
* [`datasrc-ssl-privatekey`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#datasrc-ssl-privatekey) specifies the SSL private key that the Liberator uses to decrypt the symmetric session key received from a DataSource peer (in this case, from MyIntegrationAdapter).
* [`datasrc-ssl-passwordfile`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#datasrc-ssl-passwordfile) specifies a file that contains a plain text (unencrypted) password used to access the private key file and the certificate file specified by `datasrc-ssl-privatekey` and `datasrc-ssl-passwordfile`.

**⚠️ WARNING**\
We strongly recommend that you password protect the private key file and certificate file.

* [`ssl-config-name`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#ssl-config-name) (optional) specifies the OpenSSL configuration file that’s loaded by MyLiberator
* The [`add-peer`](datasource-datasource-peers-configuration-part-1.md#add-peer) configuration specifies the SSL connection to MyIntegrationAdapter:
  * `[remote-label](datasource-datasource-peers-configuration-part-1.md#remote-label) MyIntegrationAdapter` matches the [`datasrc-local-label`](#myintegrationadapter) in MyIntegrationAdapter’s configuration.
  * `[ssl](datasource-datasource-peers-configuration-part-1.md#ssl) TRUE` ensures that the Liberator will only accept SSL connection requests from MyIntegrationAdapter; it rejects any request for a non-secure connection.
  * [`ssl-accept-certificate`](datasource-datasource-peers-configuration-part-1.md#ssl-accept-certificate) specifies the SSL certificate file that the Liberator uses for certificate pinning. When the SSL connection is being established with MyIntegrationAdapter, Liberator compares the public key in the certificate received from the MyIntegrationAdapter against the public key in the `ssl-accept-certificate` file. If the keys don’t match, the Liberator terminates the (probably unauthorised) connection.

**📌 NOTE**\
The certificate file and the private key file must be in PEM format.

## SSL connections for Java-based DataSource applications

What if your Integration Adapter is written in Java? (It will be if you’ve implemented it using the Caplin Integration Suite.) In that case, the SSL configuration is slightly different. Following on from the [C-based configuration example above](#ssl-connections-for-c-based-datasource-applications), assume that now you want to replace MyIntegrationAdapter with a Java version called **MyJavaAdapter**, and as before, MyJavaAdapter connects to MyLiberator through a secure connection using SSL.

**The Liberator (SSL server) configuration doesn’t change**, other than the Adapter name in the `add-peer`:

```
datasrc-name        MyLiberator-%h
datasrc-local-label MyLiberator

datasrc-ssl-enable         TRUE
datasrc-ssl-port           25001
datasource-ssl-certificate %r/certs/rttpd.pem
datasrc-ssl-privatekey     %r/certs/rttpd.key
datasrc-ssl-passwordfile   %r/certs/rttpd.pwd
ssl-config-name            /etc/pki/tls/openssl.cnf

add-peer
   remote-name  MyJavaAdapter
   remote-label MyJavaAdapter
   ssl TRUE
   ssl-accept-certificate %r/certs/MyIntegrationAdapterCert.pem
end-peer
```

**The configuration for MyJavaAdapter (the SSL client) looks like this:**

```
datasrc-name        MyJavaAdapter-%h
datasrc-local-label MyJavaAdapter

datasrc-ssl-keystore     %r/certs/MyJavaAdapterKeyStore.jks
datasrc-ssl-passwordfile %r/certs/MyJavaAdapterPassword.pwd

add-peer
   remote-name   MyLiberator
   remote-label  MyLiberator
   addr         <MyLiberators-hostname>
   port         <MyLiberators-portnumber>
   ssl TRUE
   ssl-present-certificate  <certificate-name-in-datasrc-ssl-keystore>
   ssl-accept-certificate   <certificate-name-in-datasrc-ssl-keystore>
end-peer

ssl-config-name /etc/pki/tls/openssl.cnf
```

* Rather than putting MyJavaAdapter’s SSL certificate and private key in separate files, you keep them in a Java KeyStore, along with copies of the certificates used for certificate pinning. You specify the KeyStore in [`datasrc-ssl-keystore`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#datasrc-ssl-keystore).
* If you want to password protect the KeyStore, specify the password file in [`datasrc-ssl-passwordfile`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#datasrc-ssl-passwordfile).

**⚠️ WARNING**\
We strongly recommend that you password protect the Java KeyStore.

* As in the C-based Adapter example, the `[ssl](datasource-datasource-peers-configuration-part-1.md#ssl) TRUE` option of the [`add-peer`](datasource-datasource-peers-configuration-part-1.md#add-peer) tells MyJavaAdapter to initiate an SSL connection with its peer (the Liberator).
* [`ssl-present-certificate`](datasource-datasource-peers-configuration-part-1.md#ssl-present-certificate) must be present. It specifies the SSL certificate file that MyJavaAdapter sends to MyLiberator when initiating the secure connection. This is the certificate that identifies MyJavaAdapter to MyLiberator. Since we’re keeping the certificate in a Java KeyStore, `ssl-present-certificate` is just the name of the relevant certificate in the KeyStore.
* [`ssl-accept-certificate`](datasource-datasource-peers-configuration-part-1.md#ssl-accept-certificate) specifies the name of an SSL certificate file in the Java KeyStore. This is the certificate that MyJavaAdapter uses for certificate pinning. When the SSL connection is being established with MyLiberator, MyJavaAdapter compares the public key in the certificate received from the Liberator against the public key for the certificate in the Java KeyStore. If the keys don’t match, the adapter terminates the (probably unauthorised) connection.

  You can supply a _chain_ of certificates for certificate pinning, as long as they’re in [PKCS](https://en.wikipedia.org/wiki/PKCS)#7 format. You import the chain to the Java KeyStore using the [KeyStore utility](https://docs.oracle.com/javase/7/docs/technotes/tools/solaris/keytool.html) and the chain is then handled by the standard Java cryptography library. The certificates must be chained such that the highest level CA is last in the chain; for example: `MyCertificate -> Intermediate-CA-1 -> Intermediate-CA-2 -> Root-CA` where `Root-CA` is the highest level CA. Then set `ssl-accept-certificate` to the name of the lowest level certificate in the chain; in the example here, this would be to `MyCertificate`.
* And finally, the (optional) item [`ssl-config-name`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#ssl-config-name) specifies the OpenSSL configuration file that’s loaded by MyJavaAdapter.

## Configuring OpenSSL

C-based DataSource applications use the [OpenSSL](https://www.openssl.org) software to implement the security policies for secure connections with peers. You can configure OpenSSL using the following DataSource configuration items, which are defined on the page [DataSource Secure Sockets Layer (SSL) configuration](datasource-datasource-secure-sockets-layer-ssl-configuration.md):

* [`ssl-config-name`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#ssl-config-name)
* [`ssl-debug`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#ssl-debug)
* [`ssl-engine-flags`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#ssl-engine-flags)
* [`ssl-engine-id`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#ssl-engine-id)

**📌 NOTE**\
When you change the configuration of OpenSSL within Liberator, the new settings also apply to all of Liberator’s [HTTPS connections](../liberator/liberator-configure-how-liberator-handles-https-connections.md) and [Direct secure connections](../liberator/liberator-configure-how-liberator-handles-direct-client-connections.md), as well as to secure connections between with its peers.

## Setting strong encryption (encryption key length)

To ensure adequate security In a production deployment, the encryption keys you use (as defined in the certificates) must be at least 128 bits long.

Additionally, make sure that the list of SSL ciphers (cryptographic algorithms) available to your DataSource application includes ciphers that support keys of 128 bits or more. In C-based DataSource applications, the ciphers are selected from the set available in the version of [OpenSSL](https://www.openssl.org/) built into the application, and In Java-based DataSource applications they’re selected from the set provided with Java (see the Java Cryptography Architecture Oracle Providers Documentation for the version of Java used by your application). You specify the set of ciphers to use through the DataSource configuration item [`datasrc-ssl-cipherlist`](datasource-datasource-secure-sockets-layer-ssl-configuration.md#datasrc-ssl-cipherlist).

For C-based DataSource applications, we recommend you define `datasrc-ssl-cipherlist` as follows:

```
datasrc-ssl-cipherlist HIGH+TLSv1
```

This configuration setting ensures that _Windows-based_ C DataSource applications can use encryption keys of least 128 bits. Linux-based C DataSource applications can use just the value `HIGH`, but `HIGH+TLSV1` amounts to the same thing on LInux, so you can use the above configuration in both Windows and Linux environments.

**⚠️ WARNING**\
In C-based Datasource applications running under Windows, the configuration setting `https-cipher-list HIGH` _won’t_ provide 128 bit encryption capability.

**📌 NOTE**\
For more information about the SSL cipher list for OpenSSL 1.0.2, see the `OpenSSL ciphers(1)` manual page, which includes a list of the available cipher suite names.

---

**See also:**

* Reference: [DataSource Secure Sockets Layer (SSL) configuration](datasource-datasource-secure-sockets-layer-ssl-configuration.md)
* Reference: [DataSource peers configuration](datasource-datasource-peers-configuration-part-1.md)
* [DataSource configuration reference: Introduction](datasource-datasource-configuration-reference-introduction.md)
* How can I... [Configure how Liberator handles HTTPS connections](../liberator/liberator-configure-how-liberator-handles-https-connections.md)
* How can I... [Configure how Liberator handles direct client connections](../liberator/liberator-configure-how-liberator-handles-direct-client-connections.md)
