.. include:: /../getting_started/vars.rst
.. _section-Product-Security-611:
RTI Security Plugins
********************
The following issues affect backward compatibility in *RTI Security Plugins*
when migrating from Release 6.1.0 to Release 6.1.1 or 6.1.2.
Problems checking whether a participant is allowed to exist
===========================================================
In |CONNEXT| 6.1.0 and below, if a |PermissionsDoc| contained conflicting
allow and deny rules for a given domain combination, then the rule that took
effect when creating or discovering new |DPs| was the
rule that appeared last in the document. This order of precedence is not the
intention of the `DDS Security specification `_.
In this release, the rule that takes effect by default is the one that appears
first in the document.
For example, in previous |CONNEXT| versions, in the following
|PermissionsDoc| snippet, a |DP| on domain 12 was incorrectly allowed
to be created:
.. code-block:: xml
12
12
This problem has been fixed in release 6.1.1. Now, the first rule will be
applied, so a |DP| on domain 12 will fail to be created.
In general, to avoid the question of precedence, we recommend, if possible,
rewriting your |PermissionsDoc| to eliminate conflicting rules.
To keep backwards compatibility with existing |CONNEXT| 6.1.0 |DPs|
that cannot update their |PermissionsDoc|, release 6.1.1/6.1.2 will, by default,
automatically apply the preference order based on the version of the |DP|
associated with the |PermissionsDoc|. This behavior can be changed through
the new ``com.rti.serv.secure.access_control.use_610_permissions_rules_precedence``
property, which supports the following values:
- auto (default): use the last applicable rule if the |DP|'s version is
known to use the last applicable rule (e.g., for release 6.1.0 or below),
and use the first applicable rule otherwise.
- false: always use the first applicable rule.
- true: always use the last applicable rule.
Note that the default behavior may change in future releases of |CONNEXT|.
.. SEC-850
.. _section-security-sec-1820:
Failure loading certificates due 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.
In that release, |DP| creation did not fail if you enforced key usage
extension and the certificate of the Identity or Permissions CAs was missing the
keyCertSign attribute, although |DP| creation should have failed in this case.
(See :ref:`section-security-sec-898` in the 6.0.1 section.)
In release 6.1.1, |DP| creation now fails in this case,
with a message similar to the following:
.. code-block:: text
[CREATE DP] RTI_Security_CertHelper_loadCertsCrls:!keyCertSign in keyUsage X.509 v3 extension. Subject name: [...]
To prevent |DP| creation failure, add keyCertSign as part of the allowed uses
in the keyUsage variable of the CA's configuration file. For example:
.. code-block:: text
keyUsage = cRLSign, keyCertSign
See the :link_release_notes_sec_612:`Security Plugins Release Notes 6.1.2 <>`
for more information on the fix, "Creation of secure DomainParticipant did not
fail as expected when its Certificate Authority was missing keyCertSign" (SEC-1820).
.. SEC-1820 and MG-142