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

[Jan Cholasta]

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