3.3.2.3. RTI Security Plugins

The following issues affect backward compatibility in RTI Security Plugins when migrating from Release 6.0.0 to Release 6.0.1.

3.3.2.3.1. OpenSSL upgrade

Release 6.0.1 of Security Plugins uses OpenSSL® 1.1.1d. (Release 5.3.1 used OpenSSL 1.0.2n, and Release 6.0.0 used OpenSSL 1.0.2o.) Security Plugins 6.0.1 is API-compatible with OpenSSL versions 1.1.0a through 1.1.1d, not with versions earlier than OpenSSL 1.1.0a.

Note

OpenSSL 1.0.2 will only be supported until the end of 2019 (https://www.openssl.org/policies/releasestrat.html), so it is recommended that you upgrade the version of OpenSSL that you are using to OpenSSL 1.1.1d for release 6.0.1. For instructions on installing the latest version of OpenSSL, see the RTI Security Plugins Getting Started Guide 6.0.1.

3.3.2.3.2. Changes to building an application

When building a Windows application, you must now link against libssl and libcrypto instead of ssleay32 and libeay32.

When building a Windows statically-linked application, you must now link against the system library crypt32.lib. See rti_workspace/6.0.1/examples/connext_dds/c++/hello_security/READ_ME.txt for details.

When building a non-Windows statically-linked application, you may see this error:

undefined reference to 'pthread_atfork'

If so, open your makefile and make sure that -lpthread (which is part of $(SYSLIBS) in the makefile generated by RTI Code Generator) appears after -lssl and -lcrypto.

3.3.2.3.3. Changes to behavior of intermediate certificates

Intermediate certificates are certificates that have signed other certificates but are not self-signed. Security Plugins 6.0.1 requires that intermediate certificates have an X509 v3 extension, which explicitly allows it to sign other certificates. For example, the intermediate certificate’s .cnf file should have

[ v3_ca ]
basicConstraints = CA:true

and the “openssl ca” command to sign the intermediate certificate should have “-extensions”. For example (entered all on one line):

% openssl ca -batch -create_serial -config opensslECdsa.cnf -days 365 -in intermediateCaReqECdsa.pem
-extensions v3_ca -out intermediateCaECdsa.pem

Any intermediate certificates from previous releases must have this extension in order for their DomainParticipants to communicate with 6.0.1 DomainParticipants.

3.3.2.3.4. Property key_material_key now required for Secure Persistence Service

In previous releases, dds.data_writer.history.key_material_key was an optional string. Starting in 6.0.1, this property is now mandatory when configuring Durable Writer History (including Persistence Service) to store secure data. You may now specify either the file name or the document contents. If specifying the file name, the property value may optionally have the prefix file: (no space after the colon), followed by the fully-qualified path and name of the file. Note that a property value without a prefix is interpreted as a file name. If specifying the contents of the document, the property value must have the prefix data:, (no space after the comma), followed by the contents inside the document. For example: data:,myPassword.

If you need to use the current version of Persistence Service to access a database encrypted with a previous version of Persistence Service that did not specify a value for the property dds.data_writer.history.key_material_key, please contact RTI Support at support@rti.com to get the default non-disclosed key_material_key.

3.3.2.3.5. Issue related to missing keyCertSign when a CA has the KeyUsage X.509 V3 extension

In release 6.0.1, the Security Plugins introduced the ability to enforce the presence of the X.509 v3 extension KeyUsage. (See “Changes related to authentication plugin configuration” in the What’s New section of the RTI Security Plugins Release Notes 6.0.1.)

DomainParticipant creation should fail if you are enforcing key usage extension and the certificate of the Identity or Permissions CAs is missing the keyCertSign attribute. However, the Security Plugins are not enforcing this requirement in releases before 6.1.1. See Failure loading certificates due to missing keyCertSign when a CA has the KeyUsage X.509 V3 extension in the 6.1.1/6.1.2 section for more information.