Transport Layer Security for the TimesTen Daemon

For requests received by the TimesTen main daemon over TCP, you can optionally configure Transport Layer Security (TLS) for secure, encrypted network communication. This includes supported requests from remote hosts and supported requests over the local loopback interface. TLS connections use mutual authentication: the main daemon and the connecting client authenticate each other by using certificates stored in secure Oracle Wallets.

The main daemon performs security negotiation after accepting a TCP connection and before processing the request. This configuration applies only to TCP connections to the main daemon. It does not apply to requests transported over a UNIX domain socket (UDS). TLS for TimesTen client/server and TLS for replication are configured separately.

Note:

TLS protects the TCP transport; it does not change which main-daemon requests are permitted over that transport. After TLS negotiation, the main daemon continues to enforce the existing restrictions for the request and its point of origin. Enabling TLS does not make a UDS-only request available over TCP, and it does not make a loopback-only TCP request available to a remote host.

Because TLS negotiation occurs before request processing, a TCP client must satisfy the configured TLS policy before the main daemon determines whether the requested operation is permitted. A successful TLS handshake does not prevent the main daemon from subsequently rejecting a request because of its transport or point of origin.

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

Task 1: Generate Certificates for the Main Daemon

You can create certificates for TCP requests to the TimesTen main daemon 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 2A: Create Self-Signed Certificates. 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.

Note:

When you generate certificates for an environment that uses FIPS mode, specify the intended mode. Create the destination directory before you run ttCreateCerts. For example, these commands explicitly select FIPS 140-3: 

% mkdir -p timesten_home/conf/daemonWallets 
% ttCreateCerts -dir timesten_home/conf/daemonWallets -fips140_mode 3

Omitting the option uses non-FIPS mode for certificate generation.

If you will be using certificates for not only the main daemon but also replication and client/server, it is preferable to use separate certificates for the three 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 the Main Daemon

After you generate certificates for TCP requests to the TimesTen main daemon, copy them to the other TimesTen instances that may perform remote TCP requests to the main daemon, such as client instances or replication peers. Recall the resulting wallets from the example in ttCreateCerts in the Oracle TimesTen In-Memory Database Reference. 
% ls timesten_home/conf/daemonWallets
client1.cert  clientWallet  root.cert  rootWallet  server1.cert  serverWallet
% ls timesten_home/conf/daemonWallets/serverWallet
cwallet.sso

For TLS for the main daemon, 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.

Note:

The wallet directory does not need to have the same path on every TimesTen instance. For example, replication peers can store copies of the same serverWallet directory at different paths. Set daemon_wallet on each instance to the path of its local copy.

On each instance:

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

Task 3: Configure TLS for the Main Daemon

To use TLS for the TimesTen main daemon, set the corresponding TLS attributes in the timesten.conf file on each TimesTen instance whose main daemon accepts TCP connections that you want to protect.

  • daemon_cipher_suite: Specifies the encryption cipher configuration for TLS connections to the main daemon. Specify the desired cipher suites, comma-separated. See Cipher Suites in TimesTen for the list of supported cipher suites for TLS 1.3 and 1.2. This setting is required. There is no default.

  • daemon_wallet: Specifies the path to the secure Oracle Wallet containing the certificates and private key used for mutual authentication. This setting is required. There is no default location. It is recommended, but not required, to use the same location and directory name on every participating TimesTen instance. ( (In the example in the preceding section, Task 2: Copy Certificates for the Main Daemon, this would be timesten_home/conf/daemonWallets/serverWallet.)

  • daemon_ssl_mandatory: Specifies whether an incoming TCP connection to the TimesTen main daemon must use TLS.

    • 0 permits TLS or plaintext TCP. This is the default. If the client initiates TLS, the main daemon performs the TLS handshake and mutual certificate authentication. If the client does not initiate TLS, the main daemon processes the request over plaintext TCP.

    • 1 requires TLS. If the client does not initiate TLS, the main daemon rejects the connection with a security error before processing the request.

    If a client initiates TLS but the handshake fails, the main daemon rejects the connection. It does not retry that connection as plaintext.

  • ssl_fips_140: Selects the FIPS mode used by the main daemon for TLS for TCP connections. Specify 0, 1, 2, or 3. The default is 0 (FIPS mode disabled). Mode 1 is the default TimesTen FIPS mode, which is FIPS 140-3; mode 2 explicitly selects FIPS 140-2; and mode 3 explicitly selects FIPS 140-3.

Note:

Setting daemon_wallet and daemon_cipher_suite does not prevent plaintext TCP connections when daemon_ssl_mandatory=0. To require TLS for every TCP connection to the main daemon, set daemon_ssl_mandatory=1.

This example configures TLS for the main daemon with explicit FIPS 140-3 mode: 

daemon_wallet=timesten_home/conf/daemonWallets/serverWallet 
daemon_cipher_suite=TLS_AES_256_GCM_SHA384 
daemon_ssl_mandatory=0 
ssl_fips_140=3

Note:

  • For these configuration changes to take effect on any given instance, you must restart the main daemon.

  • Use daemon_ssl_mandatory=0 only when backward-compatible plaintext TCP connections are intentionally acceptable. Otherwise, use daemon_ssl_mandatory=1.

  • FIPS mode is optional, but if enabled and the main daemon receives TCP requests from other instances, set ssl_fips_140 on every participating instance as well.

See TimesTen Instance Configuration File in Oracle TimesTen In-Memory Database Reference.

Task 4: Activate TLS for the Main Daemon

After the wallet is in place and the TLS attributes are set, restart the TimesTen main daemon to activate the settings. If the instance is managed manually, use the following commands as the instance administrator: 
ttDaemonAdmin -stop

ttDaemonAdmin -start

If the instance is managed by systemd or another service manager, use the applicable service-management commands instead.

You can first allow a transition period, or you can require TLS as soon as the settings are activated.

Introduce TLS Gradually

Use this method while clients (instances) that are permitted to connect over TCP are being configured to initiate TLS.
  1. On each instance, confirm that the TLS attributes are set accordingly:

    • daemon_wallet is set to indicate where the certificates are located.

    • daemon_cipher_suite is set to indicate the cipher suite you are using.

    • daemon_ssl_mandatory is set to 0.

  2. On each instance, stop and restart the TimesTen main daemon:
    ttDaemonAdmin -stop

ttDaemonAdmin -start

During this transition, the receiving main daemon negotiates TLS with clients that initiate it and accepts plaintext from clients that do not.

Require TLS

If you want TLS to start and be enforced on all clients (instances) immediately and simultaneously, you must shut down the TimesTen main daemon for all instances before setting daemon_ssl_mandatory to 1 on each instance.

  1. On all instances, stop the TimesTen main daemon:
    ttDaemonAdmin -stop
  2. On all instances, confirm that the TLS attributes are set accordingly:

    • daemon_wallet is set to indicate where the certificates are located.

    • daemon_cipher_suite is set to indicate the cipher suite you are using.

    • daemon_ssl_mandatory is set to 1.

  3. On all instances, restart the TimesTen main daemon:
    ttDaemonAdmin -start

When daemon_ssl_mandatory=1, a client that does not initiate TLS cannot send a request to the main daemon over TCP. Requests sent over UDS are unaffected.