Bug 1427798 - Use X509v3 Basic Constraints "CA:TRUE" instead of "CA:FALSE" IPA CA CSR
Summary: Use X509v3 Basic Constraints "CA:TRUE" instead of "CA:FALSE" IPA CA CSR
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.3
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks: 1506526
TreeView+ depends on / blocked
 
Reported: 2017-03-01 09:17 UTC by Thorsten Scherf
Modified: 2018-04-10 16:41 UTC (History)
16 users (show)

Fixed In Version: ipa-4.5.4-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1506526 (view as bug list)
Environment:
Last Closed: 2018-04-10 16:40:25 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0918 None None None 2018-04-10 16:41:35 UTC

Description Thorsten Scherf 2017-03-01 09:17:41 UTC
Description of problem:
When you create a new certificate request using ipa-cacert-manage, the CSR contains a "X509v3 Basic Constraints" attribute "CA" which is set to "FALSE".

Based on RFC2986, the "certification request information" part of the CSR contains a subject distinguished name, a subject public key and optionally a set of attributes.

It's not clear to me why the value of the "CA" attribute is set to "FALSE". IMHO the CSR which is created should supply some information about the intended use case of the certificate. We do need the signing CA to
delegate CA authority to the new CA certificate. To do this, a proper CA profile has to be used to sign the CSR.

While we use the string "CN=Certificate Authority" in the Subject DN, the attribute "CA" set to "FALSE" might give a wrong impression that this cert will be used for an end entity.

I would recommend to change the attribute value to "TRUE".

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 3 Rob Crittenden 2017-07-20 14:53:45 UTC
Can you be more specific about the command-line you're running?

I'm not sure that ipa-cacert-manage generates a new CSR. I think it should use the existing CSR of the already-tracked CA.

Comment 5 Thorsten Scherf 2017-07-25 10:39:11 UTC
To renew an IdM CA certificate, we have the following instructions in the docs [1]:

# ipa-cacert-manage renew --external-ca
# ipa-cacert-manage renew --external-cert-file /root/ca.crt --external-cert-file /root/cacert.pem

When I test this on a clean RHEL-7.3 installation, the CSR created by ipa-cacert-manage (/var/lib/ipa/ca.csr) is indeed identical to the CSR created during the initial certificate request and which is stored in one of the certmonger request files (/var/lib/certmonger/requests/).

$ openssl req -in /var/lib/ipa/ca.csr -noout -text|grep CA
                CA:FALSE

$ openssl req -in request.csr -noout -text|grep CA
                CA:FALSE

What is irritant though is this: I have an IdM self-signed Root-CA which has the isCA constraint set to TRUE:

$ openssl x509 -in /etc/ipa/ca.crt -noout -text|grep CA
                CA:TRUE

IIRC the caCACert profile is used to request this certificate:

$ grep basicConstraintsIsCA /var/lib/pki/pki-tomcat/ca/profiles/ca/caCACert.cfg
policyset.caCertSet.5.constraint.params.basicConstraintsIsCA=true
policyset.caCertSet.5.default.params.basicConstraintsIsCA=true

This looks ok. But when I check the certmonger request file for this certificate, the isCA constraint is set to False:

$ grep cert_nickname /var/lib/certmonger/requests/20170213125736
cert_nickname=caSigningCert cert-pki-ca

I then copied the CSR data blob into req.txt: 

$ openssl req -in req.txt -noout -text|grep CA
                CA:FALSE

This confirms that the isCA constraint is set to FALSE in the CSR - which is wrong I guess.

[1] https://access.redhat.com/solutions/272493

Comment 6 Rob Crittenden 2017-07-25 16:14:41 UTC
IPA/certmonger do not use the dogtag profiles in ipa_cacert_manage.

It looks like IPA is not asking for the CA basic constraint so certmonger isn't including it in the CSR it generates. I think this bug will eventually be moved to IPA but I'll continue investigating to be sure.

Comment 7 Rob Crittenden 2017-07-25 17:36:35 UTC
Ok, confirmed. IPA needs to set template-is-ca to True on cert renewals and the generated CSR will include the CA basic constraint.

They may also want to set template-ca-path-length. As far as I can tell the default is 0 which would mean IPA wouldn't be able to create Sub-CA's.

The signer of the CSR could always change the path length I suppose, depending on their policy.

Comment 8 Thorsten Scherf 2017-07-26 12:26:41 UTC
(In reply to Rob Crittenden from comment #6)
> It looks like IPA is not asking for the CA basic constraint so certmonger
> isn't including it in the CSR it generates. 

Alright, and the reason why the self-signed IPA CA certificate contains the basic constraint is simply because the IPA CA set it although it has not explicitly been requested - I guess.

Comment 9 Rob Crittenden 2017-07-26 13:01:09 UTC
No, the IPA CA cert has the proper extensions because dogtag handles that during installation, not certmonger.

Comment 10 Petr Vobornik 2017-08-04 21:39:16 UTC
Upstream ticket:
https://pagure.io/freeipa/issue/7088

Comment 11 Rob Crittenden 2017-08-31 18:27:46 UTC
Fixed upstream in master: a37e90530fd205604d30213c3410bd5cb9e063cf

Comment 17 Petr Vobornik 2017-10-27 15:40:37 UTC
4.5 backport: https://github.com/freeipa/freeipa/pull/1217

Comment 18 fbarreto 2017-10-27 16:54:47 UTC
Fixed upstream
ipa-4-5:
https://pagure.io/freeipa/c/cae3e592305143941aac005628ccef5e1a1d58c6

Comment 21 Mohammad Rizwan 2017-11-20 09:51:16 UTC
Verified.

Comment 24 errata-xmlrpc 2018-04-10 16:40:25 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:0918


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