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.

--
Martin^3 Babinsky

--
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

Reply via email to