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?

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

Turns out this was DNS issue in customer's environment.

Ignore last update -that was meant for a different bug

> 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);
       .
       .
       .

Upstream ticket:
https://pagure.io/389-ds-base/issue/49454

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.

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