The default CA (cn=ipa,cn=cas,cn=ca,dc=...) can issue certificates even when it is not enabled by any of the CA ACLs. The ACL for the default certificate profile that is shipped with IPA does not have either the CA member or ca category option, but the CA is usable.
Any other (sub) CA doesn't work unless it satisfies an ACL.
$ ipa caacl-show hosts_services_caIPAserviceCert --all dn: ipaUniqueID=1a63e5e0-39e5-11e6-8885-525400093b00,cn=caacls,cn=ca,dc=test,dc=example,dc=com ACL name: hosts_services_caIPAserviceCert Enabled: TRUE Host category: all Service category: all Profiles: caIPAserviceCert ipauniqueid: 1a63e5e0-39e5-11e6-8885-525400093b00 objectclass: ipaassociation, ipacaacl
This is expected behaviour; if a CA ACL does not reference any CAs, and does not have cacat=all, then it is assumed to refer to the default CA. This is for backwards compatibility with existing CA ACLs, which do not reference any CAs but did (and still do) allow access to IPA CA.
Leaving open for discussion about whether to break compatibility for a more consistent behaviour.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1353995 (Red Hat Enterprise Linux 7)
master:
Metadata Update from @mkubik: - Issue assigned to ftweedal - Issue set to the milestone: FreeIPA 4.4.1
Login to comment on this ticket.