Bug 1411428

Summary: Unable to create a CA clone in FIPS
Product: Red Hat Enterprise Linux 7 Reporter: Standa Laznicka <slaznick>
Component: pki-coreAssignee: RHCS Maintainers <rhcs-maint>
Status: CLOSED ERRATA QA Contact: Asha Akkiangady <aakkiang>
Severity: high Docs Contact: Petr Bokoc <pbokoc>
Priority: urgent    
Version: 7.3CC: akahat, edewata, gkapoor, mharmsen, pbokoc
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pki-core-10.4.0-1.el7 Doc Type: Bug Fix
Doc Text:
CA clone installation in FIPS mode no longer fails Previously, installing a CA clone or a Key Recovery Authority (KRA) failed in FIPS mode due to an inconsistency in handling internal NSS token names. With this update, the code that handles the token name has been consolidated to ensure that all token names are handled consistently. T allows the KRA and CA clone installation to complete properly in FIPS mode.
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 22:48:25 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:
Bug Depends On:    
Bug Blocks: 1125174, 1427443    
Attachments:
Description Flags
Install output, configuration, debug and log files none

Description Standa Laznicka 2017-01-09 17:08:39 UTC
Created attachment 1238830 [details]
Install output, configuration, debug and log files

Description of problem:
When trying to set up a clone using pkispawn with the attached configuration in FIPS, pkispawn fails with NoSuchTokenException.

Version-Release number of selected component (if applicable):
10.3.3-16

How reproducible:
Always

Steps to Reproduce:
1. Set up a master server and a future replica to use FIPS.
2. Set up a master CA on a server using pkispawn
3. Try to create a clone of the server from 1. using `pkispawn -s CA -f pkispawn_config_repl.txt`

Actual results:
The installation fails with "org.mozilla.jss.NoSuchTokenException".

Expected results:
The installation of the clone passes.

Additional info:
Might (but does not have to be) be related to https://bugzilla.redhat.com/show_bug.cgi?id=1382066.

Comment 2 Endi Sukma Dewata 2017-01-16 16:36:13 UTC
Hi, in bug #1382066 the code was fixed to recognize the full name of the internal token (i.e. Internal Key Storage Token) which is used in FIPS mode in addition to the short name (i.e. internal):
https://bugzilla.redhat.com/show_bug.cgi?id=1382066#c7

Apparently there are additional places that need to be fixed which are only exposed under this test scenario.

Comment 3 Matthew Harmsen 2017-01-16 17:18:46 UTC
Upstream ticket:
https://fedorahosted.org/pki/ticket/2556

Comment 4 Endi Sukma Dewata 2017-01-26 00:27:36 UTC
*** Bug 1412132 has been marked as a duplicate of this bug. ***

Comment 5 Endi Sukma Dewata 2017-01-27 16:58:32 UTC
Fixed in master:
* 2fa7bc707a558da1b0c4d748d0805bdd0b60168c

Comment 7 Amol K 2017-06-08 09:54:08 UTC
I tested this bug on pki 10.4.1-8.el7 version. It worked as expected. 

I follow following steps to verify the bug:

1. Installed CA with dual step installation with modification of sslRangeCiphers in server.xml file.

2. I follow above installation procedure with the clone and I able to create the clone successfully.

Verifying this bug.

Comment 9 errata-xmlrpc 2017-08-01 22:48:25 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-2017:2110