[Freeipa-devel] [PATCH] 0059..0064 Lightweight sub-CAs

[Fraser Tweedale]

On Wed, Jun 15, 2016 at 07:30:26AM +0200, Jan Cholasta wrote:
> 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.
> 
Thanks; I've made note of this on the tracking etherpad:
http://idm.etherpad.corp.redhat.com/rhel73-cert-mgmt-progress

Design page has also been updated to clarify some command args, etc,
and add Certmonger details.