Using data packet encryption for SQL OpenNet
The SQL OpenNet data packet encryption feature enables you to encrypt the transfer of sensitive data across a network. On Unix and OpenVMS, SQL OpenNET interfaces with a third-party library, OpenSSL, to provide SSL support for secure data transport between client and server. On Windows, as of version 12, SQL OpenNET interfaces with Microsoft Secure Channel (Schannel).
To use data packet encryption for SQL OpenNet, the server and all clients must be version 11.1.1 or higher.
Using encryption can affect performance because data must be encrypted and decrypted on both sides of the SQL OpenNet connection. The cipher negotiation between client and server, even though it happens only when a connection is established, also takes time. |
To use encryption, start vtxnetd or vtxnet2 with the -e option. With this option, you specify the SSL certificate file that the SQL OpenNet service will use. On Windows and Unix, this file is verified on startup and, by default, if the certificate is invalid, the service terminates and writes an error to the tcm_pid.log file. You can pass the invcertOK switch with -e to continue running if the certificate is invalid; the error is still logged so that you can troubleshoot the problem. Optionally, you can specify a certificate authority and TLS levels. The default TLS is 1.2 and higher; you can also specify 1.1 and higher or 1.3 and higher. Keep in mind that because protocol support varies by operating system, older systems may not support newer protocols. And as new threats and vulnerabilities are found, Synergex may need to update the default for accepted protocols to maintain a high level of security.
Follow these steps to set up SQL OpenNet to use data packet encryption.
1. | (Unix and OpenVMS servers) Install OpenSSL on your server machine. For details on which version of OpenSSL is required for your operating system and where to get it, see OpenSSL requirements (Unix and OpenVMS). The OpenSSL libraries are installed in a standard location determined by the operating system, so you don’t need to move them or set the path. On Unix, to verify that the libraries are in the correct location, you can run the dltest utility |
2. | (Unix clients) Install and configure OpenSSL on the client machines. The library path is used to find the OpenSSL libraries. If you used the setsde script to set up your Synergy environment, the path will be correctly set. You can run the dltest utility to see the shared library path and determine if Synergy can find the necessary DLLs. |
You can configure default client SSL settings for all SQL OpenNet connections by using settings in net.ini (see Setting SQL OpenNet client options in net.ini). And you can configure client SSL settings for specific DSNs and SQL Connection connections (see Setting up access with DSNs and %SSC_CMD).
3. | Create a certificate file. You may name it anything you like and put it anywhere on the server. Alternatively, on Windows you can use a certificate in the Windows Certificate Store; see Windows Certificate Store specification for the format. |
4. | Start vtxnetd or vtxnet2 with the -e option. Specify the certificate and other options as needed. See vtxnetd and vtxnet2 programs and Encrypting data packets (-e) for details. |
To determine whether the SQL OpenNet service is set to use data packet encryption, start vtxnetd or vtxnet2 with the log option, and then use vtxping to test the connection. If encryption is in use, the log file will include something like the following:
Thu Mar 17 10:38:02 2016 - Version 4.0.0.17. Thu Mar 17 10:38:02 2016 - Starting vtxnetd (pid: 6128). Thu Mar 17 10:38:02 2016 - Server port 1987 Thu Mar 17 10:38:02 2016 - SSL enabled Thu Mar 17 10:38:02 2016 - SSL compile/library: OpenSSL 1.0.2d 9 Jul 2015/OpenSSL 1.0.2d 9 Jul 2015 Thu Mar 17 10:38:02 2016 - Creating 'listen' queue (max: 10) Thu Mar 17 10:38:02 2016 - Setup done. Going into 'accept' loop Thu Mar 17 10:38:07 2016 - Starting a TCMHOST thread (parms: 128 VTX11_12)
If the log file includes an “SSL compile/library:…No such file or directory” error, the path to the certificate is incorrect.
If the log file includes an “SSL compile/library:…problems getting password” error, the CA file includes a pass phrase, which is not supported. See Creating a local certificate authority.
An “INVVER: NET version mismatch…” error may mean that a client from a prior version of Connectivity Series is attempting to connect to the SQL OpenNet service while encryption is enabled; the server and all clients must be version 11.1.1 or higher.