Christina Fu 2018-06-07 20:21:50 EDT

commit 8cf6b5b2ac6da169f1c63341159faebc09580798 (HEAD -> DOGTAG_10_5_BRANCH, origin/DOGTAG_10_5_BRANCH, gerrit/DOGTAG_10_5_BRANCH)
Author: Christina Fu <cfu>
Date:   Mon Jun 4 16:47:57 2018 -0700

    Ticket 3033 CRMFPopClient tool - should allow option to do no key archival
    
    This patch allows key transport cert file to not be specified, which would
    then not include key archive option in the CRMF request.
    
    fixes https://pagure.io/dogtagpki/issue/3033
    
    Change-Id: Ib8c585c15057684aa049632d8eb67c2827d7e774

Test procedure:

Case 1:
run CRMFPopClient per any existing test cases but leave out the 
 -b <transport cert file name>
and expect no key archival (check on KRA to verify)

Case 2:
run CRMFPopClient per any existing test cases with
 -b <transport cert file name>
and expect key archival (this is to make sure the tool didn't break existing feature)

Note:
If there have been test cases that do not specify
 -b <transport cert file name>
but expects default file name and still do key archival, it will no longer
work that way.

Hi Christina,

Could you please provide more information on which profiles needs to tested in priority from a customer perspective with the changes in this build? With the limited testing time we have I wanted to test high priority scenarios.

since this is a Gossamer-requested "feature" (for CC evaluation), how about just do CMC self-signed case (ask Geetika for it) with caFullCMCSelfSignedCert ?

[root@auto-hv-01-guest10 ecc_cert_db]# rpm -q pki-ca
pki-ca-10.5.1-13.1.el7_5.noarch
[root@auto-hv-01-guest10 ecc_cert_db]# rpm -qi pki-ca
Name        : pki-ca
Version     : 10.5.1
Release     : 13.1.el7_5
Architecture: noarch
Install Date: Mon 11 Jun 2018 05:10:04 PM EDT
Group       : System Environment/Daemons
Size        : 2451424
License     : GPLv2
Signature   : (none)
Source RPM  : pki-core-10.5.1-13.1.el7_5.src.rpm
Build Date  : Mon 11 Jun 2018 11:08:38 AM EDT
Build Host  : ppc-016.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - Certificate Authority

The following scenarios were tested:

1. non-ECC and non-CMC certificates were generated successfully when only CA was installed and CRMFPopClient was used without -b option. Profiles tested were caEncUserCert, caServerCert, caUserCert

2. non-ECC and CMC certificates were generated successfully when only CA was installed and CRMFPopClient was used without -b option. Profiles tested were caFullCMCSelfSignedCert.

3. non-ECC and non-CMC certificates were generated successfully when CA and KRA was installed and CRMFPopClient was used without -b option. Profiles tested were caEncUserCert, caServerCert, caUserCert. No Key generated on KRA.

4. non-ECC and CMC certificates were generated successfully when CA  and KRA was installed and CRMFPopClient was used without -b option. Profiles tested were caFullCMCSelfSignedCert. No Key generated on KRA.

5. non-ECC and non-CMC certificates were generated successfully when CA and KRA were installed and CRMFPopClient was used with -b option. Profiles tested were caEncUserCert, caServerCert, caUserCert. Key generation was successful.

6. non-ECC and CMC certificates were generated successfully when CA  and KRA was installed and CRMFPopClient was used with -b option. Profiles tested were caFullCMCSelfSignedCert. Key archival was successful.

All of the above tested ran successfully on ECC environment as well.

doc text looks good.

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/RHSA-2018:1979