Bug 1568615

Geetika, could you please attach the exact pkispawn config file that you used to create the KRA instance?
Recall yesterday I pointed out to you that both KRA transport and storage keys need to be RSA.  I assumed that you fixed your pkispawn config and recreated the KRA instance?

wait, Geetika, what version are you testing?  In my tree I do have the following profiles:
caECInternalAuthServerCert.cfg  caECInternalAuthSubsystemCert.cfg

That should be all that matters.  The other profiles should do what they are supposed to do as long as you give the correct key type in the pkispawn config file.
Again, please attach your pkispawn config file so I can take a look.

Created attachment 1423791 [details]
Config_details

Hi Christina,

I have attached config and the Z stream bits that i am using are:

pki-ca-10.5.1-11.el7.noarch
pki-kra-10.5.1-11.el7.noarch

A few pointers:
* make sure things are under the right [] sections. (e.g. I think your admin cert keytype is in wrong section; my wiki and Marc's guidance also point to different sections for some certs!)
Way to check for sure is to man pkispawn;
alternatively look at pki_default.cfg
* audit signing cert should be RSA as well
(basically only ssl server cert and subsystem certs need to use the EC specific ones)
* admin cert should be EC as well (though it's user cert)
* and again, caECInternalAuthServerCert.cfg  caECInternalAuthSubsystemCert.cfg do exist

Please make sure you use a *clean* CA (one without any "workarounds" from before) to test this out ;-).
thanks!

Update:

This is kind of brief update so that we don't miss what we discussed on IRC.
I think we do need some code changes.

Endi, Christina discussed that there could be 2 ways:

in SystemConfigService.java caInternalAuthSubsystemCert is hard coded.
 with the current code in SystemConfigService.java, it basically overwrites the preop.cert.subsystem.profile in step 2
we can move it to step 1 if you want so you can customize it before step 2
SystemCertData class has a keyType attribute, the value can be "ecc"

Ques: how do we want to fix this? (1) make it customizable, (2) hardcode it for rsa & ecc

Configuration files and values picked for admin,subsystem and server cert in pkispawn logs.This can be refer to check my configuration parameters. 
  
[DEFAULT]
pki_instance_name=gkapoor_RHCS75_kra-ecc1
pki_https_port=31443
pki_http_port=31080

#NSS DB Token Password
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM6000-OCS
pki_token_password=SECret.579
pki_subsystem_key_type=ecc
pki_subsystem_key_size=nistp384
pki_subsystem_key_algorithm=SHA384withEC
pki_subsystem_signing_algorithm=SHA384withEC
pki_subsystem_token=NHSM6000-OCS
pki_ssl_server_key_type=ecc
pki_ssl_server_key_size=nistp384
pki_ssl_server_key_algorithm=SHA384withEC
pki_ssl_server_signing_algorithm=SHA384withEC
pki_ssl_server_token=NHSM6000-OCS

#Admin Password
pki_admin_password=SECret.123

#Security Domain
pki_hostname=csqa4-guest04.idm.lab.eng.rdu.redhat.com
#pki_security_domain_name=Example-rhcs92-CA-ecc
pki_security_domain_password=SECret.123
pki_security_domain_https_port=20443
#client Dir
pki_client_dir=/opt/RootCA-KRA
pki_client_database_password=SECret.123
pki_client_pkcs12_password=SECret.123
pki_ds_ldap_port=3389
pki_ds_bind_dn=cn=Directory Manager
pki_ds_password=SECret.123
pki_ds_secure_connection=False
pki_ds_ldaps_port=11636
pki_ds_secure_connection_ca_pem_file=/etc/dirsrv/slapd-secure-ds/ds.crt
pki_ds_remove_data=True
pki_ds_hostname=csqa4-guest04.idm.lab.eng.rdu.redhat.com
pki_admin_key_size=nistp384
pki_admin_keysize=nistp384
pki_admin_key_algorithm=SHA384withEC
pki_admin_key_type=ecc

[Tomcat]
pki_ajp_port=31009
pki_tomcat_server_port=31005

[KRA]
pki_admin_nickname=PKI KRA Administrator
#pki_admin_name=caadmin
#pki_admin_uid=caadmin
#pki_admin_email=example
pki_admin_key_type=ecc
pki_pin=SECret.579
pki_import_admin_cert=False
pki_ds_hostname=csqa4-guest04.idm.lab.eng.rdu.redhat.com
pki_ds_base_dn=dc=RootCA-CA-KRA1
pki_ds_database=RootCA-LDAP-KRA1
pki_import_admin_cert=False



Values Picked in pkispawn logs:
===============================
    'pki_subsystem_key_algorithm': 'SHA384withEC',
    'pki_subsystem_key_size': 'nistp384',
    'pki_subsystem_key_type': 'ecc',
    'pki_subsystem_signing_algorithm': 'SHA384withEC',



    'pki_ssl_server_key_algorithm': 'SHA384withEC',
    'pki_ssl_server_key_size': 'nistp384',
    'pki_ssl_server_key_type': 'ecc',
    'pki_ssl_server_nickname': 'Server-Cert cert-gkapoor_RHCS75_kra-ecc1',
    'pki_ssl_server_signing_algorithm': 'SHA384withEC',
    'pki_ssl_server_subject_dn': u'cn=csqa4-guest04.idm.lab.eng.rdu.redhat.com,ou=gkapoor_RHCS75_kra-ecc1,o=idm.lab.eng.rdu.redhat.com Security Domain',
    'pki_ssl_server_token': 'NHSM6000-OCS',
    'pki_sslserver_cert_path': '/etc/pki/gkapoor_RHCS75_kra-ecc1/kra_sslserver.cert',
    'pki_sslserver_csr_path': '/etc/pki/gkapoor_RHCS75_kra-ecc1/kra_sslserver.csr',
    'pki_sslserver_key_algorithm': 'SHA384withEC',
    'pki_sslserver_key_size': 'nistp384',
    'pki_sslserver_key_type': 'ecc',
    'pki_sslserver_nickname': 'Server-Cert cert-gkapoor_RHCS75_kra-ecc1',
    'pki_sslserver_subject_dn': u'cn=csqa4-guest04.idm.lab.eng.rdu.redhat.com,ou=gkapoor_RHCS75_kra-ecc1,o=idm.lab.eng.rdu.redhat.com Security Domain',
    'pki_sslserver_tag': 'sslserver',
    'pki_sslserver_token': 'NHSM6000-OCS',



    'pki_admin_key_algorithm': 'SHA384withEC',
    'pki_admin_key_size': 'nistp384',
    'pki_admin_key_type': 'ecc',
    'pki_admin_keysize': 'nistp384',
    'pki_admin_name': 'kraadmin',
    'pki_admin_nickname': 'PKI KRA Administrator',
    'pki_admin_password': 'XXXXXXXX',
    'pki_admin_profile_id': 'caAdminCert',

 Per RHEL 7.5.z/7.6/8.0 Triage:  7.5.z

I think for 7.5z, a "quick" fix might do.

Just a quick summary of what I have in mind.
The EC-specific installation profiles that need to replace the default ones when keytype of the certs are EC are:
caECInternalAuthServerCert.cfg for caInternalAuthServerCert.cfg
caECInternalAuthSubsystemCert.cfg for caInternalAuthSubsystemCert.cfg
and for admin cert
caAdminCert.cfg for caECAdminCert.cfg

I searched in the source for caInternalAuthServerCert, and found it hard-coded in:
server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java 

I searched in the source for caInternalAuthSubsystemCert, and found it hard-coded in:
server/cms/src/org/dogtagpki/server/rest/SystemConfigService.java

I searched in the source for caAdminCert, and found it hard-coded in:
server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java

I'm not familiar with this part of the code.  If we can somehow identify the keytype for each cert at this point, then we can switch between the EC and RSA profiles.
If we can't, then I guess we will just have to go with Endi's "full solution."

another thing that could be tried is when a CA is determined to be ECC, then during the installation, copy the caECInternalAuth*.cfg to the caInternalAuth*.cfg.
Maybe in source, copy the current caInternalAuth*.cfg to caRSAInternalAuth*.cfg so they are not lost after the EC ones are copied over.

After the CA is installed, all subsystems under that CA would automatically get the EC ones.

I thought of sharing my views too..:)

So we basically have to deal with :

preop.admincert.profile=caECAdminCert
preop.cert.sslserver.profile=caECInternalAuthServerCert
preop.cert.subsystem.profile=caECInternalAuthSubsystemCert

1. preop.admincert.profile 
we can set in /usr/share/pki/kra/conf/CS.cfg or as pki_admin_profile_id in pkispawn file and it is getting picked correctly.
So I guess we can do this without code change.

2. preop.cert.sslserver.profile 
we can set in /usr/share/pki/kra/conf/CS.cfg  and it is getting picked correctly. so it never get changed at any point of time.
So i guess we can do this without code change.

3. preop.cert.subsystem.profile 
we can set it /usr/share/pki/kra/conf/CS.cfg  like we did for above two. 
So we did pkispawn step 1 install.

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

Basiaclly it reverts to hardcoded value.

So subsystem cert reverts to it's original value. Rest others maintain their values whatever we assign them in CS.cfg.
in SystemConfigService.java caInternalAuthSubsystemCert is hard coded.So I guess if we remove this fixed values it should be working.

-- So do you think just fixing the third one would solve all problems?

Checkin upstream to master:

commit 94e0a563633609401777cfddd3cf16265eeafa20 (HEAD -> master, origin/master, origin/HEAD)
Author: Jack Magne <jmagne>
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

I tested this Bugzilla on the version 10.5.9-5.el7.

As test procedure mention by Jack in comment #6, I'm able to install CA and KRA.

I enroll certificate and key got archived. I tried OCSP and TKS subsystems installation and it was successful.

Marking this Bugzilla as 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/RHBA-2018:3195