Use the following guidelines to encrypt solidDB connectivity by using the TLS protocol.
Note To use solidDB with TLS, you must have the OpenSSL 1.1.1 libraries (see wiki.openssl.org/index.php/Binaries); the solidDB distribution does not include OpenSSL libraries. solidDB supports only the TLS 1.2 protocol.
Quick setup
By default, when configured to use TLS, solidDB automatically generates a one-time, self-signed certificate that allow a TLS client to connect to the server.
Note Using this self-signed certificate, instead of a certificate that is signed by a certificate authority (CA), might expose the connection to ‘man in the middle’ attacks, see Using signed X509 certificate from a certificate authority.
To use the TLS protocol with solidDB self-signed certificates, complete the following steps:
1 Make sure that the solidDB server and ODBC clients have access to the OpenSSL shared libraries (libssl and libcrypto).
– On Linux and UNIX: libraries (for example, libssl.so) should be in $LD_LIBRARY_PATH
– On Windows: libraries (for example, libssl.dll) should be in %PATH%
– On AIX: libraries (for example libssl.a) should be in $LIBPATH
The actual name of the library might be slightly different.
Note JDBC clients use JSSE (Java Secure Sockets Extension), which is built in to the Java runtime environment (JRE) and do not use the OpenSSL libraries.
2 In the server-side solid.ini, add a network listening name that uses the tls prefix, for example:
[Com] Listen=tls 192.168.1.1 1964
3 Set up clients to use TLS:
– ODBC: In client-side solid.ini, add a connect string that uses the tls prefix, for example:
[Com] Connect=tls 192.168.1.1 1964
For solidDB tools, use tls prefix in connect string, for example:
solsql 'tls 192.168.1.1. 1964' dba dba
– JDBC: In the connect string, set the connection property solid_use_tls to yes, for example:
When a connection is made, solidDB automatically creates the internal, one-time, self-signed certificate that allows the TLS client to connect to the server.
Notes
▪ If an SSL library is not found when TLS is configured, solidDB reports an error in solmsg.out.
▪ You can specify only one listening protocol per socket; you cannot have unsecured and secured connections on the same socket.
Custom setup
If required, you can specify the paths to the SSL libraries or use a signed X509 certificate from a certificate authority.
Specifying location of SSL libraries
Instead of making sure that the libraries are in the appropriate path statement for your operating system, you can specify the paths to the libssl and libcrypto libraries in the server-side and client-side solid.ini. For example:
Using signed X509 certificate from a certificate authority
While a basic TLS connection offers encryption, it does not prevent man-in-the-middle attacks or support certificate expirations. If such features are needed, you must get a certificate from a certificate authority (CA).
A CA is typically a third-party trusted organization. Your organization might also act as a CA for internal use. It is even possible to create a CA certificate for only a specific purpose, for example, for a single application or for testing.
To use the TLS protocol with a CA certificate, complete the following steps:
1 Create a private key and public certificate request. For example, the following command creates a private key (myprivate.key) and certificate request (mycertificaterequest.csr) that are valid for one year:
In this case, the private key is protected with the password mypassword, but a password is not compulsory.
2 Send the certificate request to your certificate authority for signing. You will get a signed certificate public key and the CA public certificate in return.
Note The private key should not be sent anywhere.
3 Place the signed certificate public key, the CA public certificate, and the private key (that you initially created) in a path that solidDB can access.
4 Configure the solidDB server to use the certificates by configuring the paths to the certificates and private key in the server-side solid.ini, as shown in the following example:
Note The certificate file might have a different extension, for example .pem.
5 If the private key is password-protected, you must enter the password in a file (for example password.txt) and then configure the path to the file in the [Com] section as shown in the following example:
Note Security for the password file is not handled by solidDB.
6 Restart the solidDB server.
Note that the solidDB server does not start under any of the following conditions:
▪ any of the certificates have expired or are invalid,
▪ the certificate private key is password-protected and the password file is not configured in solid.ini,
▪ the password file (if configured) is inaccessible or contains the wrong password.
7 For ODBC clients, place the CA certificate in a path that the client can access and configure the path to the certificate in the client-side solid.ini, as shown in the following example:
Note The keystore is created if it does not already exist.
b Configure the JDBC client to use the certificate in the keystore by using one of the following methods:
– (available in solidDB version 200.0.3 and later) Use the solid_truststore_path and (if your keystore has a password) the solid_truststore_pwd non-standard JDBC properties in the connection string, for example: