Hide Forgot
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:
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.
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
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.
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.
(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.
No, the IPA CA cert has the proper extensions because dogtag handles that during installation, not certmonger.
Upstream ticket: https://pagure.io/freeipa/issue/7088
Fixed upstream in master: a37e90530fd205604d30213c3410bd5cb9e063cf
4.5 backport: https://github.com/freeipa/freeipa/pull/1217
Fixed upstream ipa-4-5: https://pagure.io/freeipa/c/cae3e592305143941aac005628ccef5e1a1d58c6
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:0918