Transport Layer Security for TimesTen Replication

When you use TimesTen replication in TimesTen Classic, you can optionally configure and use Transport Layer Security (TLS) for secure, encrypted network communication between replication agents or between TimesTen utilities (such as ttRepAdmin) and replication agents. Mutual authentication is used for all connections.

TimesTen supports these cipher suites:

SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
SSL_RSA_WITH_AES_128_CBC_SHA256

SSL_RSA_WITH_AES_128_CBC_SHA256 may be needed to decode CA-provided certificates but should not be used for network traffic.

These are the main steps for using TLS with TimesTen replication:

Task 1: Generate Certificates for Replication

You can create certificates for replication with the ttInstanceCreate utility when you create a TimesTen instance, or by using the ttCreateCerts utility directly.

Using ttInstanceCreate would be essentially the same as shown earlier in this chapter for client/server, in Task 1: Generate Certificates and Set TLS Attributes with ttInstanceCreate. Note that ttInstanceCreate uses the ttCreateCerts utility to generate certificates. Or see ttCreateCerts in the Oracle TimesTen In-Memory Database Reference for information about ttCreateCerts syntax, options, and usage in order to use it directly.

If you will be using certificates for both replication and client/server, it is preferable to use separate certificates for the two features. You can use the ttCreateCerts utility to generate additional certificates as needed.

Note the following regarding certificates generated by TimesTen:

Certificates produced are self-signed and stored in an Oracle Wallet.
Because the certificates are self-signed, they cannot be revoked. But certificates can be regenerated as needed.
The root CA has a default expiration time. It is the user’s responsibility to track this. When the root CA expires, all certificates must be regenerated. When the root CA is regenerated, it must be copied to each TimesTen instance.
Instances will store the root certificate (the public key) in a local wallet.
Wallets produced are auto-login or single-sign-on (SSO) wallets, without a password. Access to wallets is controlled by file system permissions.
The wallets are platform-independent.

TimesTen uses Oracle Wallets to store certificates. For general information about these wallets, also referred to as "keystores", refer to How the Keystore for the Storage of TDE Master Encryption Keys Works in Oracle Database Advanced Security Guide.

Task 2: Copy Certificates for Replication

After you generate certificates for replication, copy them to the other TimesTen instances. Recall the resulting wallets from the example in ttCreateCerts in the Oracle TimesTen In-Memory Database Reference.

% ls timesten_home/conf/wallets
client1.cert  clientWallet  root.cert  rootWallet  server1.cert  serverWallet
% ls timesten_home/conf/wallets/serverWallet
cwallet.sso

For TLS for replication, only serverWallet is used. Copy the serverWallet directory, which includes the root certificate, to the desired location. This is preferably the same location on each TimesTen instance.

On each instance:

% mkdir timesten_home/conf/wallets
[...Copy serverWallet from the instance where it was created...]
% cd timesten_home/conf/wallets
% ls
serverWallet
% ls serverWallet
cwallet.sso

Task 3: Configure TLS for Replication

To use TLS for replication, set TLS attributes in the timesten.conf file on each TimesTen instance. The settings are read on each instance by the replication agent and by utilities that may communicate with the agent.

Tip:

Generate and copy certificates before you configure TLS for replication. Otherwise, configuration may trigger an error condition where replication agents start up and try to access certificates that do not exist yet.

replication_cipher_suite: This lists the cipher suite or suites that can be used, depending also on the client setting. Specify the desired cipher suites, comma-separated and in order of preference. See Transport Layer Security for TimesTen Replication for the list of supported cipher suites. This setting is required. There is no default.
replication_wallet: Specify the path to the wallet directory—the directory where you placed the certificates that you generated. This setting is required. There is no default location. It is suggested, but not required, to use the same location and directory name on each TimesTen instance. (In the example in the preceding section, Task 2: Copy Certificates for Replication, this would be timesten_home/conf/wallets/serverWallet.)
replication_ssl_mandatory: Specifies whether it is mandatory to have consistent TLS configuration between TimesTen instances—specifically, whether TLS is configured through replication_cipher_suite and replication_wallet settings, and what cipher suite is specified. If there is a mismatch between the current instance and the replication peer, then TimesTen behavior is determined as follows:
- On an instance with a setting of replication_ssl_mandatory=0 (not mandatory, the default), replication proceeds between that instance and the replication peer, but TLS is not used for communications between the replication agents as long as the settings are inconsistent. Use this setting for an online switchover to TLS.
- On an instance with a setting of replication_ssl_mandatory=1 (mandatory), replication cannot proceed between this instance and the replication peer until the settings are made consistent. Use this setting for an offline switchover to TLS.

Note:

For these configuration changes to take effect on any given instance, you must restart the replication agent. (It is not necessary to restart the TimesTen daemon.)
If the replication_cipher_suite value is invalid or the suite is not supported by TimesTen, an error is reported and replication cannot function until the problem is resolved.
If replication_cipher_suite is set but replication_wallet is not, or no certificates are found in the specified location, an error is reported and replication cannot function until the problem is resolved.

Task 4: Activate TLS for Replication

Once TLS is configured on all TimesTen instances, with certificates located in the specified replication_wallet directories and the desired cipher suite specified in the replication_cipher_suite settings, restarting the replication agents will activate TLS, resulting in it being used for communication to and from the replication agents.

There are two ways to activate TLS:

Switch Online to TLS for Replication

If you have an existing replication scheme that is not using TLS, you can perform an online switchover to TLS by restarting the replication agents one at a time as replication continues to function.

On each instance, confirm replication_wallet is set to indicate where the certificates are located. (In the example in Task 2: Copy Certificates for Replication, this would be timesten_home/conf/wallets/serverWallet.)
On each instance, confirm replication_cipher_suite is set to indicate the cipher suite you are using.
On each instance, confirm replication_ssl_mandatory=0. This allows you to update the TimesTen instances to start using TLS one at a time.
On each instance (one at a time, in succession), stop and restart the replication agent:
```
% ttAdmin -repStop DSN
% ttAdmin -repStart DSN
```

For example, assume the following:

There is an active standby pair with databases rep1 on host1 and rep2 on host2, with subscriber rep3 on host3.
Certificates were generated on rep1 and placed in /swdir/mywalletloc, then copied to the same location on rep2 and rep3.

Complete these steps, as replication continues to function, to use TLS for communications to and from each of the replication agents:

Use these TLS settings in the timesten.conf file on each instance:

replication_wallet=/swdir/mywalletloc
replication_cipher_suite=SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
replication_ssl_mandatory=0

Restart the replication agent on each instance, one at a time.

On host1:

% ttAdmin -repStop rep1
% ttAdmin -repStart repl

On host2:

% ttAdmin -repStop rep2
% ttAdmin -repStart rep2

On host3:

% ttAdmin -repStop rep3
% ttAdmin -repStart rep3

Switch All Instances Simultaneously to TLS for Replication (Offline)

If you want TLS to start and be enforced on all instances immediately and simultaneously, you must shut down all replication agents, stopping replication, before setting replication_ssl_mandatory=1 on each instance.

On all instances, stop the replication agent:
```
% ttAdmin -repStop DSN
```
Note:

If you are using Oracle Clusterware, you can accomplish this for all instances with a single command using the ttCWAdmin utility from any instance in the cluster:
```
% ttCWAdmin -stop -dsn DSN
```
On all instances, confirm replication_wallet is set to indicate where the certificates are located.
On all instances, confirm replication_cipher_suite is set to indicate the cipher suite you are using.
On all instances, confirm replication_ssl_mandatory=1.

This requires all replication agents to be shut down at once, and all timesten.conf files to be updated while all the replication agents are down.
On all instances, restart the replication agent:
```
% ttAdmin -repStart DSN
```
Note:

If you are using Oracle Clusterware, you can accomplish this for all instances with a single command using the ttCWAdmin utility from any instance in the cluster:
```
%  ttCWAdmin -start -dsn DSN
```

Task 5: Check Operation of TLS for Replication

The ttRepAdmin utility -showstatus -detail option indicates whether the replication agent transmitters and receivers are using TLS (indicated as "SSL").

For example:

TRANSMITTER thread(s) (TRANSMITTER(M):140427924887296):
For                     : REP1 (track 0) (SSL)
   Start/Restart count   : 1
   Current state         : STATE_META_PEER_INFO

RECEIVER thread(s) (RECEIVER:140427327059712):
For                     : REP1 (track 0) (SSL)
   Start/Restart count   : 1
   Current state         : STATE_RCVR_READ_NETWORK_LOOP
   Current DB context    : 0x7fb7bc4a41e0

See ttRepAdmin in Oracle TimesTen In-Memory Database Reference.

Note:

In order for you to see this output, the replication agents on the master and subscribing systems must be running and connected to each other.