Bug 1464463 - Replication fails to start with CBCA (Certificate-Based Client Authentication) while FIPS mode is enabled.
Summary: Replication fails to start with CBCA (Certificate-Based Client Authentication...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
(Show other bugs)
Version: 7.4
Hardware: x86_64 Linux
medium
medium
Target Milestone: rc
: ---
Assignee: mreynolds
QA Contact: Viktor Ashirov
Marc Muehlfeld
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-23 13:41 UTC by Amita Sharma
Modified: 2018-04-10 14:19 UTC (History)
9 users (show)

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 14:18:12 UTC
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 14:19 UTC

Comment 2 mreynolds 2017-06-23 14:08:05 UTC
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 12:25:17 UTC
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 15:56:29 UTC
Turns out this was DNS issue in customer's environment.

Comment 17 mreynolds 2017-10-27 15:57:11 UTC
Ignore last update -that was meant for a different bug

Comment 46 Bob Relyea 2017-11-13 23:52:13 UTC
> 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 18:09:02 UTC
Upstream ticket:
https://pagure.io/389-ds-base/issue/49454

Comment 49 mreynolds 2017-11-16 14:28:42 UTC
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 14:18:12 UTC
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.