Back to bug 1378209

Who When What Removed Added
Noriko Hosoi 2016-10-21 21:27:57 UTC Priority unspecified high
Severity unspecified high
Ellen Newlands 2016-10-24 16:20:14 UTC CC enewland
Marc Sauton 2016-10-25 00:54:43 UTC CC msauton
Marc Sauton 2016-10-25 00:58:42 UTC Priority high urgent
Severity high urgent
Noriko Hosoi 2016-10-25 15:51:30 UTC Status NEW POST
CC mreynolds
Assignee nhosoi mreynolds
Flags needinfo?(mreynolds)
Noriko Hosoi 2016-10-25 15:52:41 UTC Status POST NEW
Marcel Kolaja 2016-10-25 17:32:03 UTC Status NEW POST
Flags needinfo?(mreynolds)
Blocks 1388581
Marcel Kolaja 2016-10-25 17:32:33 UTC Keywords ZStream
Noriko Hosoi 2017-01-10 19:02:58 UTC Doc Text Cause: When FIPS mode is enabled on the security database, the token name is changed.

Consequence: This prevents the server from reverse decoding the replication manager's password. Which prevents replication sessions from getting established.

Fix: Instead of getting the key slot from the harded coded token name, call slapd_pk11_getInternalKeySlot() which gets the current slot.

Result: When FIPS mode is enabled on the security database, the replication session over SSL/startTLS successfully establishes the connection.
Doc Type If docs needed, set a value Bug Fix
Noriko Hosoi 2017-01-16 19:54:23 UTC Depends On 1390154
errata-xmlrpc 2017-03-23 15:58:59 UTC Status POST MODIFIED
Fixed In Version 389-ds-base-1.3.6.1-3.el7
Status MODIFIED ON_QA
Marc Muehlfeld 2017-03-29 11:28:23 UTC Blocks 1425952
Doc Text Cause: When FIPS mode is enabled on the security database, the token name is changed.

Consequence: This prevents the server from reverse decoding the replication manager's password. Which prevents replication sessions from getting established.

Fix: Instead of getting the key slot from the harded coded token name, call slapd_pk11_getInternalKeySlot() which gets the current slot.

Result: When FIPS mode is enabled on the security database, the replication session over SSL/startTLS successfully establishes the connection.
In FIPS mode, the "slapd_pk11_getInternalKeySlot()" function is now used to retrieve the key slot for a token

The Red Hat Directory Server previously tried to retrieve the key slot from a fixed token name, when FIPS mode was enabled on the security database. However, the token name can change. If the key slot is not found, Directory Server is unable to decode the replication manager's password and replication sessions fail. To fix the problem, the "slapd_pk11_getInternalKeySlot()" function now uses FIPS mode to retrieve the current key slot. As a result, replication sessions using *SSL* or *STTARTTLS* no longer fail in the described situation.
Amita Sharma 2017-04-25 07:30:24 UTC Status ON_QA VERIFIED
CC amsharma
Lenka Špačková 2017-04-27 18:21:52 UTC Docs Contact mmuehlfe
Amita Sharma 2017-05-16 14:22:52 UTC Status VERIFIED ASSIGNED
Viktor Ashirov 2017-05-18 15:21:30 UTC Status ASSIGNED ON_QA
Depends On 1449195
Amita Sharma 2017-05-24 10:16:20 UTC Status ON_QA VERIFIED
errata-xmlrpc 2017-08-01 21:10:21 UTC Status VERIFIED CLOSED
Resolution --- ERRATA
Last Closed 2017-08-01 17:10:21 UTC
Simon Pichugin 2020-09-13 21:46:58 UTC Link ID Github 389ds/389-ds-base/issues/1968

Back to bug 1378209