Hide Forgot
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.
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@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',
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@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
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