.. include:: /../getting_started/vars.rst .. _section-Product-Security-601: 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. 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 :link_connext_sec_gsg_601:`RTI Security Plugins Getting Started Guide 6.0.1<>`. 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: .. code-block:: bash 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``. 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 .. code-block:: bash [ 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): .. code-block:: bash % 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*. .. _section-security-key: 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.