dogtagpki

#2996 ECC installation for non CA subsystems needs improvement
Closed: fixed Opened by mharmsen.

Closed: fixed
Reopen Issue

gkapoor reported:

Missing profiles for subsystem and server certs for ECC non ca subsystem(/usr/share/pki/kra/conf/).Similar profiles do exist under /usr/share/pki/ca/conf/

ls -al /usr/share/pki/ca/conf/EC
-rw-r--r--. 1 root root 1696 Apr 9 19:45 /usr/share/pki/ca/conf/ECadminCert.profile
-rw-r--r--. 1 root root 1719 Apr 9 19:45 /usr/share/pki/ca/conf/ECserverCert.profile
-rw-r--r--. 1 root root 1713 Apr 9 19:45 /usr/share/pki/ca/conf/ECsubsystemCert.profile

Also, only CA section in default.cfg talks about these profiles no such section is mentioned under KRA.

Steps to Reproduce:

Pkispawn of KRA with ECC

Actual results:

Installation failed

Expected results:

Installation should work

Additional info:

Workaround's that i did to make it work
I did some round of changes for KRA and now it is working.But yes I think those needs to be documented.
So what i did I did 2 step installation for KRA.After step1 i change the profile for subsystem cert,server cert and admin cert and later proceed with step2 install. ==> Will raise a BZ for this as mentioned.
Also, I have one question to ask. So what i did i did some changes in here i.e /usr/share/pki/kra/conf/CS.cfg
[root@csqa4-guest04 75_cfg_working]# grep "profile" /usr/share/pki/kra/conf/CS.cfg
preop.admincert.profile=caECAdminCert
preop.cert.audit_signing.profile=caInternalAuthAuditSigningCert
preop.cert.storage.profile=caInternalAuthDRMstorageCert
preop.cert.transport.profile=caInternalAuthTransportCert
preop.cert.sslserver.profile=caECInternalAuthServerCert
preop.cert.subsystem.profile=caECInternalAuthSubsystemCert
preop.hierarchy.profile=caCert.profile
So after step 1 install where i did  : pkispawn -s KRA -f kra.ecc -vvvv --skip-configuration
Subsystem profile is picked correctly i.e :::caECInternalAuthSubsystemCert
[root@csqa4-guest04 75_cfg_working]# grep "InternalAuthSubsystemCert" /etc/pki/gkapoor_RHCS75_kra-ecc/kra/CS.cfg
preop.cert.subsystem.profile=caECInternalAuthSubsystemCert
Later after i did step 2 install where i did: pkispawn -s KRA -f kra.ecc -vvvv --skip-installation
grep "InternalAuthSubsystemCert" /etc/pki/gkapoor_RHCS75_kra-ecc/kra/CS.cfg
preop.cert.subsystem.profile=caInternalAuthSubsystemCert
Basically, it reverted back to original value. So I did some manipulations and make it work but i feel this all needs to be documented.
AT the end it was going to caAdminCert profile so i add ECC profile in place of RSA to make it work and restart CA after all these changes.

Metadata Update from @mharmsen:
- Custom field component adjusted to None
- Custom field feature adjusted to None
- Custom field origin adjusted to None
- Custom field proposedmilestone adjusted to None
- Custom field proposedpriority adjusted to None
- Custom field reviewer adjusted to None
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1568615
- Custom field type adjusted to None
- Custom field version adjusted to None

Per 10.5.x/10.6 Triage: 10.5

Metadata Update from @mharmsen:
- Issue assigned to edewata

Metadata Update from @mharmsen:
- Issue priority set to: blocker (was: major)

QE considers this a blocker

Checkin master:

commit 94e0a563633609401777cfddd3cf16265eeafa20 (HEAD -> master, origin/master, origin/HEAD)
Author: Jack Magne jmagne@redhat.com
Date: Wed May 16 15:28:38 2018 -0700

Fix  #2996 ECC installation for non CA subsystems needs improvement.
The problem is that the installation of say a KRA, which is ECC enabled fails out of the box.
This is due to the fact that the internal cert profiles for the following certificates is incorrect:
1. sslserver cert
2. subsystem cert
3. admin cert
In the ECC case there is some hard coding that references the well known cert profiles for RSA versions of the above certs.
What we need in the ECC case is a way to correctly select the ECC versions of the above profiles.
Therefore this fix does the following:
1. Makes the selection of either the ECC version or the RSA version of the above internal cert profiles based on the key type, ecc or rsa. This solution relies upon well known profile names, but can be modified in the future to be more customizable , should the need arise.
2. I found a related problem when trying to create a ECC enabled KRA in a SHARED instance scenario. There was some final cloning related config code that was grossly RSA specific and throws exceptions when ECC is involved. I altered this piece of code to skip over the bad things with ECC and let the RSA case run unimpeded. We may need further refinement for the ECC case, but I felt this was needed to allow something like an ECC kra to be installed in a shared instance scenario.
Change-Id: I192dc18e50c87403624dd46754c5f22bc988d9a7

Metadata Update from @jmagne:
- Issue assigned to jmagne (was: edewata)

Metadata Update from @jmagne:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.5.8 (was: 10.5)

Metadata Update from @mharmsen:
- Custom field fixedinversion adjusted to pki-core-10.5.8-1.fc27

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/3114

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.
Metadata
None
None
None
Lowest
None
None
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.