Bug 1568615 - ECC installation for non CA subsystems needs improvement
Summary: ECC installation for non CA subsystems needs improvement
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core
Version: 7.5
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Jack Magne
QA Contact: Asha Akkiangady
Marc Muehlfeld
URL:
Whiteboard:
Keywords: TestCaseProvided, ZStream
Depends On:
Blocks: 1581134
TreeView+ depends on / blocked
 
Reported: 2018-04-17 22:57 UTC by Geetika Kapoor
Modified: 2018-10-30 11:08 UTC (History)
7 users (show)

(edit)
Installing Certificate System subsystems with ECC keys no longer fail

Previously, due to a bug in the Certificate System installation procedure, installing a Key Recovery Authority (KRA) with ECC keys failed. To fix the problem, the installation process has been updated to handle both RSA and ECC subsystems automatically. As a result, installing subsystems with ECC keys no longer fail.
Clone Of:
: 1581134 (view as bug list)
(edit)
Last Closed: 2018-10-30 11:07:04 UTC


Attachments (Terms of Use)
Config_details (3.56 KB, text/plain)
2018-04-18 21:28 UTC, Geetika Kapoor
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3195 None None None 2018-10-30 11:08 UTC

Description Geetika Kapoor 2018-04-17 22:57:27 UTC
Description of problem:

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.

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

pki-ca-10.5.1-11.el7.noarch


How reproducible:
always

Steps to Reproduce:
1.Pkispawn of KRA with ECC
2.
3.

Actual results:
 Installation failed with:

[16/Apr/2018:11:25:01][http-bio-21443-exec-3]: CertUtil: content:
{xmlOutput=[true], cert_request_type=[pkcs10],
profileId=[caInternalAuthServerCert],
cert_request=[MIIBYTCB6AIBADBpMR4wHAYDVQQKDBVFeGFtcGxlLXJoY3M5Mi1DQS1lY2MxHzAdBgNVBAsMFmdrYXBvb3JfUkhDUzc1X2tyYS1lY2MxJjAkBgNVBAMMHW5lYnVsYS5sYWIuZW5nLnBucS5yZWRoYXQuY29tMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE2YmkbBQrVVVqNn8fdzIpddrPd5xnnHaVFKt5GUOYDuFtTJ1z+LNi84UNkUBgrkN7iSxx5Z+PSb9M0NEWNCmOgTTTKFtKkIwO4aeCjKQQQex0LZi6LY7J6agW2YlMFdzzoAAwCgYIKoZIzj0EAwMDaAAwZQIxAM2mWAVxC1zbKX3Paw6vd0NHOEHGgUGexgOMd6JeGFRiSQcDxyJJtrdprqYg/pakQAIwSI3DSIPKeg0wBoZkhgqTvNOrVz0Ux7JfwqIDoTX4RyB7Rcfut18TX/ShcoC2bCsV],
requestor_name=[KRA-nebula.lab.eng.pnq.redhat.com-21443],
sessionID=[5350945447035517802]}
[16/Apr/2018:11:25:01][http-bio-21443-exec-3]: ConfigurationUtils:
POST https://nebula.lab.eng.pnq.redhat.com:20443/ca/ee/ca/profileSubmit
[16/Apr/2018:11:25:01][http-bio-21443-exec-3]: Server certificate:
[16/Apr/2018:11:25:01][http-bio-21443-exec-3]:  - subject:
CN=nebula.lab.eng.pnq.redhat.com,OU=gkapoor_RHCS_75_ecc,O=Example-rhcs92-CA-ecc
[16/Apr/2018:11:25:01][http-bio-21443-exec-3]:  - issuer: CN=CA
Signing Certificate,OU=gkapoor_RHCS_75_ecc,O=Example-rhcs92-CA-ecc
[16/Apr/2018:11:25:02][http-bio-21443-exec-3]: CertUtil: status: 3
[16/Apr/2018:11:25:02][http-bio-21443-exec-3]: CertUtil: error:
Request 21 Rejected - Key Type RSA Not Matched
java.io.IOException: Request 21 Rejected - Key Type RSA Not Matched
        at
com.netscape.cms.servlet.csadmin.CertUtil.createRemoteCert(CertUtil.java:103)
        at
com.netscape.cms.servlet.csadmin.ConfigurationUtils.configRemoteCert(ConfigurationUtils.java:2725)
        at
com.netscape.cms.servlet.csadmin.ConfigurationUtils.configCert(ConfigurationUtils.java:2591)
        at
org.dogtagpki.server.rest.SystemConfigService.processCert(SystemConfigService.java:484)
        at
org.dogtagpki.server.rest.SystemConfigService.processCerts(SystemConfigService.java:303)
        at
org.dogtagpki.server.rest.SystemConfigService.configure(SystemConfigService.java:166)
        at
org.dogtagpki.server.rest.SystemConfigService.configure(SystemConfigService.java:101)

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.

Comment 3 Christina Fu 2018-04-18 16:00:14 UTC
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?

Comment 4 Christina Fu 2018-04-18 16:47:38 UTC
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.

Comment 5 Geetika Kapoor 2018-04-18 21:28 UTC
Created attachment 1423791 [details]
Config_details

Comment 6 Geetika Kapoor 2018-04-18 21:30:31 UTC
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

Comment 7 Christina Fu 2018-04-18 22:08:59 UTC
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!

Comment 8 Geetika Kapoor 2018-04-19 14:21:26 UTC
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

Comment 9 Geetika Kapoor 2018-04-19 16:56:09 UTC
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@redhat.com
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',

Comment 10 Matthew Harmsen 2018-04-20 02:25:03 UTC
 Per RHEL 7.5.z/7.6/8.0 Triage:  7.5.z

Comment 12 Christina Fu 2018-05-16 00:44:18 UTC
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."

Comment 13 Christina Fu 2018-05-17 00:28:49 UTC
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.

Comment 14 Geetika Kapoor 2018-05-17 10:12:59 UTC
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?

Comment 15 Jack Magne 2018-05-21 18:25:02 UTC
Checkin upstream to 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

Comment 20 Amol K 2018-08-16 13:12:49 UTC
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.

Comment 22 errata-xmlrpc 2018-10-30 11:07:04 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-2018:3195


Note You need to log in before you can comment on or make changes to this bug.