Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1464463 - Replication fails to start with CBCA (Certificate-Based Client Authentication) while FIPS mode is enabled.
Replication fails to start with CBCA (Certificate-Based Client Authentication...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
7.4
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: mreynolds
Viktor Ashirov
Marc Muehlfeld
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-23 09:41 EDT by Amita Sharma
Modified: 2018-04-10 10:19 EDT (History)
9 users (show)

See Also:
Fixed In Version: 389-ds-base-1.3.7.5-10.el7
Doc Type: Bug Fix
Doc Text:
Replication now works correctly with TLS client authentication and FIPS mode enabled Previously, if you used TLS client authentication in a Directory Server replication environment with Federal Information Processing Standard (FIPS) mode enabled, the internal Network Security Services (NSS) database token differed from a token on a system with FIPS mode disabled. As a consequence, replication failed. The problem has been fixed, and as a result, replication agreements with TLS client authentication now work correctly if FIPS mode is enabled.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 10:18:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0811 None None None 2018-04-10 10:19 EDT

  None (edit)
Comment 2 mreynolds 2017-06-23 10:08:05 EDT
This is a known issue with nss (I don't think the fix has been released yet), what version of NSS is on your test system?
Comment 15 thierry bordaz 2017-06-27 08:25:17 EDT
Hi Hubert, there are few documents describing this bind method:
You may have a look at https://access.redhat.com/documentation/en-us/red_hat_directory_server/9.0/html/administration_guide/managing_replication-configuring-replication-cmd#Configuring-Replication-ReplAgmt-cmd (search for nsds5replicabindmethod sslclientauth)

Also you may have a look at this test case that setup a cert-base client auth https://pagure.io/389-ds-base/blob/master/f/dirsrvtests/tests/tickets/ticket47536_test.py
Comment 16 mreynolds 2017-10-27 11:56:29 EDT
Turns out this was DNS issue in customer's environment.
Comment 17 mreynolds 2017-10-27 11:57:11 EDT
Ignore last update -that was meant for a different bug
Comment 46 Bob Relyea 2017-11-13 18:52:13 EST
> I really don't want to call an external tool from the server's C code to get 
> the server's cert token name.  I was hoping it could be obtained with the 
> PK11 API, I just don't know if it's possible.

If you have a pointer to the PK11SlotInfo *, you can use  PK11_GetTokenName().
If you need the internal slot you can get it with:
PK11_GetInternalSlot() for the crypto slot and PK11_GetInternalKeySlot() for the key/cert database slot. In FIPS mode it will return the same token.


The PK11_GetInternal*Slot() calls return a reference you need to free (PK11_FreeSlot()).

PK11_GetTokenName() returns a const char * which will say around until you free the slot (well until the slot is fully freed, but you know it won't be fully freed as long as you have a reference to it).

      .
      .
      .

    slot = PK11_GetInternalKeySlot();
    if (slot == NULL) {
          /* throw error */
    }
    tokenName = PK11_GetTokenName(slot);
    /* copy or use tokenName */

    PK11_FreeSlot(slot);
       .
       .
       .
Comment 47 mreynolds 2017-11-15 13:09:02 EST
Upstream ticket:
https://pagure.io/389-ds-base/issue/49454
Comment 49 mreynolds 2017-11-16 09:28:42 EST
Hubert,

I did see the code I needed in (nss_engine_pphrase.c).  Bob thanks for the detailed info on using the token name and slot correctly!  This is now fixed upstream on the DS side.
Comment 60 errata-xmlrpc 2018-04-10 10:18:12 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0811

Note You need to log in before you can comment on or make changes to this bug.