On 15.6.2016 04:02, Fraser Tweedale wrote:
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:


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

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:


Here are the last 256 lines of the debug log:


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!


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.

Pushed to master: f0915e61986f545ad9b282fa90a4b1d0538829c5

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.

Once released, please send a patch bumping the minimum version in our spec file. I'm leaving https://fedorahosted.org/freeipa/ticket/4559 open until the patch is merged.

Jan Cholasta

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to