.. include:: /../getting_started/vars.rst

.. _section-Product-Security-611:

|RTI_SP_PRODUCT_HEADING|
************************

The following issues affect backward compatibility in |RTI_SP_PRODUCT| 
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 |SEC_SPEC_11|. 
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

    <deny_rule>
        <domains>
            <id>12</id>
        </domains>
    </deny_rule>
    <allow_rule>
        <domains>
            <id>12</id>
        </domains>
    </allow_rule>

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 |RTI_SP_PRODUCT| 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 |SP_RN| :link_release_notes_sec_612:`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