This chapter discusses the use of encryption in TimesTen.
Some features in TimesTen, such as Client/Server and replication, support use of Transport Layer Security (TLS) for communication between TimesTen instances.
These topics are discussed here:
Notes:
In TimesTen Release 18.1, TLS is not supported in TimesTen Scaleout.
TimesTen uses TLS version 1.2.
TLS configuration in TimesTen does not apply to communication between TimesTen and Oracle Database, such as when TimesTen Cache is used. For encrypted TimesTen-Oracle communication, configure TLS through settings in the sqlnet.ora
file used for connections to Oracle Database. Refer to "Configuring Secure Sockets Layer Authentication" in Oracle Database Security Guide.
This section describes the use of certificates for TLS for TimesTen, covering these topics:
TimesTen Client/Server and replication support use of Transport Layer Security for communication between TimesTen instances. TimesTen provides the ttCreateCerts
utility to generate certificates for TLS for TimesTen.
The procedure shown in "Using ttCreateCerts" results in the TimesTen server having its own self-signed root certificate; however, this does not preclude using a certificate signed by a third party commercial certificate authority. TimesTen supports both self-signed and CA-signed certificates. Certificates produced by ttCreateCerts
are self-signed. The wallets are platform-independent.
The wallet of each TimesTen server must have its own public/private key identity signed by the root certificate. Each client that connects to a TimesTen server must have a wallet containing the root certificate of that server. (A client may optionally have multiple wallets for connections to multiple database services.) By default, TimesTen uses TLS server authentication, so that the client can verify that the server it is connecting to is valid.
The server uses the existing TimesTen user ID and password mechanism to authenticate a user, but TimesTen also supports a form of client authentication where the server validates an identity in the client wallet. This is a way for the server to verify that the connecting client is a legitimate TimesTen client, but the user still must provide user ID and password credentials.
The wallet is an auto-login or single-sign-on (SSO) wallet, without a password. Access to the wallet is controlled by file system permissions.
TimesTen supports NSA Suite B cipher suites SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
and SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
. See "Configuring Secure Sockets Layer Authentication" in Oracle Database Security Guide for information about these cipher suites.
The following sections describe the TimesTen ttCreateCerts
utility and show how to use it to create certificates. The certificates can be used with TLS for either TimesTen Client/Server or TimesTen replication.
The ttCreateCerts
utility is located in the bin
directory of a TimesTen instance. You must set TIMESTEN_HOME
before you run ttCreateCerts
, which you can accomplish by sourcing the ttenv.sh
or ttenv.csh
script from the bin
directory.
The utility creates three Oracle Wallets: rootWallet
, clientWallet
, and serverWallet
.
Note:
You must have Java on your system to usettCreateCerts
. The utility searches for it according to the JRE_HOME
, JAVA_HOME
, and PATH
settings.This is the syntax for ttCreateCerts
:
% ttCreateCerts -h usage: ttCreateCerts [-dir WALLETDIR] [options...] ttCreateCerts [-h | -help] ttCreateCerts [-V | -version] options: -f | -force -verbose -validity DAYS | -valid_from mm/dd/yyyy -valid_until mm/dd/yyyy -dryrun -sign_alg ALGORITHM (ecdsasha256 ecdsasha384 ecdsasha512) -eccurve TYPE (p256 p384 p521)
Input and option descriptions:
-dir
: Specifies a directory where the wallets are placed, as an absolute path. The specified directory must already exist and cannot already contain wallets produced by ttCreateCerts
, unless you use the -force
option. The default is timesten_home
/conf
.
-h
or -help
: Shows help (showing the above syntax).
-V
or -version
: Displays the TimesTen release number.
-f
or -force
: Overwrites any previous wallets in the specified directory.
-verbose
: Shows additional output from execution of the utility.
-validity
: One of two ways to specify the lifetime of the wallets that are created, expressed as a number of days from creation. The default is 3650 days, which can be overridden by setting either -validity
or -valid_from
and -valid_until
.
-valid_from
and -valid_until
: The other way to specify the lifetime of the wallets that are created, expressed as a start and an end date in mm/dd/yyyy format.
-dryrun
: Echoes all the commands to be executed by ttCreateCerts
to create the certificates as you specified, but without executing them. For options you do not set, you can use this to confirm what the default values are.
-sign_alg
: Specifies the elliptical curve signing algorithm. Supported algorithms are ecdsasha256
, ecdsasha384
(default), and ecdsasha512
.
-eccurve
: Specifies the size of the elliptical curve. Supported values are p256
, p384
(default), and p521
.
This section provides ttCreateCerts
examples that place the wallets in a wallets
subdirectory under timesten_home
/conf
, where timesten_home
is the full path to the TimesTen instance home directory.
The following example includes verbose output. (Without the -verbose
option, only the last line is shown.)
% ttCreateCerts -verbose -dir timesten_home/conf/wallets Requested Certificates: User Certificates: Subject: CN=server1,C=US Trusted Certificates: Subject: CN=ecRoot,C=US Requested Certificates: User Certificates: Subject: CN=client1,C=US Trusted Certificates: Subject: CN=ecRoot,C=US ttCreateCerts : certificates created in timesten_home/conf/wallets
Here are the results:
% ls timesten_home/conf/wallets client1.cert clientWallet root.cert rootWallet server1.cert serverWallet % ls timesten_home/conf/wallets/clientWallet cwallet.sso % ls timesten_home/conf/wallets/rootWallet cwallet.sso % ls timesten_home/conf/wallets/serverWallet cwallet.sso
Note:
Any.lck
files can be ignored.See "Certificates for TimesTen Client/Server" and "Certificates for TimesTen replication" for where to copy certificates for TimesTen Client/Server and replication.
The next example is a dry run. No certificates are created (despite the last line). This shows only a snippet of the output:
% ttCreateCerts -dir timesten_home/conf/wallets -dryrun ... + /bin/java -Djava.security.egd=file:///dev/./urandom -Xms64m -Xmx512m -cp /scratch/classic181430/instances/tt181/install/lib/cryptoj_5_0.jar: /scratch/classic181430/instances/tt181/install/lib/oraclepki.jar: /scratch/classic181430/instances/tt181/install/lib/osdt_cert.jar: /scratch/classic181430/instances/tt181/install/lib/osdt_core.jar oracle.security.pki.textui.OraclePKITextUI wallet add -wallet rootWallet -dn CN=ecRoot,C=US -sign_alg ecdsasha384 -self_signed -asym_alg ECC -eccurve p384 -jsafe -validity 3650 -auto_login_only -nologo ... ttCreateCerts : certificates created in timesten_home/conf/wallets
From this, you can see that the default settings are -sign_alg ecdsasha384
, -eccurve p384
, and -validity 3650
(days).
Here is another example that sets signing algorithm and size of the elliptical curve:
% ttCreateCerts -dir timesten_home/conf/wallets -sign_alg ecdsasha256 -eccurve p256 ttCreateCerts : certificates created in timesten_home/conf/wallets
This example specifies that the certificates will expire one year from when they were created:
% ttCreateCerts -dir timesten_home/conf/wallets -validity 365 ttCreateCerts : certificates created in timesten_home/conf/wallets
Or, equivalently:
% ttCreateCerts -dir timesten_home/conf/wallets -valid_from 10/28/2020 -valid_until 10/28/2021 ttCreateCerts : certificates created in timesten_home/conf/wallets
The next example tries to create wallets in a location where wallets already exist:
% ttCreateCerts -dir timesten_home/conf/wallets
ttCreateCerts: rootWallet is not empty, use -force to overwrite
This example tries again, using the -force
option:
% ttCreateCerts -dir timesten_home/conf/wallets -f ttCreateCerts : certificates created in timesten_home/conf/wallets
When you use TimesTen Client/Server, you can optionally configure and use TLS for encrypted communication between the TimesTen client (or clients) and TimesTen server. This feature is supported with TimesTen release 18.1.2.1.0 and higher.
This section discusses TimesTen support for TLS for Client/Server, covering these topics:
Note:
Using a server or client prior to TimesTen release 18.1.2.1.0 results in the connection being unencrypted, unless encryption is specified as required at the other end, in which case the connection will fail.This feature enables secure TCP/IP network connections, using TLS, between TimesTen clients and servers. The certificates for a TLS session are contained in an Oracle Wallet. Without enabling this feature, and in earlier TimesTen releases, network communication is unencrypted.
These are the high-level steps to use TLS for Client/Server:
Create certificates on the TimesTen server, placing them in a desired wallet directory.
Copy the wallet directory to the TimesTen clients.
Configure TLS on the server and on the clients, as appropriate, including specifying the wallet directory and cipher suite.
Confirm operation of TLS communication. (TLS is used as soon as the configuration is complete.)
This section discusses where to copy the certificates you generated for TimesTen Client/Server. Recall the resulting wallets from the example in "Using ttCreateCerts":
% ls timesten_home/conf/wallets client1.cert clientWallet root.cert rootWallet server1.cert serverWallet % ls timesten_home/conf/wallets/clientWallet cwallet.sso % ls timesten_home/conf/wallets/rootWallet cwallet.sso % ls timesten_home/conf/wallets/serverWallet cwallet.sso
For use of TLS for Client/Server, ignore client1.cert
, root.cert
, rootWallet
, server1.cert
, and serverWallet
. Copy the clientWallet
directory, which includes the root certificate, to the desired location. This is preferably the same location on each TimesTen client instance.
On each client:
% mkdir timesten_home/conf/wallets [...Copy clientWallet from the server...] % cd timesten_home/conf/wallets % ls clientWallet % ls clientWallet cwallet.sso
Note:
Be careful to preserve the file and directory permissions of the wallet.There is both server-side and the client-side configuration for TLS for Client/Server.
These server-side attributes for TLS for Client/Server can be set in the server DSN definition in timesten_home
/conf/sys.odbc.ini
, where timesten_home
is the TimesTen instance directory.
Wallet
: Specify the wallet location, as an absolute path, where you placed the certificates that you generated (preferably the same directory path as on the client). There is no default location. If you used ttCreateCerts
, this is the full path of the serverWallet
directory.
Encryption
: Use one of these settings. These descriptions assume matching cipher suite settings between the server and client, where applicable.
accepted
: Enable an encrypted session if required or requested by the client; use an unencrypted session otherwise. This is the default.
rejected
: Demand an unencrypted session. (If the server does not support encryption, TimesTen behaves as if this is the setting on the server.) The connection is rejected if the client requires encryption.
requested
: Request an encrypted session if the client allows it (if the client has any setting other than rejected
); use an unencrypted session otherwise.
required
: Demand an encrypted session. Reject the connection if the client rejects encryption.
See Table 3-1 for a summary of the results of each possible combination of settings of this attribute between the server and client, with consideration of the cipher suite settings.
CipherSuites
: This lists the cipher suite or suites that can be used, depending also on the client setting. Specify SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
, SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
, or both, comma-separated and in order of preference. There is no default setting. For TLS to be used, the server and client settings must include at least one common suite.
SSLClientAuthentication
: Specifies whether TLS client authentication is required (setting of 1) or not (setting of 0, the default). With client authentication, the server validates an identity presented by the client, and requires an identity (public/private key) in the client wallet. Note that regardless of the client authentication setting, server authentication is performed, where the client validates the server.
The server and client must have the same SSLClientAuthentication
setting.
Note:
As an alternative to the preceding attributes insys.odbc.ini
, you can set these equivalent attributes in the TimesTen configuration file, timesten_home
/conf/timesten.conf
:
server_wallet
server_encryption
server_cipher_suites
ssl_client_authentication
If you have more than one database in a TimesTen instance, these settings apply to all, but can be overridden for each database through the server DSN definition.
TimesTen also supports TLS session renegotiation, where new session keys are generated during an active TLS session for more robust security. Session renegotiations are performed according to either how much data has been transferred or how much time has passed. If you want to enable this feature, use one these attributes in the server DSN definition:
SSLRenegotiationSize
: Specifies a number of megabytes of data transfer in either direction between the client and server, after which session renegotiation is performed. The default setting is 0, meaning do not renegotiate based on megabytes transferred.
SSLRenegotiationPeriod
: Specifies a period of time, in minutes, after which session renegotiation is performed. The default setting is 0, meaning do not renegotiate based on a time period.
If both attributes are set to nonzero values, whichever situation occurs first will result in renegotiation.
Table 3-1 shows the results of all possible combinations of encryption settings between client and server, with consideration of the cipher suite settings.
Table 3-1 Results of combinations of server and client encryption settings
Server encryption setting | Client encryption setting | Result |
---|---|---|
|
|
Connection accepted, encryption off. |
|
|
Connection accepted, encryption off. |
|
|
Connection accepted. Encryption on if there is overlap between the cipher suite settings, off if there is not. |
|
|
Connection accepted with encryption on if there is overlap between cipher suite settings. Connection rejected if there is not. |
|
|
Connection accepted, encryption off. |
|
|
Connection accepted, encryption off. |
|
|
Connection accepted, encryption off. |
|
|
Connection rejected. |
|
|
Connection accepted. Encryption on if there is overlap between the cipher suite settings, off if there is not. |
|
|
Connection accepted, encryption off. |
|
|
Connection accepted. Encryption on if there is overlap between the cipher suite settings, off if there is not. |
|
|
Connection accepted with encryption on if there is overlap between cipher suite settings. Connection rejected if there is not. |
|
|
Connection accepted with encryption on if there is overlap between cipher suite settings. Connection rejected if there is not. |
|
|
Connection rejected. |
|
|
Connection accepted with encryption on if there is overlap between cipher suite settings. Connection rejected if there is not. |
|
|
Connection accepted with encryption on if there is overlap between cipher suite settings. Connection rejected if there is not. |
Note:
If automatic client failover is enabled and a failover occurs, encryption attribute settings from the original connection will continue to be used. The failover server must have the same encryption settings as the original server.These client-side attributes for TLS for Client/Server can be set in the client DSN definition in timesten_home
/conf/sys.odbc.ini
or a client odbc.ini
file, or in a connect string.
Note:
If an attribute is set in both the client DSN definition and the connect string, the connect string setting takes precedence.Wallet
: Specify the wallet directory, as an absolute path, where you placed the certificates that you generated (preferably the same directory path as on the server). There is no default location. If you used ttCreateCerts
, this is the full path of the clientWallet
directory.
Encryption
: Use one of these settings. These descriptions assume matching cipher suite settings between the server and client, where applicable.
accepted
: Enable an encrypted session if required or requested by the server; use an unencrypted session otherwise. This is the default.
rejected
: Demand an unencrypted session. (If the client does not support encryption, TimesTen behaves as if this is the setting on the client.) The connection is rejected if the server requires encryption.
requested
: Request an encrypted session if the server allows it (if the server has any setting other than rejected
); use an unencrypted session otherwise.
required
: Demand an encrypted session. The connection is rejected if the server rejects encryption.
See Table 3-1 for a summary of the results of each possible combination of settings of this attribute between the server and client, with consideration of the cipher suite settings.
CipherSuites
: This lists the cipher suite or suites that can be used, depending also on the server setting. Specify SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
, SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
, or both, comma-separated and in order of preference. There is no default setting. For TLS to be used, the server and client settings must include at least one common suite.
SSLClientAuthentication
: Specifies whether TLS client authentication is required (setting of 1) or not (setting of 0, the default). With client authentication, the server validates an identity presented by the client, and requires an identity (public/private key) in the client wallet. Note that regardless of the client authentication setting, server authentication is performed, where the client validates the server.
The server and client must have the same SSLClientAuthentication
setting.
Note:
As an alternative to some of the preceding attributes insys.odbc.ini
or client odbc.ini
, you can set these equivalent attributes in the TimesTen configuration file, timesten_home
/conf/timesten.conf
:
client_wallet
client_cipher_suites
If you have more than one client DSN in a TimesTen instance, these settings apply to all, but can be overridden for each client through the client DSN definition.
If TLS is configured on both the server and the client with sufficiently matching settings of Encryption
and CipherSuite
, as described in Table 3-1, TLS is used as soon as the connection is established. You can confirm this by calling sqlgetconnectattr tt_tls_session
from ttIsqlCS
on the client. A return value of 1 indicates TLS is being used.
Example 3-1 shows the results of several combinations of encryption settings on the server and client.
Example 3-1 Connecting with TLS
Scenario 1: Encryption is requested on the server and on the client with the same cipher suite settings. The connection is successful and TLS is used.
Server DSN definition:
[sampledb] Driver=timesten_home/install/lib/libtten.so DataStore=/db/databases/sampledb PermSize=512 TempSize=128 LogBufMB=256 LogFileSize=256 LogDir=/db/logs DatabaseCharacterSet=AL32UTF8 OracleNetServiceName=ttorcl Wallet=timesten_home/conf/mywallets/serverWallet Encryption=requested CipherSuites=SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Client DSN definition:
[sampledbCS]
TTC_SERVER=myserverhost.example.com
TTC_SERVER_DSN=sampledb
UID=myuser
PWD=welcome
Wallet=timesten_home/conf/mywallets/clientWallet
Encryption=requested
CipherSuites=SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Connect, executing ttIsqlCS
from the timesten_home
/bin
directory (output formatted for readability):
% ttIsqlCS sampledbCS Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=sampledbCS"; Connection successful: DSN=sampledbCS;TTC_SERVER=myserverhost.example.com; TTC_SERVER_DSN=sampledb;UID=myuser;DATASTORE=/db/databases/sampledb; DATABASECHARACTERSET=AL32UTF8;CONNECTIONCHARACTERSET=US7ASCII;LOGFILESIZE=256; LOGBUFMB=256;LOGDIR=/db/logs;PERMSIZE=512;TEMPSIZE=128; ORACLENETSERVICENAME=ttorcl;(SERVER)ENCRYPTION=Requested; (SERVER)WALLET=file:timesten_home/conf/mywallets/serverWallet; (client)Encryption=Requested; (client)Wallet=/timesten_home/conf/mywallets/clientWallet; (client)CipherSuites=SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384; (Default setting AutoCommit=1)
Confirm TLS is enabled:
Command> sqlgetconnectattr tt_tls_session; TT_TLS_SESSION = 1 (SQL_TRUE)
Scenario 2: Encryption is requested on the server and on the client but with mismatched cipher suite settings. The connection is successful but a warning message indicates that TLS is not used. (Except for what is shown here, settings are the same as in Scenario 1.)
From the server DSN definition:
CipherSuites=SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
From the client DSN definition:
CipherSuites=SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Connect:
% ttIsqlCS sampledbCS Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=sampledbCS"; Warning 01000: Unable to create requested TLS session; unencrypted session created. Check Wallet and CipherSuites on client and server. SSL error: SSL Fatal Alert Connection successful: ...
Scenario 3: Encryption is accepted on the server and on the client. This is not sufficient to result in TLS usage, as noted in Table 3-1. The connection is successful but TLS is not used. (Except for what is shown here, settings are the same as in Scenario 1.)
From the server DSN definition:
Encryption=accepted
From the client DSN definition:
Encryption=accepted
Connect:
% ttIsqlCS sampledbCS Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=sampledbCS"; Connection successful: ... Command> sqlgetconnectattr tt_tls_session; TT_TLS_SESSION = 0 (SQL_FALSE)
Scenario 4: Encryption is required on the client but rejected on the server. The connection attempt is unsuccessful. (Except for what is shown here, settings are the same as in Scenario 1.)
From the server DSN definition:
Encryption=rejected
From the client DSN definition:
Encryption=required
Attempt to connect:
% ttIsqlCS sampledbCS Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=sampledbCS"; HY000: Connection rejected: inconsistent encryption attributes The command failed. Done.
When you use TimesTen replication, you can optionally configure and use Transport Layer Security (TLS) for secure network communication to and from TimesTen replication agents.
This section discusses TimesTen support for TLS for replication, covering these topics:
This feature enables secure TCP/IP network connections, using TLS, for TimesTen replication agents. Mutual authentication is used for all connections. This applies to communications between TimesTen instances, either between replication agents or between TimesTen utilities (such as ttRepAdmin
) and replication agents. Without enabling this feature, and in earlier TimesTen releases, such communications are unencrypted.
These are the high-level steps to use TLS for replication:
Create certificates on one of the TimesTen instances, placing them in a desired wallet directory.
Copy the contents of the wallet directory to the other TimesTen instances.
Configure TLS in TimesTen, specifying the wallet directory and cipher suite.
Enable TLS communications (restart the replication agents to begin using TLS).
This section discusses where to copy the certificates you generated for TimesTen replication. Recall the resulting wallets from the example in "Generation of certificates for TimesTen":
% ls timesten_home/conf/wallets client1.cert clientWallet root.cert rootWallet server1.cert serverWallet % ls timesten_home/conf/wallets/clientWallet cwallet.sso % ls timesten_home/conf/wallets/rootWallet cwallet.sso % ls timesten_home/conf/wallets/serverWallet cwallet.sso
For use of TLS for replication, ignore client1.cert
, clientWallet
, root.cert
, rootWallet
, and server1.cert
. 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
To use TLS for replication, set these 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:
Important:
Generate and place certificates first. If you configure TLS for replication before you generate and place the certificates, and replication agents restart in between, there will be an error condition when replication agents try to access non-existent certificates.replication_cipher_suite
: The cipher suite to be used in encrypting communications to and from the replication agent. This setting is required. There is no default.
TimesTen supports NSA Suite B cipher suites SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
and SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
. These suites require elliptical signing.
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.
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 this instance and the replication peer, but TLS is not used for communications between the replication agents. Use this setting to ease the transition to TLS, if secure communication is not critical (at least initially).
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.
Notes:
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.
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 result in TLS being used for communication to and from the replication agents.
There are two ways to accomplish this:
Enable TLS for replication online. Restart the replication agents one at a time as replication continues to function.
Or:
Enable TLS for replication simultaneously on all instances, stopping replication until you restart all the replication agents at once.
Note:
This assumes consistent settings between instances or is subject toreplication_ssl_mandatory
settings, as discussed in "Configuration for TLS for replication".This section covers these topics:
If you have an existing replication scheme that is not using TLS, use these steps for an online switchover to TLS as replication continues to function:
Generate certificates as discussed in "Generation of certificates for TimesTen", then copy them to the desired location on each TimesTen instance as discussed in "Certificates for TimesTen replication".
On each instance, set replication_wallet
to indicate where the certificates are located.
On each instance, set replication_cipher_suite
to indicate the cipher suite you are using.
On each instance, set 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 there is an active standby pair with databases rep1
on host1
and rep2
on host2
, with subscriber rep3
on host3
. Complete these steps, as replication continues to function, to use TLS for communications to and from each of the replication agents:
Create the certificates on rep1
and place them in the desired wallet directory: /swdir/mywalletloc
for example.
Copy the wallet directory to the appropriate location (preferably the same location) on rep2
and rep3
.
Configure TLS on all three instances. For example, in each timesten.conf
file:
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
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.
Generate certificates as discussed in "Generation of certificates for TimesTen", then copy them to the desired location on each TimesTen instance as discussed in "Certificates for TimesTen replication".
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 thettCWAdmin
utility from any instance in the cluster:
% ttCWAdmin -stop -dsn DSN
On all instances, set replication_wallet
to indicate where the certificates are located.
On all instances, set replication_cipher_suite
to indicate the cipher suite you are using.
On all instances, set 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 thettCWAdmin
utility from any instance in the cluster:
% ttCWAdmin -start -dsn DSN
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 for information about this utility.
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.