Hide Forgot
Created attachment 1205043 [details] Logs Description of problem: This test is further extension to BZ https://bugzilla.redhat.com/show_bug.cgi?id=1329365. Here we are testing the Authority Key Identifier and subject key identifier as mentioned in :: 1. http://pki.fedoraproject.org/wiki/Custom_Installation(Adding generic system certificate request extension) 2. http://pki.fedoraproject.org/wiki/Certificate_Extensions#CA_Signing_CSR_Extensions Version-Release number of selected component (if applicable): pki 10.3.3.10 How reproducible: always Steps to Reproduce: 1. Used step1.cfg to run first step. 2. Try to add additional parameters in CS.cfg(/etc/pki).I tried to add for authority key identifier. preop.cert.AKI.ext.oid=1.3.6.1.4.1.311.20.9 preop.cert.AKI.ext.data=1E0A00530075006200430041 preop.cert.AKI.ext.critical=true 3. Use openssl to sign csr. $ openssl x509 -req -in ca_signing.csr -CA rootca.pem -CAkey rootca.key -CAcreateserial -out ca_signing.pem 4. Perform step2 to do final installation. 5. Installation went fine but when tried to access EE amd agent pages so got below exception. java.io.IOException: CS server is not ready to serve. com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:445) javax.servlet.http.HttpServlet.service(HttpServlet.java:731) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) Actual results: Pki installation doesn't show any exception .When tried to open EE page it shows java.io.IOException: CS server is not ready to serve. com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:445) javax.servlet.http.HttpServlet.service(HttpServlet.java:731) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) Expected results: Installation should go fine and it should support all extensions well . ExternalCA signed using using openssl with additional extensions should work. Additional info: Note :: all the files/logs and screenshots are attached.
Created attachment 1205044 [details] Failure_Screenshot
Created attachment 1205045 [details] step1.cfg
Created attachment 1205046 [details] step2.cfg
Hi, The <tag> in preop.cert.<tag>.ext.oid actually needs to be one of the certificate IDs listed in <subsystem>.cert.list, so for CA it's either signing, ocsp_signing, sslserver, subsystem, or audit_signing. I've updated the wiki page to clarify this. Could you try again with a valid tag (e.g. signing instead of AKI)? If it still fails please attach the whole debug log (i.e. /var/log/pki/InstallECA/ca/debug). Also currently there's an issue with 2-step installation (bug #1378275) but it's unclear if the reported problem is caused by that bug.
Based on discussion with Endi, we currently support basic extensions like: Keyusage Basic constaint. RFC https://tools.ietf.org/html/rfc5280#page-27 suggest many extensions which can be "MUST" at the same time so we should allow multiple extensions support.
Upstream ticket: https://fedorahosted.org/pki/ticket/2482
Per CS/DS Meeting of 10/04/2016: 7.4
Are we sure the instruction given at http://pki.fedoraproject.org/wiki/Certificate_Extensions#CA_Signing_CSR_Extensions for Generic CSR Extensions where it asked people to put the extension info in CS.cfg is correct? I am only familiar with the sample put in the previous section: CA Signing CSR Extensions where the generic extensions are specified in the pkispawn config instead of CS.cfg Endi did you change the design of this feature?
Yes, the functionality was expanded in this commit: https://git.fedorahosted.org/cgit/pki.git/commit/?id=4950f167d628b04c3859baf512328bff8538bd2d See the changes in createGenericExtensions(). Originally we only supported generic extension on the CA signing cert only with these parameters: * preop.cert.signing.ext.oid * preop.cert.signing.ext.data * preop.cert.signing.ext.critical Now we support generic extensions on all certs with these parameters: * preop.cert.<tag>.ext.oid * preop.cert.<tag>.ext.data * preop.cert.<tag>.ext.critical The two-step installation (http://pki.fedoraproject.org/wiki/Two-Step_Installation) basically allows you to customize the CS.cfg (including adding generic extensions) during installation. Note that even with these changes we are still limited to one generic extension per certificate. To support multiple extensions as Geetika mentioned in comment #6 we probably need something like this: * preop.cert.<tag>.exts.list=0,1,2,... * preop.cert.<tag>.ext.<n>.oid * preop.cert.<tag>.ext.<n>.data * preop.cert.<tag>.ext.<n>.critical
ok, I was not aware of the change. Endi could you please make sure this goes into the document if it hasn't already? Thanks.
I think the support for a single generic extension on all certs is only documented in wiki. Where should we document it (which chapter/section) in RHCS 9.1 docs? Do we need to file a doc ticket? As for this ticket, it will be used to add the support for multiple generic extensions on each cert. I suppose that will be documented later in RHCS 9.2 docs.
Per PKI Bug Council of 04/05/2017: 7.5
Moved to RHEL 7.7.
(In reply to Endi Sukma Dewata from comment #12) > I think the support for a single generic extension on all certs is only > documented in wiki. Where should we document it (which chapter/section) in > RHCS 9.1 docs? Do we need to file a doc ticket? > > As for this ticket, it will be used to add the support for multiple generic > extensions on each cert. I suppose that will be documented later in RHCS 9.2 > docs. Endi, if this has not yet been documented, it probably belongs somewhere in the installation guide.
Two things: 1. Endi, how about create an upstream ticket and 2. Florian, how about making sure it's documented (coordinate with Endi to turn this into doc bz?)
This ticket was already linked upstream in comment #7. In this ticket are we just trying to document the current behavior which only supports 1 extension per certificate, or are we trying to support multiple extensions as described in comment #6 and comment #10, then create a new doc for that?
As per Grooming meeting on 04/21/2020, closing this ticket as UPSTREAM. We have a related upstream ticket to track this: https://pagure.io/dogtagpki/issue/2482