# xSQL SSL Parameters

> The xSQL configuration file can be used to define global SSL parameters (corresponding to the C API `mco_ssl_params_t` structure). Global SSL parameters are specified in the `ssl_params` section. Component-specific SSL parameters can be specified for eXtremeDB High Availability, eXtremeDB Cluster or Remote SQL communications in their separate sections. Component-specific SSL support is disabled by default, even when the global SSL settings are defined. To enable SSL support for a component and inherit the global settings, specify an empty `ssl_params` section in the component's configuration.

> The descriptions of the individual settings are available in the target/xsql/readme.txt file.

> ### For an overview see page Configuration File Parameters

> The global `ssl_params` section consists of a set of "name : value" pairs enclosed within braces. For example:

>         ssl_params : {
>             verify_mode: ["verify_peer", "verify_fail_if_no_cert"],
>             ca_file: "../certs/ca.pem",
>             ...
>         }

> Note that `ssl_params` sections can appear at different levels:

> - the top level: here the `ca_file` or `ca_path` values must be defined and cannot be defined in other `ssl_params` sections

> - in the `ha_params` section: where security parameters are defined for eXtremeDB High Availability (see page xSQL HA Parameters)

> - in the `cluster_params` section: where security parameters are defined for eXtremeDB Cluster (see page xSQL Cluster Parameters)

> - in elements of a `sql_servers` vector (see page xSQL SQL Parameters)

> - in elements of a `remote_client::shards` vector (see page xSQL SQL Parameters)

> The following table lists the possible options for the `ssl_params` section with the corresponding C API structures and values specified in the comment:

> Option name : example value | Comment
> --- | ---
> verify_mode: ["verify_peer", "verify_fail_if_no_cert"], | SSL verify mode (`mco_ssl_params_t::verify_mode`). This is the peer verification mode determined by the following flags: `verify_none` : in server mode, the client certificate won't be requested; in client mode, when anonymous cipher is not used, the certificate will be verified but the handshake will be continued regardless of the result `verify_peer` : in server mode, the client certificate will be requested and verified; in client mode, when anonymous cipher is not used, the server certificate will be verified; the handshake will be aborted in case of verification failure `verify_fail_if_no_cert` : in server mode, the handshake will be terminated if the client doesn't send its certificate; ignored in client mode; can only be used together with `verify_peer` `verify_client_once`: in server mode, the client certificate will only be requested on initial TLS handshake (but not in case of renegotiation); ignored in client mode; can only be used together with `verify_peer` The default value is `verify_peer + verify_fail_if_no_cert`
> cert_file_pem: "../certs/server.crt", | Path to the certificate file in PEM format (`mco_ssl_params_t::cert_file_pem`). The default is none
> pkey_file_pem: "../certs/server.key", | Path to the private key file in PEM format (`mco_ssl_params_t::pkey_file_pem`). The default is none
> ca_file: "../certs/ca.pem", | Corresponds to the `ca_file` parameter of the `mco_ssl_load_verify_locations()` function. This must be a certificate chain file in PEM format; default is none
> ca_path: "eXtremeDB/ssl" | The path to the CA certificate storage; default is none. This directory should be set up as described on the ​OpenSSL SSL_CTX_load_verify_locations() page
> cipher_list: | The list of ciphers to be used, as a string in OpenSSL format (see ​OpenSSL ciphers page for details); the default list is "`HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4`"
> max_cert_list: | The maximum size allowed for the peer's certificate chain, in bytes; the default is 100 Kb
> verify_depth: | The maximum depth for the certificate chain verification; the default is 100