This parameter has been deprecated. Use the data_channel TLS CONFIGURATION instead.

Enables encryption using SSL on the data channel. The value of this parameter is a comma-separated list of the following:

• An SSL certificate (chainable)
• The corresponding SSL private key
• The SSL CA (Certificate Authority) certificate.

You should set EncryptSpreadComm before setting this parameter.

In the following example, the SSL Certificate contains two certificates, where the certificate for the non-root CA verifies the certificate for the cluster. This is called an SSL Certificate Chain.

=> ALTER DATABASE DEFAULT SET PARAMETER DataSSLParams =
'----BEGIN CERTIFICATE-----<certificate for Cluster>-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----<certificate for non-root CA>-----END CERTIFICATE-----,
-----BEGIN RSA PRIVATE KEY-----<private key for Cluster>-----END RSA PRIVATE KEY-----,
-----BEGIN CERTIFICATE-----<certificate for public CA>-----END CERTIFICATE-----';

Indicates a default session timeout value for all users where IDLESESSIONTIMEOUT is not set. For example:

=> ALTER DATABASE DEFAULT SET defaultidlesessiontimeout = '300 secs';

String, a Diffie-Hellman group of at least 2048 bits in the form:

 -----BEGIN DH PARAMETERS-----...-----END DH PARAMETERS-----

You can generate your own or use the pre-calculated Modular Exponential (MODP) Diffie-Hellman groups specified in RFC 3526.

Changes to this parameter do not take effect until you restart the database.

Default: RFC 3526 2048-bit MODP Group 14:

-----BEGIN DH PARAMETERS-----MIIBCAKCAQEA///////////
JD9qiIWjCNMTGYouA3BzRKQJOCIpnzHQCC76mOxObIlFKCHmONAT
d75UZs806QxswKwpt8l8UN0/hNW1tUcJF5IW1dmJefsb0TELppjf
tawv/XLb0Brft7jhr+1qJn6WunyQRfEsf5kkoZlHs5Fs9wgB8uKF
jvwWY2kg2HFXTmmkWP6j9JM9fg2VdI9yjrZYcYvNWIIVSu57VKQd
wlpZtZww1Tkq8mATxdGwIyhghfDKQXkYuNs474553LBgOhgObJ4O
i7Aeij7XFXfBvTFLJ3ivL9pVYFxg5lUl86pVq5RXSJhiY+gUQFXK
OWoqsqmj//////////wIBAg==-----END DH PARAMETERS-----

Boolean, specifies whether a non-superuser can view details of another user:

• 0: Users can view details of other users.
• 1: Users can only view details about themselves.

Default: 0

Boolean, specifies whether to automatically enable all roles granted to a user on login:

• 0: Do not automatically enable roles
• 1: Automatically enable roles. With this setting, users do not need to run SET ROLE

Default: 0 (disable)

Specifies which SSL cipher suites to use for secure client-server communication. Changes to this parameter apply only to new connections.

Default: Vertica uses the Microsoft Schannel default cipher suites. For more information, see the Schannel documentation.

Enables Spread encryption on the control channel, set to one of the following strings:

• vertica: Specifies that Vertica generates the Spread encryption key for the database cluster.
• aws-kms|key‑name, where key‑name is a named key in the iAWS Key Management Service (KMS). On database restart, Vertica fetches the named key from the KMS instead of generating its own.

If the parameter is empty, Spread communication is unencrypted. In general, you should enable this parameter before modifying other security parameters.

Enabling this parameter requires database restart.

A string that specifies which user inherits objects after their owners are dropped. This setting ensures preservation of data that would otherwise be lost.

Set this parameter to one of the following string values:

• Empty string: Objects of dropped users are removed from the database.
• username: Reassigns objects of dropped users to username. If username does not exist, Vertica creates that user and sets GlobalHeirUsername to it.
• <auto>: Reassigns objects of dropped LDAP users to user dbadmin.

  Be sure to include the angle brackets < >.

For more information about usage, see Examples.

Default: <auto>

When using CONNECT TO VERTICA to connect to another Vertica cluster for import or export, specifies the degree of stringency for using TLS. Possible values are:

• PREFER: Try TLS but fall back to plaintext if TLS fails.
• REQUIRE: Use TLS and fail if the server does not support TLS.
• VERIFY_CA: Require TLS (as with REQUIRE), and also validate the other server's certificate using the CA specified by the "server" TLS CONFIGURATION's CA certificates (in this case, "ca_cert" and "ica_cert"):

  => SELECT name, certificate, ca_certificate, mode FROM tls_configurations WHERE name = 'server';
    name  |   certificate    |   ca_certificate   |   mode
  --------+------------------+--------------------+-----------
   server | server_cert      | ca_cert,ica_cert   | VERIFY_CA
  (1 row)

• VERIFY_FULL: Require TLS and validate the certificate (as with VERIFY_CA), and also validate the server certificate's hostname.
• REQUIRE_FORCE, VERIFY_CA_FORCE, and VERIFY_FULL_FORCE: Same behavior as REQUIRE, VERIFY_CA, and VERIFY_FULL, respectively, and cannot be overridden by CONNECT TO VERTICA.

Default: PREFER

Boolean, specifies whether the FIPS mode is enabled:

• 0 (disable)
• 1: (enable)

On startup, Vertica automatically sets this parameter from the contents of the file crypto.fips_enabled. You cannot modify this parameter.

For details, see FIPS Compliance for the Vertica Server .

Default: 0

Sets the algorithm for the function that hash authentication uses, one of the following:

• SHA512
• MD5

For example:

=> ALTER DATABASE DEFAULT SET SecurityAlgorithm = 'SHA512';

Default: SHA512

The absolute path to a certificate bundle of trusted CAs. This CA bundle is used when establishing TLS connections to external services such as AWS or Azure through their respective SDKs and libcurl. The CA bundle file must be in the same location on all nodes.

If this parameter is empty, Vertica searches the "standard" paths for the CA bundles, which differs between distributions:

• Red Hat-based: /etc/pki/tls/certs/ca-bundle.crt

• Debian-based: /etc/ssl/certs/ca-certificates.crt

• SUSE: /var/lib/ca-certificates/ca-bundle.pem

Example:

=> ALTER DATABASE DEFAULT SET SystemCABundlePath = 'path/to/ca_bundle.pem';

Default: Empty