On Tue, Jun 14, 2016 at 03:21:24PM +0200, Martin Babinsky wrote: > On 06/14/2016 04:55 AM, Fraser Tweedale wrote: > > On Tue, Jun 14, 2016 at 02:19:27AM +1000, Fraser Tweedale wrote: > > > On Mon, Jun 13, 2016 at 04:35:54PM +0200, Martin Babinsky wrote: > > > > > > > > > > > > > > Hi Fraser, > > > > > > > > > > > > > > during functional review I found the following issues: > > > > > > > > > > > > > > 1.) > > > > > > > > > > > > > > If I create a CAACL rule tied to a specific sub-CA let's say for > > > > > > > user > > > > > > > certificate issuance: > > > > > > > > > > > > > > """ > > > > > > > ipa caacl-show user_cert_issuance > > > > > > > Enabled: TRUE > > > > > > > User category: all > > > > > > > CAs: user_sub_ca > > > > > > > Profiles: caIPAuserCert > > > > > > > ACL name: user_cert_issuance > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > I can still happily request certificate for a user using root-CA: > > > > > > > > > > > > > > """ > > > > > > > ipa cert-request cert.csr --principal jdoe --ca ipa > > > > > > > Certificate: MIID9j.../Ov8mkjFA== > > > > > > > Subject: CN=jdoe,O=IPA.TEST > > > > > > > Issuer: CN=Certificate Authority,O=IPA.TEST > > > > > > > ... > > > > > > > """ > > > > > > > > > > > > > > should not this be denied by CA-ACL rule? > > > > > > > > > > > > > > The default IPA CAACL rule is like this: > > > > > > > > > > > > > > """ > > > > > > > ipa caacl-show hosts_services_caIPAserviceCert > > > > > > > Enabled: TRUE > > > > > > > Host category: all > > > > > > > Service category: all > > > > > > > Profiles: caIPAserviceCert > > > > > > > ACL name: hosts_services_caIPAserviceCert > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > so the default rule should not allow users to request certs at > > > > > > > all. > > > > > > > > > > > > > Yes, these should be denied. Looking into it. > > > > > > > > > > > Were you using 'admin' account to request the cert? admin has > > > > > permission 'Request Certificate ignoring CA ACLs' via the > > > > > 'Certificate Manager' privilege. > > > > > > > > > > If so, please try again with less privileges (e.g. self-service as > > > > > jdoe). > > > > > > > > > > > > > You were right when I was requesting certs as user principals themselves > > > > everything worked as expected. > > > > > > > > Regarding usb-CAs not present on replica, both machines run the > > > > following > > > > version of dogtag CA: > > > > > > > > pki-ca-10.3.2-3.fc24.noarch > > > > > > > > Here are the last 256 lines of the debug log: > > > > > > > > http://paste.fedoraproject.org/378512/65828332 > > > > > > > Thanks for that. It seems there are two issues. The first one is: > > > > > > Unable to read key retriever class from CS.cfg: Property > > > features.authority.keyRetrieverClass missing value > > > > > > This happens only on replica, until the first restart of Dogtag > > > after installation. I have attached a patch to fix it. > > > > > > The second issue is: > > > > > > Failed to update certificate > > > <stack trace> > > > > > > This needs to be fixed in Dogtag, however, the error is not > > > triggered if the key retrieval succeeds when the replica first > > > observes the addition of a new CA. The attached patch does help in > > > this regard, so apply it and I hope it will see you through the rest > > > of the functional testing of my patches... I hope. > > > > > > Thank you for testing! > > > > > > Cheers, > > > Fraser > > > > > Rebased patches attached (VERSION conflicts; no other changes). > > > > Thanks Fraser, > > the certificate issuance by sub-CA now works also on replica but I must > first restart PKI for it to pick up stuff from master CA. > > If I set up a replica first and then create a sub-CA on master Dogtag picks > this up and uses the new sub-CA and its key for signing without restart. > > This seems to be pure Dogtag issue, however and I concluded that IPA side > works ok. > > If no one objects then I would give functional ACK to your patches and > document/track the Dogtag issue in a separate ticket. > Thanks Martin,
The Dogtag ticket is https://fedorahosted.org/pki/ticket/2359. Fix is merged and will go out in 10.3.3 this week or early next week. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code