6.2.3. Security Plugins
The following issues affect backward compatibility in Security Plugins when migrating from Release 6.0.0 to Release 6.0.1.
6.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.
6.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
.
6.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.
6.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.