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: VERIFIED
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
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-23 09:41 EDT by Amita Sharma
Modified: 2018-01-03 06:05 EST (History)
9 users (show)

See Also:
Fixed In Version: 389-ds-base-1.3.7.5-10.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-10-27 11:56:29 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)

  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.

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