Bug 1254641

Summary: Remove CSR allowed-extensions restriction
Product: Red Hat Enterprise Linux 7 Reporter: Petr Vobornik <pvoborni>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED ERRATA QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.2CC: ftweedal, ipa-maint, jcholast, ksiddiqu, mkosek, rcritten
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.2.0-5.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 12:05:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
`openssl req' config to produce CSR with esoteric extension
none
console output with verification steps none

Description Petr Vobornik 2015-08-18 14:40:33 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/5205

cert-request decodes CSRs and examines the request extensions.  It
currently only permits the following extensions to appear:

- Subject Key Identifier
- Basic Constraints
- Key Usage
- Extended Key Usage
- Subject Alternative Name

I also have a patch on review that allows the IECUserRoles extension
to appear.

I propose removing these checks.

Rationale:

- No extension is copied from the CSR or otherwise included in the
 final certificate unless using a Dogtag profile that is explicitly
 configured to do so.  The mere presence of a request extension
 does not, on its own, affect the final certificate.

- With the current checks, adding a profile to copy a certain
 esoteric / custom extension from CSR to cert will be ineffective
 unless cert-request knows about it.  This renders custom profiles
 useless for working with such unknown extensions, unless / until
 we add support for them.

- I am not aware of any reason why we should whitelist request
 extensions.  If there are reasons, please enlighten me!

Objection:

- If no error is thrown then the user will naturally expect that the
 extensions requested were added to the cert and then spent a lot of
 time trying to figure out how their CSR is wrong. Reject a cert you
 cannot issue is doing the user a favor.

Counterpoint:

- CAs simply ignore extensions you added if they don't like issuing them.
 There is no commenting of whether you are denied or not.
 
 We can add support of comparing request and resulted cert, if needed,
 but I don't think we should really do a favor in pre-check.

We must make difficult things easier, but not at the expense of
making other difficult things possible.  At the moment, despite
custom profiles, it is not possible to use custom profiles to work
with extensions other than those listed above, without patching
FreeIPA.

Comment 3 Kaleem 2015-10-12 10:34:14 UTC
Please provide the steps to verify this.

Comment 4 Fraser Tweedale 2015-10-13 02:16:40 UTC
You can use the attached `openssl req' config (tweak commonName as required)
to produce a CSR with a formerly-prohibited extension.  Then submit the
request via `ipa cert-request' and ensure that, despite the presence of
an unknown extension, the request succeeds.

Comment 5 Fraser Tweedale 2015-10-13 02:17:55 UTC
Created attachment 1082193 [details]
`openssl req' config to produce CSR with esoteric extension

Comment 6 Kaleem 2015-10-13 09:10:09 UTC
Verified.

IPA Version:
============
[root@dhcp207-115 ~]# rpm -q ipa-server
ipa-server-4.2.0-14.el7.x86_64
[root@dhcp207-115 ~]# 

Please find the attached file for console output.

Comment 7 Kaleem 2015-10-13 09:10:33 UTC
Created attachment 1082311 [details]
console output with verification steps

Comment 8 errata-xmlrpc 2015-11-19 12:05:41 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://rhn.redhat.com/errata/RHBA-2015-2362.html