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. SQL OpenNet interfaces with a third‑party library, OpenSSL, to provide SSL support for secure data transport between client and server.

To use SSL encryption, the server and all clients must be version 10.3.3 or higher.

Note

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 implement encryption, you must start vtxnetd or vtxnet2 with the ‑e option. You specify the SSL certificate file, the private key file, and optionally a list of accepted protocols (TLS versions). You can specify one or more of the following protocols: TLS 1.0, 1.1, 1.2. By default, all three are accepted. Bear in mind that because protocol support varies by operating system, older systems may not support newer protocols. For example, Windows Vista and Windows Server 2008 do not support any protocols above TLS 1.0. Additionally, 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 SSL encryption. For details on which version of OpenSSL is required for your operating system, see OpenSSL requirements. For additional information on OpenSSL, see Synergex KnowledgeBase article 100001979.

1. Install OpenSSL on your server machine.
2. Ensure that the OpenSSL shared libraries are in the correct location on the server and have been added to the correct path. The library path must be set before starting vtxnetd or vtxnet2.
3. Create a certificate file and a private key file. You may name these anything you like and put them anywhere on the server. Note that the certificate file cannot include a pass phrase. For information on creating certificate and key files, see Requesting a certificate and Testing your HTTPS setup locally.
4. Install and configure OpenSSL on the client machines.
5. Start vtxnetd or vtxnet2 with the ‑e option. Specify the certificate and the private key file, and optionally specify the protocol (TLS levels). See vtxnetd and vtxnet2 programs for details.

To determine whether the SQL OpenNet service is set to use data packet encryption (SSL), start vtxnetd or vtxnet2 with the log option, and then use vtxping to test the connection. If SSL 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 or private key file is incorrect.

If the log file includes an “SSL compile/library:…problems getting password” error, the private key file includes a pass phrase, which is not supported. For information on removing a pass phrase, see Testing your HTTPS setup locally.

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 SSL encryption is enabled. To use SSL encryption, the server and all clients must be version 10.3.3 or higher.