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