Transport Layer Security for TimesTen Client/Server

When using a client/server connection, you can optionally configure and use Transport Layer Security (TLS) for encrypted communication between clients and the server.

This section discusses TimesTen support for TLS for client/server, covering these topics:

About Using Certificates with Client/Server

For self-signed certificates, TimesTen provides the ttCreateCerts utility for the generation of certificates for TLS.

TimesTen uses Oracle Wallets to store certificates, which you can use separately after the instance has been created. 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.

Note:

The server validates the client identity using client certificate that is stored in the client wallet. This is a way for the server to verify that the connecting client is a legitimate client, but the user still must provide user ID and password credentials.

In TimesTen:

TimesTen can generate certificates and place them on an instance when it is created.
The TimesTen server has its own self-signed root certificate.
The user typically imports, or optionally copies, the client wallet to each client.

Regarding certificates generated by TimesTen:

Certificates produced are self-signed and stored in an Oracle Wallet.
The root certificate has a default expiration time. It is your responsibility to track this. When the root certificate expires, regenerate all certificates. When the TimesTen regenerates the root certificate, all clients must re-import it.
Clients store the root certificate in a local wallet, that is accessible to the client.
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.
Because the certificates are self-signed, they cannot be revoked. But certificates can be regenerated as needed.

TimesTen also supports the use of certificates signed by a third-party CA. The wallet of each server has its own public/private key identity signed by the root certificate. Each client that connects to a server must have a wallet containing the root certificate of that server. (A client may optionally have multiple wallets for connections to multiple database servers.)

See Task 2A: Create Self-Signed Certificates and Task 2B: Create CA-Signed Certificates for configuration details.

Configuration for TLS for Client/Server

There is both server-side and the client-side configuration for TLS for client/server.

Server Attributes for TLS

These are the server connection attributes that determine settings for TLS for client/server.

For configuration details, see also Task 3: Configure the Server for TLS.

Wallet: Specify the wallet location, as an absolute path, where certificates were placed. Assuming ttCreateCerts was used, this is the full path of the serverWallet directory.
Encryption (encryption flag): Use one of the following 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 4-3 later in this section 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 the desired cipher suites, comma-separated and in order of preference. See Cipher Suites in TimesTen for the list of supported cipher suites for TLS 1.3 and 1.2. For TLS to be used, the server and client settings must include at least one common cipher 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 server connection attributes, these equivalent attributes are available in the instance-level TimesTen configuration file, timesten_home/conf/timesten.conf, on the server. Connection attribute settings take precedence.

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 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.

The following table shows the results of all possible combinations of encryption flag settings between client and server, with consideration of the cipher suite settings.

Table 4-3 Results of Combinations of Server and Client Encryption Settings

Server Encryption Flag Setting	Client Encryption Flag Setting	Result
`accepted`	`accepted`	Connection accepted, encryption off.
`accepted`	`rejected`	Connection accepted, encryption off.
`accepted`	`requested`	Connection accepted. Encryption on if there is overlap between the cipher suite settings, off if there is not.
`accepted`	`required`	Connection accepted with encryption on if there is overlap between cipher suite settings. Connection rejected if there is not.
`rejected`	`accepted`	Connection accepted, encryption off.
`rejected`	`rejected`	Connection accepted, encryption off.
`rejected`	`requested`	Connection accepted, encryption off.
`rejected`	`required`	Connection rejected.
`requested`	`accepted`	Connection accepted. Encryption on if there is overlap between the cipher suite settings, off if there is not.
`requested`	`rejected`	Connection accepted, encryption off.
`requested`	`requested`	Connection accepted. Encryption on if there is overlap between the cipher suite settings, off if there is not.
`requested`	`required`	Connection accepted with encryption on if there is overlap between cipher suite settings. Connection rejected if there is not.
`required`	`accepted`	Connection accepted with encryption on if there is overlap between cipher suite settings. Connection rejected if there is not.
`required`	`rejected`	Connection rejected.
`required`	`requested`	Connection accepted with encryption on if there is overlap between cipher suite settings. Connection rejected if there is not.
`required`	`required`	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. (See Using Automatic Client Failover in Oracle TimesTen In-Memory Database Operations Guide for information about automatic client failover.)

Client Attributes for TLS

These are the client connection attributes to determine settings for TLS for client/server.

For configuration details, see also Task 4: Configure the Client for TLS.

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 certificates were placed. If ttCreateCerts was used, this is the full path of the clientWallet directory.
Encryption (encryption flag): Use one of the following 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 4-3 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 the desired cipher suites, comma-separated and in order of preference. See Cipher Suites in TimesTen for the list of supported cipher suites for TLS 1.3 and 1.2. For TLS to be used, the server and client settings must include at least one common cipher 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 client connection attributes, these equivalent attributes are available in the instance-level TimesTen configuration file, timesten_home/conf/timesten.conf, on the client. Connection attribute settings take precedence.

client_wallet
client_cipher_suites
client_encryption
ssl_client_authentication

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.

Using TLS for Client/Server in TimesTen

This section describes how to configure Transport Layer Security (TLS) for TimesTen client/server communication

Tasks 5 and 6 are optional and are provided as a convenience for exporting and importing client TLS configuration; equivalent results can be achieved by manually configuring the client wallet and DSN.

Task 1: Decide Between Self-Signed Certificates and CA-signed Certificates

With a self-signed certificate, the certificate signs itself. TimesTen components trust the certificate because it is explicitly placed in an Oracle wallet. Trust is established locally and must be configured on each participating system. With a Certificate Authority (CA)-signed certificate, the certificate is signed by a trusted CA. Trust is established through the CA certificate chain stored in an Oracle wallet, allowing TimesTen components to validate certificates issued by that CA according to its trust policies. See About Using Certificates with Client/Server for more information.

Determine whether your deployment requires certificates signed by a trusted CA:

Use self-signed certificates for development or internal environments where manual trust configuration is acceptable.
Use CA-signed certificates for production environments that require integration with an enterprise PKI.

Proceed to Task 2A if you decided to use self-signed certificates, or Task 2B if you decide to use CA-signed certificates.

Task 2A: Create Self-Signed Certificates

To generate self-signed certificates, use the TimesTen instance creation utilities to automatically generate the server and client certificates and store them in Oracle wallets.If you prefer to create CA-signed certificates, go to Task 2B instead.

You can arrange for certificates to be created when you run the ttInstanceCreate utility (from the installation bin directory).

Note:

Certificates generated by ttInstanceCreate can be used for replication as well as for client/server.
You can also use the TimesTen ttCreateCerts utility manually to generate certificates. This is useful, for example, if you need to regenerate certificates for any reason, such as expiration, or if you have multiple databases on a single TimesTen instance and want to use different certificates for each database. See ttCreateCerts in the Oracle TimesTen In-Memory Database Reference .

Set –serverEncryption (the encryption flag) and –serverCipherSuites (the cipher suite or suites to use) on the ttInstanceCreate command line. See Server Attributes for TLS for descriptions of encryption and cipher suites attributes. See Transport Layer Security for TimesTen Client/Server for a list of cipher suites you can use in TimesTen.

This command, to create an instance named tt261, will generate certificates in the instance conf directory, timesten_home/conf.

% installation_dir/bin/ttInstanceCreate -name tt261 -location instances_dir -serverEncryption required -serverCipherSuites TLS_AES_128_CCM_SHA256
Creating instance in instances_dir/tt261 ...
INFO: Creating certificates, this may take some time ...
ttCreateCerts : certificates created in instances_dir/tt221/conf
...
Instance created successfully.

This generates wallets with a root certificate, server certificate, and client certificate and adds the following entries to the instance timesten.conf file (the latter two by default):

server_encryption=required
server_cipher_suites=TLS_AES_128_CCM_SHA256
client_wallet=timesten_home/conf/clientWallet
server_wallet=timesten_home/conf/serverWallet

From the timesten_home/conf directory, what follows shows the serverWallet and clientWallet directories that are created when you run ttInstanceCreate. Each contains a wallet, cwallet.sso. (Ignore the .cert files and rootWallet directory.)

% ls
client1.cert  root.cert   server1.cert  sys.odbc.ini       timesten.conf
clientWallet  rootWallet  serverWallet  sys.ttconnect.ini

Note:

If you want to change the -serverEncryption and -serverCipherSuites settings for the instance at a later time, you can do so using the ttInstanceModify utility, which also has those options. You can copy or move the wallet to a different location and specify the new location of the server wallet using the ttInstanceModify -serverWallet option.

After you have generated certificates, you can list information about them using the -certificateList option of the TimesTen ttAdmin utility, but to use ttAdmin you must specify a database on the command line that is defined in the sys.odbc.ini file in the timesten_home/conf directory.

The utility looks in the timesten_home/conf directory unless the wallets were moved elsewhere, as would be indicated by the Wallet connection attribute in sys.odbc.ini or by server_wallet in the instance-level timesten.conf configuration file.

This example is for a database mydb. Start the TimesTen daemon before you run ttAdmin.

% ttDaemonAdmin -start
TimesTen Daemon (PID: 733500, port: 6624) startup OK.
% ttAdmin -certificateList mydb
NAME                                               HOLDER                  EXPIRATION
timesten_home/conf/serverWallet/cwallet.sso        CN=server1,C=US         Fri Jul 30 23:08:02 UTC 2032

Task 2B: Create CA-Signed Certificates

To use certificates signed by a certificate authority (CA) with TimesTen, you must create and populate a server wallet and a client wallet.If you prefer to create self-signed certificates, go to Task 2A instead.

It is assumed that you have obtained a private key and a certificate request (.csr file), typically using openssl; you have sent the certificate request to a certificate authority (CA); and the CA has returned a signed certificate with signing chain.

Starting with .pem files that contain x509 certificates, concatenate the certificates in order from the certificate provided by the CA to the root. (If your certificates are not in .pem format, use openssl or some other appropriate utility to convert them.) In the discussion in the sections that follow, assume the result is called complete.pem and the private key is in privkey.pem. Then you will package the certificates into a pkcs12 file.

At the end of this process, the server wallet will contain the following:

The entire certificate chain. This consists of the certificate from the CA, the intermediate certificates, and the root certificate.
The private key of the certificate from the CA.

And the client wallet will contain the following:

The certificate chain excluding the CA certificate. This consists of the intermediate certificates and the root certificate.

Create the Server Wallet

To use CA-signed certificates with TimesTen, you must manually import certificates into the server wallet and the client wallet. Complete the following steps for the client wallet. These steps assume intermediate certificates certsigner1.pem and certsigner2.pem.

Concatenate the certificates in the correct order. Starting with .pem files that contain x509 certificates, concatenate the certificates in order from the certificate received from the CA to the root. For example:
```
% cat cert.pem certsigner1.pem certsigner2.pem root.pem > complete.pem
```
Package the certificates into a pkcs12 file, as in the following example. Use any password in the openssl command. It will not be in the Oracle Wallet. In this example, the concatenated certificates are in complete.pem and the private key is in privkey.pem.
```
% openssl pkcs12 -export -in complete.pem -inkey privkey.pem -out server.p12 -password pass:mypwd
```
Create an empty auto_login_only Oracle Wallet using the TimesTen ttCreateCerts utility. See ttCreateCerts in the Oracle TimesTen In-Memory Database Reference for information about ttCreateCerts and the -run option.
```
% ttCreateCerts -run "wallet create -wallet servertWallet -auto_login_only"
```

Put the certificates and private key into the wallet. For example:

% ttCreateCerts -run "wallet import_pkcs12 -wallet serverWallet -auto_login_only -pkcs12file server.p12 -pkcs12pwd mypwd"

Verify the server wallet. This includes confirming that the intermediate and root certificates are “Trusted Certificates” and the new certificate is a “User Certificate”. (A “User Certificate” means that TimesTen has the private key for it.) Output should be of the basic form shown.

% ttCreateCerts -run "wallet display -wallet path/serverWallet"
Requested Certificates:
User Certificates:
Subject:        CN=www.example.com,O=xxxxxxxxxxxxxx,L=xxxxxxxxxxxxxx,ST=xxxxxxxxxxxxxx,C=US
Trusted Certificates:
Subject:        CN=xxxxxxxxxxxxxx SHA-256 Private Root,O=xxxxxxxxxxxxxx,C=US
Subject:        CN=xxxxxxxxxxxxxx SHA-256 Private Intermediate,O=xxxxxxxxxxxxxx,C=US

Create the Client Wallet

Concatenate the certificates in the correct order. Starting with .pem files that contain x509 certificates, concatenate the certificates in order from the certificate received from the CA to the root. For example:
```
% cat cert.pem certsigner1.pem certsigner2.pem root.pem > complete.pem
```
Package the certificates into a pkcs12 file, as in the following example. Use any password in the openssl command. It will not be in the Oracle Wallet. In this example, the concatenated certificates are in complete.pem and the private key is in privkey.pem.
```
% openssl pkcs12 -export -in complete.pem -inkey privkey.pem -out server.p12 -password pass:mypwd
```
Create an empty auto_login_only Oracle Wallet using the TimesTen ttCreateCerts utility. See ttCreateCerts in the Oracle TimesTen In-Memory Database Reference for information about ttCreateCerts and the -run option.
```
% ttCreateCerts -run "wallet create -wallet clientWallet -auto_login_only"
```

Import the certificates and private key into the wallet.

% ttCreateCerts -run "wallet import_pkcs12 -wallet clientWallet -auto_login_only -pkcs12file server.p12 -pkcs12pwd mypwd"

Verify the client wallet. This includes confirming that the intermediate and root certificates are “Trusted Certificates” and the new certificate is a “User Certificate”. (A “User Certificate” means that TimesTen has the private key for it.) Output should be of the basic form shown.
Proceed to Task 3.

Task 3: Configure the Server for TLS

You can configure TLS for the server in the following ways.

The encryption flag and cipher suite(s) are specified in the ttInstanceCreate command as shown earlier. Later, there are additional TLS configuration attributes you can set as well. In particular, set the wallet location.
At the instance level, you can add or update TLS attributes in the timesten.conf file in the timesten_home/conf directory, such as through the server_wallet, server_cipher_suites, and server_encryption attributes. (Recall that initial values for server_cipher_suites and server_encryption were set through ttInstanceCreate.) Values in timesten.conf serve as default values for any database on the instance.
At the database level, server attributes for TLS can be set in the server DSN definition in timesten_home/conf/sys.odbc.ini. For a given database, these settings override the instance-level settings in timesten.conf.

This excerpt from a server DSN definition specifies where ttInstanceCreate placed the server wallet directory:

[mydb]
Driver=timesten_home/install/lib/libtten.so
DataStore=databases_dir/mydb
...
Wallet=timesten_home/conf/serverWallet

Make sure that you also update the new wallet directory in timesten.conf file using ttInstanceModify -serverWallet utility or modifying the server_wallet attribute in the timesten.conf file. Alternatively, if you're using the sys.odbc.ini file to specify the TLS attributes, modify the Wallet attribute.

See Server Attributes for TLS for information about available configuration attributes.

Task 4: Configure the Client for TLS

Configure TLS for the client in the client DSN definition. Manually set Encryption (the encryption flag), CipherSuites (the cipher suite(s) to use), and Wallet (pointing to the client wallet directory) in the client DSN definition in sys.odbc.ini on the server.

For example, for a database mydb:

[mydbCS]
TTC_SERVER=mydb_CS
TTC_SERVER_DSN=mydb
Wallet=timesten_home/conf/clientWallet
Encryption=required
CipherSuites=TLS_AES_128_CCM_SHA256

Also be aware of these alternatives:

You can manually copy the client wallet from the server and edit the odbc.ini file on the client to set the correct attribute values. The ttAdmin utility has a -clientExportAll option that includes all the required files to copy to your client. See Transport Layer Security in Oracle TimesTen In-Memory Database Reference.
You can set attribute values in the connect string for a particular connection, such as from the ttIsql utility:
```
Command> connect "Driver=...;DataStore=...;Encryption=required;CipherSuites=TLS_AES_128_CCM_SHA256";
```
You can set equivalent attributes at the instance level in the TimesTen configuration file, timesten_home/conf/timesten.conf, on the client. These settings, including client_encryption, client_cipher_suites, and client_wallet, would be used as default values. Any connection attribute settings for a particular connection take precedence.

See Client Attributes for TLS for information about available configuration attributes.

(Optional) Task 5: Export Certificates and Configuration in TimesTen

The ttAdmin utility has a –clientExportAll option that outputs a ZIP file containing the client wallet, a samplesys.odbc.ini file that can be used in accessing the database, and other files (such as tnsnames.ora file) as applicable.

The –clientExportAll option requires:

A server DSN name (specified on the command line)
The server DSN to be defined in the server sys.odbc.ini file.
The server DSN to be configured for TLS, including a wallet, encryption, cipher suites.

The following example shows a TLS-enabled server DSN named mydbCS in the server sys.odbc.ini file.

[mydbCS]
TTC_SERVER=mydb_CS
TTC_SERVER_DSN=mydb
Encryption=required
CipherSuites=TLS_AES_128_CCM_SHA256
Wallet=mydbCSWallet

Run the ttAdmin utility from the timesten_home/bin directory on the server. On the command line, specify the output ZIP file path and name, followed by the server DSN name. specify the desired ZIP file path and name and the client DSN.

The wallet in the exported ZIP file contains the CA public key used to verify server certificates and, when client authentication is enabled, a client certificate.

The following command exports the client configuration for the database mydbCS and creates a file named exports.zip in the timesten_home/info directory:

% ttAdmin -clientExportAll timesten_home/info/exports.zip mydbCS
Client definitions exported to timesten_home/info/exports.zip

The exports.zip file contains a sample sys.odbc.ini file and a directory named after the server DSN, mydbCSWallet in this example. That directory contains the client wallet, cwallet.sso, that was created during instance creation. The exported ZIP file does not contain the server wallet.

(Optional) Task 6: Import Certificates and Configuration in TimesTen

Run the ttClientImport utility from the client to import the contents of the ZIP file created by the ttAdmin -clientExportAll command.

Typically, copy the exported ZIP file from the server to a desired location on the client system, and then specify that location on the ttClientImport command line. The ttClientImport utility imports the client wallet, the sys.odbc.ini file, and other configuration files, as applicable.

The utility creates a wallet directory named after the server DSN, mydbCSWallet in this example, under the wallets directory under timesten_home/conf.

% ttClientImport path/exports.zip
Client definitions imported.

The client sys.odbc.ini is updated to add a client DSN with the TLS settings from the exported configuration. If a client DSN with the same name already exists, it is replaced. The wallet path in the imported sys.odbc.ini file is updated to reflect the actual wallet location under the wallets/mydbCSWalletdirectory path.

[mydbCS]
TTC_SERVER=mydb_CS
Encryption=Required
CipherSuites=TLS_AES_128_CCM_SHA256
Wallet=timesten_home/conf/wallets/mydbCSWallet

The following commands show the resulting directory structure on the client system:

% ls
sys.odbc.ini  sys.ttconnect.ini  timesten.conf  wallets
% ls wallets
mydbCSWallet
% ls wallets/mydbCSWallet
cwallet.sso

After the import is completed, and assuming the client and server are configured with compatible encryption and cipher suite settings, clients can connect to the server using TLS. See Task 7: Verify Operation of TLS for Client/Server.

See ttAdmin and ttClientImport in Oracle TimesTen In-Memory Database Reference for additional information about these utilities.

Task 7: Verify Operation of TLS for Client/Server

If TLS is configured on both the server and the client with sufficiently matching settings of Encryption and CipherSuite, 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.

The following set of examples shows the results of several combinations of encryption settings on the server and client.

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:

[mydb]
Driver=timesten_home/install/lib/libtten.so
DataStore=/db/databases/mydb
PermSize=512
TempSize=128
LogBufMB=256
LogFileSize=256
LogDir=/db/logs
DatabaseCharacterSet=AL32UTF8
OracleNetServiceName=ttorcl
Wallet=timesten_home/conf/mywallets/serverWallet
Encryption=requested
CipherSuites=TLS_AES_128_CCM_SHA256

Client DSN definition:

[mydbCS]
TTC_SERVER=myserverhost.example.com
TTC_SERVER_DSN=mydb
UID=myuser
PWD=welcome
Wallet=timesten_home/conf/mywallets/clientWallet
Encryption=requested
CipherSuites=TLS_AES_128_CCM_SHA256

Connect, executing ttIsqlCS from the timesten_home/bin directory (output formatted for readability):

% ttIsqlCS mydbCS
 
Copyright (c) 1996, 2025, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
 
connect "DSN=mydbCS";
Connection successful: DSN=mydbCS;TTC_SERVER=myserverhost.example.com;
TTC_SERVER_DSN=mydb;UID=myuser;DATASTORE=/db/databases/mydb;
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=TLS_AES_128_CCM_SHA256;
(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=TLS_AES_128_CCM_SHA256

From the client DSN definition:

CipherSuites=TLS_CHACHA20_POLY1305_SHA256

Connect:

% ttIsqlCS mydbCS
 
Copyright (c) 1996, 2025, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
 
connect "DSN=mydbCS";
 
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. With these encryption values, the TLS encryption is not enforced. The connection is successful but TLS is not used. (Except for what is shown here, settings are the same as in Scenario 1.) See also Table 4-3.

From the server DSN definition:

Encryption=accepted

From the client DSN definition:

Encryption=accepted

Connect:

% ttIsqlCS mydbCS
 
Copyright (c) 1996, 2025, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
 
connect "DSN=mydbCS";
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 mydbCS
 
Copyright (c) 1996, 2022, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
 
connect "DSN=mydbCS";
HY000: Connection rejected: inconsistent encryption attributes
The command failed.
Done.