3.2.4. 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.
18.104.22.168. 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.
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.
22.214.171.124. 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
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
126.96.36.199. 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.
188.8.131.52. Property key_material_key now required for Secure Persistence Service¶
In previous releases,
dds.data_writer.history.key_material_key was an optional string. 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
data:, (no space after the comma), followed by the contents inside the document.
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 firstname.lastname@example.org
to get the default non-disclosed key_material_key.