Bug 1379542

Summary: RFE::Failures while adding extra extensions in ExternalCA
Product: Red Hat Enterprise Linux 8 Reporter: Geetika Kapoor <gkapoor>
Component: pki-coreAssignee: RHCS Maintainers <rhcs-maint>
Status: CLOSED UPSTREAM QA Contact: Asha Akkiangady <aakkiang>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.3CC: cfu, dmoluguw, edewata, mharmsen
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-21 18:13:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Logs
none
Failure_Screenshot
none
step1.cfg
none
step2.cfg none

Description Geetika Kapoor 2016-09-27 05:20:01 UTC
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.

Comment 1 Geetika Kapoor 2016-09-27 05:20:44 UTC
Created attachment 1205044 [details]
Failure_Screenshot

Comment 2 Geetika Kapoor 2016-09-27 05:21:04 UTC
Created attachment 1205045 [details]
step1.cfg

Comment 3 Geetika Kapoor 2016-09-27 05:21:25 UTC
Created attachment 1205046 [details]
step2.cfg

Comment 4 Endi Sukma Dewata 2016-09-27 15:14:52 UTC
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.

Comment 6 Geetika Kapoor 2016-09-27 19:21:33 UTC
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.

Comment 7 Matthew Harmsen 2016-09-27 21:36:08 UTC
Upstream ticket:
https://fedorahosted.org/pki/ticket/2482

Comment 8 Matthew Harmsen 2016-10-04 20:40:59 UTC
Per CS/DS Meeting of 10/04/2016: 7.4

Comment 9 Christina Fu 2016-12-12 22:26:19 UTC
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?

Comment 10 Endi Sukma Dewata 2016-12-12 23:18:47 UTC
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

Comment 11 Christina Fu 2016-12-13 17:01:29 UTC
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.

Comment 12 Endi Sukma Dewata 2016-12-15 17:32:14 UTC
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.

Comment 13 Matthew Harmsen 2017-04-06 21:24:18 UTC
Per PKI Bug Council of 04/05/2017:   7.5

Comment 14 Matthew Harmsen 2018-07-04 00:08:23 UTC
Moved to RHEL 7.7.

Comment 15 Christina Fu 2020-02-07 23:34:17 UTC
(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.

Comment 16 Christina Fu 2020-03-02 22:50:22 UTC
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?)

Comment 17 Endi Sukma Dewata 2020-03-03 00:24:13 UTC
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?

Comment 18 Dinesh Prasanth 2020-04-21 18:13:44 UTC
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