Bug 1464463
| Summary: | Replication fails to start with CBCA (Certificate-Based Client Authentication) while FIPS mode is enabled. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Amita Sharma <amsharma> |
| Component: | 389-ds-base | Assignee: | mreynolds |
| Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
| Severity: | medium | Docs Contact: | Marc Muehlfeld <mmuehlfe> |
| Priority: | medium | ||
| Version: | 7.4 | CC: | amsharma, dueno, hkario, kengert, mreynolds, nkinder, rmeggins, rrelyea, tbordaz |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Comment 2
mreynolds
2017-06-23 14:08:05 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 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 |