Client Appliance Settings

CORE Client appliance configuration is done at two levels:

  • CORE client's appliance settings specify the CORE client attributes. They apply to all CORE partitions that are accessed from the client appliance.
  • To automate this type of configuration, refer to Automatic Configuration.

  • Client' settings in a Partition. Refer to Partition Settings Summary.

Client Settings Summary

The CORE client settings can be specified in two locations:

  • "V1" location - Provides backward compatibility to versions before 2.0.2010.
  • "V2" location - recommended option for new clients.

CORE client checks both locations starting from "V2". If the setting is not found, it searches for it in location "V1".

- All settings, apart from the servers setting, are optional.
- The default setting is applied to the omitted settings.

The client appliance settings are stored in the Client Files and Registry.

Servers Setting

EP Servers Primary Group
The servers setting is a comma-separated list of EP servers and their access ports in the following format:

<EP1 server name or IP address>[:<TCP/IP port>] [,<EP2 server>[:<TCP/IP port>]]

Default port: 443

EP Servers Alternative Groups

By using the servers<N> setting, you may define alternative server groups that shall serve the client once its primary server group is out of order - refer to Client-Controlled High Availability. In the following example, we define the alternative UCLClosedUnbound Command Language servers group - servers2

check-integrity Setting

To assure the integrity of metadata provided by EP to a client, the client may request that all provided metadata be confirmed and approved by the EP's partner and MPCClosedMultiparty computation - A methodology for parties to jointly compute a function of their inputs while keeping those inputs private.-signed (using the root-ca key). The absence of the signature or its invalidity indicates that the provided metadata has been tampered with.

To enable this enhanced protection layer, enable the client's check-integrity settings.

By default, this feature is disabled for all requests except the ucl show.

ucl show -n <key-name>

Private RSA key: UID=ac84be99196d9461
Name = "rsa-key1"
--- truncated ---
Integrity confirmed

To unconditionally disable this feature, set check-integrity to -1.


PKCSClosedPublic-Key Cryptography Standards - Industry-standard cryptography specifications.#11 attribute that specifies how long (in seconds) the obtained exportable key material or certificate may be used by PKCSClosedPublic-Key Cryptography Standards - Industry-standard cryptography specifications.#11 client without refreshing its value.

Range - 0 - 86400 secs

Default - 60 secs

This device-specific setting is used when the corresponding partition setting (cache-timeout) is set to 0 (the default value). sOtherwise, the partition's value is used by this feature.

use_gnuTLS Setting

Specify gnuTLS as the SSLClosedSecure Sockets Layer - a cryptographic protocol that provides communications security over a computer network. engine when a CORE client is integrated with certain applications that already utilize OpenSSL as an SSLClosedSecure Sockets Layer - a cryptographic protocol that provides communications security over a computer network. engine.

Use gnuTLS when integrating the client with the Oracle TDEClosedTransparent Data Encryption - Technology to encrypt database files.

To utilize the libgnutls28 as an SSLClosedSecure Sockets Layer - a cryptographic protocol that provides communications security over a computer network. engine in use by a CORE client:

  1. Set use_gnutls=1 in client configuration.
  2. Verify that the Gnu TLSClosedTransport Layer Security - a cryptographic protocol that provides communications security over a computer network version is 3.2.11:
    • On Red Hat Enterprise Linux:
      • Version 6.7 - run: sudo yum update gnutls.
      • Any version above 6.7 - no update is needed.
    • On Ubuntu:
      • Version 14.04: Remove the libgnutls package and install libgnutls28.
      • Version 16.04 or 18.04- no update is needed.

app_arg_full Setting

The CORE audit log captures the request and its arguments in the Connect log record. In some cases, the captured arguments may include sensitive info such as an inline password. Starting with CORE client Release 2.0.1711:

  • For openssl, keytool, jarsigner, signcode, ucl:
    • The command and all its arguments are included in the log message
    • The inline passwords are anonymized using asterisks.
  • For any other program, all arguments are stripped from their Connect log record.

To disable password parameter anonymization or complete omission of all parameters, add the program name to the client's app_arg_full setting that is formatted as follows:

<program name 1>|<program name 2>|<program name 3>

For example, the following app_arg_full setting presents all java command arguments and stops anonymizing openssl passwords:


Client Registry with arg_app_full setting

pfx_hw_salt Setting

A CORE appliance that was registered using the ucl register command, protects the obtained certificate using a unique appliance-specific passphrase.

Suppose the CORE client fails to generate an appropriate passphrase for the PFXClosedAn archive file format for storing cryptography objects using Base64 encoding certificate of the specified partition. In that case, the client silently ignores the presence of the certificate and blocks any request to access the partition.

Hardening of the passphrase depends on the underlying OS:

To take advantage of the latest passphrase generation method, renew the partition's certificate using the ucl renew command.

Client-Controlled High Availability

A group of EP servers provides CORE service High Availability (HA). A CORE client can reach a working EP either with the help of a Load Balancer (LB) or by implementing the LB+HA function by the client. In the latter case, the CORE appliance must be configured with a group(s) of EP servers. A client searches for an available server in two dimensions:

  • Iteration within a Group of Servers

    Iteration among the servers in a group is triggered by:

    • An explicit error when connecting to the selected server.
    • The connect_timeout expiry when connecting to the selected server.
  • The ha_mode_standby setting specifies the next-server selection method:

    • 0 - the next-server is selected according to the server order in the group.
    • 1 - the next-server is selected randomly.
  • Iteration among the Server Groups
  • Initially, a client attempts to work with servers in the primary group specified by the servers setting. It remains in the primary group if at least one of its servers provides the service.

    Once it fails, the client starts inspecting servers in the secondary groups specified in the servers[N] setting. The secondary groups are searched in ascending N-number order. When a working server in one of the secondary groups is detected, the client continues using this group for up to ha_mode_timeout seconds. In the case of a failure, it proceeds with the search in the remaining groups, if any. Nevertheless, upon expiry of the ha_mode_timeout interval, the client returns to inspect servers in its primary group, and the cycle restarts.