Hi Christina,

You're probably more familiar with this area. I noticed that the
caAdminCert and the caECAdminCert profiles in CA's CS.cfg are pointing
to the same configuration file that contains an RSA key constraint.

https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/ca/shared/conf/CS.cfg#L1102-L1105

profile.caAdminCert.class_id=caEnrollImpl
profile.caAdminCert.config=[PKI_INSTANCE_PATH]/[PKI_SUBSYSTEM_TYPE]/profiles/ca/caAdminCert.cfg
profile.caECAdminCert.class_id=caEnrollImpl
profile.caECAdminCert.config=[PKI_INSTANCE_PATH]/[PKI_SUBSYSTEM_TYPE]/profiles/ca/caAdminCert.cfg

https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/ca/shared/profiles/ca/caAdminCert.cfg#L32-L35

policyset.adminCertSet.3.constraint.class_id=keyConstraintImpl
policyset.adminCertSet.3.constraint.name=Key Constraint
policyset.adminCertSet.3.constraint.params.keyType=RSA
policyset.adminCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096

I'm not sure how it works on RHEL 7 but on RHEL 8 the caECAdminCert
profile rejects KRA admin's ECC cert request because of this constraint.

If I change the caECAdminCert profile to use caECAdminCert.cfg instead
it will load the ECC key constraint:

https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/ca/shared/profiles/ca/caECAdminCert.cfg#L32-L35

policyset.adminCertSet.3.constraint.class_id=keyConstraintImpl
policyset.adminCertSet.3.constraint.name=Key Constraint
policyset.adminCertSet.3.constraint.params.keyType=-
policyset.adminCertSet.3.constraint.params.keyParameters=nistp256,nistp384,nistp521

and the KRA installation will complete successfully.
Could you take a look? Thanks.

Sorry, I should have linked the files in the master (10.8) branch:

* https://github.com/dogtagpki/pki/blob/master/base/ca/shared/conf/CS.cfg#L1086-L1089
* https://github.com/dogtagpki/pki/blob/master/base/ca/shared/profiles/ca/caAdminCert.cfg#L32-L35
* https://github.com/dogtagpki/pki/blob/master/base/ca/shared/profiles/ca/caECAdminCert.cfg#L32-L35

Regardless, the above sections are identical in master and 10.5 branch.

Endi, Christina,

I was able to install it but i need to do some tweaks in https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/ca/shared/profiles/ca/caECAdminCert.cfg#L32-L35. 
I did add ECC in keytype and when i did restart it was again picking RSA. Restart was somehow not picking the changes and it was still showing RSA so changing from admin console to ECC worked and later installation also passed. I was not sure why changes in profile file and restart didn't pick the changes. Does registry needs to be refreshed or something?

Thanks

1. Shalini, I have trouble understanding your step 2 and 3.  In step 2, you said "Try installing kra in ECC mode with mentioned ecc configurations in attached kra.cfg file.", but you didn't say what happened there.  Was it successful?  If not, what was the debug info?
  Then in step 3, you said you commented out the ec params in the kra's pkispawn file and tried again.  So here you are trying to get an RSA admin cert for an EC environment?  Is this a negative case?

2. Endi and Geetika, the profiles gets automatically switched depending on the key type:
https://github.com/dogtagpki/pki/blob/master/base/server/src/com/netscape/cms/servlet/csadmin/Configurator.java#L2421-L2425
As you can see, we did that for startup profiles;  That's what Jack and I discussed and agreed on at the time.  He implemented that.

Does that help?

Christina, yes, KRA will submit a request to caAdminCert or caECAdminCert profile based
on that code. However, as shown above both of these profiles point to the same RSA profile
configuration file, so ECC request to caECAdminCert will always be rejected.

I was wondering if it's simply a typo in CS.cfg or if there's other logic that I'm not
aware of. I'm also curious how the code works in RHEL 7 since the parts shown above are
identical in RHEL 7 and 8.

Christina it is going to right profile if ecc is slected ..No doubt on that part. Request is going to caECAdminCert profile 
But even after making keytype as ECC in caECAdminCert profile and restarting CA , it was giving Key mismatch error but as soon as i make ECC from admin console same change for caECAdminCert profile  it worked.

Jack, any idea about this?

Christina, As i mentioned in actual and expected output:

Step 2 is failing and expected to be success. : debug logs are also attached [ KRA failure debug log ] .
Step 3 is Success and working as expected. : This is a positive scenario. Just admin-cert in KRA installation is RSA, rest all certs are ECC. Similar scenario is mentioned in below documentation:
https://github.com/dogtagpki/pki/blob/master/docs/installation/Installing_KRA_with_ECC.md

When I try to have an ECC admin-cert during KRA installation, There is failure with following exception [Step2] .
""" java.io.IOException: Unable to generate admin certificate: Request 24 Rejected - Key Type RSA Not Matched """

The code has been updated upstream:
* master (10.8) branch: https://github.com/dogtagpki/pki/commit/84c039e9d93794df118e926c24aacf1da8fd166e
* 10.5 branch: https://github.com/dogtagpki/pki/commit/848946c07b4d67e27cfd8128bc7409e0db9983cd

I have added the RHEL 8 build into the errata.

Please note that there are 2 options for the admin cert during KRA installation:
1. Import an existing admin cert (pki_import_admin_cert=True). This is the default.
2. Request a new admin cert from the CA (pki_import_admin_cert=False)

The first scenario seems to be working fine, but the second scenario
is failing with ECC key type due to the incorrect path explained above.

Here's a sample deployment configuration to test scenario #2:

[KRA]
pki_import_admin_cert=False

pki_admin_email=kraadmin
pki_admin_name=kraadmin
pki_admin_nickname=kraadmin
pki_admin_password=Secret.123
pki_admin_uid=kraadmin

pki_admin_key_type=ecc
pki_admin_key_algorithm=SHA256withEC
pki_admin_key_size=nistp256

KRA installation worked with ECC admin cert. Following is the build on which testing is performed:

pki-tools-10.8.3-1.module+el8.2.0+5925+bad5981a.x86_64
pki-servlet-engine-9.0.7-16.module+el8.1.0+3366+6dfb954c.noarch
python3-pki-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch
pki-servlet-4.0-api-9.0.7-16.module+el8.1.0+3366+6dfb954c.noarch
pki-server-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch
pki-base-java-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch
pki-ca-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch
pki-kra-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch
pki-symkey-10.8.3-1.module+el8.2.0+5925+bad5981a.x86_64
pki-base-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch

jss-4.6.2-3.module+el8.2.0+5925+bad5981a.x86_64
tomcatjss-7.4.1-2.module+el8.2.0+4573+c3c38c7b.no

Marking this bugzilla verified.

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-2020:1644

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days