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:
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.
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:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
