The first Long Term Support (LTS) release of Synergy, version 12.1, is right around the corner, and there is a significant change of which all developers should be aware. The change relates to how encryption works on Windows systems and how cryptographic certificates get validated on several platforms. If you use any of the encryption capabilities in Synergy/DE products, please review the information below before upgrading to Synergy 12.

Encryption Provider Changes on Windows

In Synergy 12, we have changed how we implement encryption on Windows; we now use Secure Channel, which is part of the Windows operating system, instead of OpenSSL. There are many benefits to doing so, not least of which is that on Windows, developers no longer need to:

• Download and deploy OpenSSL DLLs to use encryption.
• Maintain cryptographic certificates on disk in PEM files.
• Create, manage, and specify Certification Authority (or CA) files to make HTTPS calls securely.

No code changes are required to take advantage of this new encryption provider, as all required changes have been made internally without altering the signatures of any routines. However, there are some optional changes that you might want to make to your code or procedures to reduce the overhead required to manage certificates and CA files.

The first change you might consider relates to configuring xfServer or xfServerPlus to use encrypted connections. Previously, there were two ways to do this: using the rsynd utilities -cert command-line option or using the “Enable Encryption” and “Certificate file” fields in the service configuration dialogs of the Synergy Configuration Program. These mechanisms previously required you to provide a file system path to the certificate, requiring the certificate to be exported from the Windows Certificate Store to a PEM file.

While this is still supported, a new syntax allows you to refer to the certificate directly in the Windows Certificate Store. There are two variations of the new syntax, one specifying the store location and common name and one specifying the store location and thumbprint of the certificate. For example,

LocalComputer\Root\MyCertificate

A similar scenario exists when implementing encryption with the SQL OpenNet protocol used by the SQL Connection and xfODBC products. This time encryption is activated via the -e option to the vtxnetd or vtxnet2 commands, and once again, a Windows Certificate Store path can serve as an alternative to a PEM file spec.

And finally, another change to consider is a slight change when using the Synergy HTTP API to make secure HTTPS calls to websites or services. Previously, to make HTTPS calls securely, it was necessary to provide a Certification Authorities (or CA) file. A certification authority is a trusted external entity from which cryptographic certificates may be purchased or otherwise obtained. The CA file you provide contains one or more certificates identifying the certification authorities whose issued certificates you are willing to trust.

Of course, this is a tough decision, so most developers defer to a trusted external entity such as Microsoft, which maintains such a list of trusted entities as part of the Windows operating system, primarily for use in web browsers such as Internet Explorer and Edge. Developers would use a Windows utility to export the Windows Certificate Stores’ Trusted Root Certification Authorities list to a file and then use a utility such as OpenSSL to convert that file into a format acceptable to the Synergy HTTP API. Of course, this is an operation that should occur regularly, as the list of trusted entities and their associated certificates changes periodically.

Once again, this mechanism is still supported, but in Synergy 12, a simpler alternative is to pass the literal value “cert_store” to the CA file parameter of the various HTTP API routines. Doing so instructs the Synergy runtime to validate certificates directly against the Trusted Root Certification Authorities list in the Windows Certificate Store.

Certificate Validation Changes on Windows, Linux, and UNIX

Another related change is more wide-ranging, affecting all platforms except OpenVMS. Starting with Synergy 12.1, cryptographic certificates get validated for authenticity, revocation, and expiration before use. This validation did not previously occur, and this means that there is a possibility that some existing deployments could be running with untrusted, revoked, or expired certificates.

With xfServer, xfServerPlus, and SQL OpenNet, certificate validation occurs during service startup. In such a scenario, upgrading to Synergy 12.1 could break existing environments as, for example, instances of those services might fail to restart during the upgrade because of bad certificates.

This change could also impact secure HTTPS connections using various HTTP API routines.

To head off any problems, we recommend performing an audit of any cryptographic certificates used in your environment before upgrading to Synergy 12, checking that those certificates:

• Are from a trusted source, or in the case of “self-signed” certificates, have been registered as trusted.
• Have not been revoked since issued.
• Have not expired.

And if you have not already done so, we also recommend implementing an ongoing process designed to ensure the replacement of certificates before they expire.

If the worst comes to the worst and you encounter an invalid certificate in a production scenario, we have provided an “emergency escape hatch” to get you up and running quickly. Specifically, the rsynd, vtxnetd, and vtxnet2 utilities have a new command-line option, -invcertok, and for xfServer and xfServerPlus, the Synergy Configuration Program has a new checkbox, “Allow startup with an invalid certificate.” Using either of these options makes it possible to start an xfServer or xfServerPlus service even with an invalid certificate, as was previously the case.