Re: [Pki-devel] [Freeipa-devel] [DESIGN] Lightweight CA renewal

On 18.6.2016 02:38, Fraser Tweedale wrote: > On Fri, Jun 17, 2016 at 03:21:07PM +0200, Jan Cholasta wrote: > > On 17.6.2016 09:34, Fraser Tweedale wrote: > > > On Mon, May 09, 2016 at 09:35:06AM +0200, Jan Cholasta wrote: > > > > Hi, > > > > > > > > On 6.5.2016 08:01, Fraser Tweedale wrote: > > > > > Hullo all, > > > > > > > > > > FreeIPA Lightweight CAs implementation is progressing well. The > > > > > remaining big unknown in the design is how to do renewal. I have > > > > > put my ideas into the design page[1] and would appreciate any and > > > > > all feedback! > > > > > > > > > > [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal > > > > > > > > > > Some brief commentary on the options: > > > > > > > > > > I intend to implement approach (1) as a baseline. Apart from > > > > > implementing machinery in Dogtag to actually perform the renewal - > > > > > which is required for all the approaches - it's not much work and > > > > > gets us over the "lightweight CAs can be renewed easily" line, even > > > > > if it is a manual process. > > > > > > > > > > For automatic renewal, I am leaning towards approach (2). Dogtag > > > > > owns the lightweight CAs so I think it makes sense to give Dogtag > > > > > the ability to renew them automatically (if configured to do so), > > > > > without relying on external tools i.e. Certmonger. But as you will > > > > > see from the outlines, each approach has its upside and downside. > > > > > > > > I would prefer (3), as I would very much like to avoid duplicating > > > > certmonger's functionality in Dogtag. > > > > > > > > Some comments on the disadvantages: > > > > > > > > * "Proliferation of Certmonger tracking requests; one for each > > > > FreeIPA-managed lightweight CA." > > > > > > > > I don't think this is an actual issue, as it's purely cosmetic. > > > > > > > > * "Either lightweight CA creation is restricted to the renewal master, or > > > > the renewal master must observe the creation of new lightweight CAs and > > > > start tracking their certificate." > > > > > > > > IMO this doesn't have to be done automatically in the initial > > > > implementation. You could extend ipa-certupdate to set up certmonger for > > > > lightweight CAs and have admins run it manually on masters after adding a > > > > new lightweight CA. They will have to run it anyway to get the new > > > > lightweight CA certificate installed in the system, so it should be fine to > > > > do it this way. > > > > > > > I have updated the renew_ca_cert post-save script to perform the > > > database update necessary for CA replicas to pick up the new cert. > > > What remains is the command to tell certmonger to track the CA. > > > > > > You mentioned ipa-certupdate but perhaps ipa-cacert-manage is a > > > better fit, e.g.: > > > > > > ipa-cacert-manage track <CA-ID> > > > > > > It would look up the necessary info (basically just the CA-ID) and > > > set up the certmonger tracking. > > > > No. ipa-cacert-manage updates global configuration in LDAP, whereas > > ipa-certupdate applies the global configuration on the local system. > > Updating certmonger configuration is the latter, hence it should be done in > > ipa-certupdate. > > > > Also, I don't think we should expose (un)tracking certificates by CA ID to > > users, as all our CA certificates should always be tracked. > > > OK, so ipa-certupdate just gets run without arguments on a CA > master, and it ensures that all CA certificates are tracked by > Certmonger. Right. > > Makes sense to me. Thanks for the clarifications. > > > > > > > It could be an error to run the command on other than the renewal > > > master. > > > > Note that the main CA certificate is tracked on all CA servers, not just the > > renewal master, otherwise it wouldn't get updated on the other CA servers > > after renewal. I would think the same needs to be done for lightweight CA > > certificates, unless there is a different mechanism for distributing the > > certificates to other CA masters, in which case I would prefer if the > > mechanism was also used for the main CA certificate. > > > There is a different mechanism that causes other CA masters to > update their NSSDBs with the new certificate. After the renewal is > performed, the authoritySerial attribute is updated in the > authority's entry in Dogtag's database; other CA replicas replicas > notice the update and install the new cert in their own NSSDBs > without requiring restart (thus, we only need to track LWCA certs on > the renewal master). > > The mechanism is available on versions of Dogtag that support > lightweight CAs, with the ou=authorities container existing in > Dogtag's database. It should work for the main CA, but I have not > tested this yet. Sounds great! I hope it works, I would very much like to get rid of our thing now that Dogtag handles it.

> > > > > > > An untrack command could also be provided. > > > > > > Thoughts? > > > > > > > * "Development of new Certmonger renewal helpers solely for lightweight CA > > > > renewal." > > > > > > > > It would be easier to extend the existing helpers. I don't think there > > > > is anything preventing them from being used for lighweight CAs, except not > > > > conveying the CA name, which should be easy to implement. > > > > > > > > > > > > I would also avoid starting with (1), I don't believe it adds any real > > > > value. IMHO the first thing that should be done is implement lightweight CA > > > > support in certmonger (add new 'request' / 'start-tracking' option for CA > > > > name, store it in tracking requests, pass it to CA helpers in a new > > > > environment variable). > > > > > > > > > > > > Honza > > > > > > > > -- > > > > Jan Cholasta > > > > > > -- > > Jan Cholasta -- Jan Cholasta