In cases where the server and client exist on separate networks or they are in a high-risk network, the lack of encryption does introduce security concerns as a malicious actor could potentially eavesdrop on the traffic as it is sent over the network between them.
To mitigate this concern, SQL Server allows you to encrypt data in transit between the server and clients using the Transport Layer Security (TLS) protocol. TLS was formerly known as Secure Socket Layer (SSL), but strictly speaking the SSL protocol is a predecessor to TLS and, that version of the protocol is now considered insecure. The documentation still uses the term SSL often and for compatibility reasons TLS-related server system
In order to secure connections between the server and client, you need to ensure that your server was compiled with TLS support.
Depending on the setup, one or more of the following fields will need to reference the appropriate file:
For production use, your MariaDB deployment should use valid certificates generated and signed by a single certificate authority. You or your organization can generate and maintain an independent certificate authority, or use certificates generated by a third-party SSL vendor.
To verify the identity of the MariaDB deployment you connect to, provide one or more certificates of trusted Certificate Authorities.
If the server is configured to perform certificate validation, you need to provide a certificate here to identify yourself to the server.
Typical file extensions for the certificate are .crt or .pem.
Client Private Key
If the server is configured to perform certificate validation, you need to provide the private key here to identify yourself to the server.
Typical file extensions for the private key are .key or .pem.
Private Key Password
A private key can optionally be encrypted with a password.
If your private key is password protected, enter the password here. If not, leave the field blank.