[Freeipa-devel] certmonger everywhere

[Jan Cholasta]

On 16.12.2015 15:29, Simo Sorce wrote:
> On Wed, 2015-12-16 at 07:17 +0100, Jan Cholasta wrote:
>> On 15.12.2015 18:22, Simo Sorce wrote:
>>> On Tue, 2015-12-15 at 16:23 +0100, Martin Kosek wrote:
>>>> On 12/15/2015 08:54 AM, Jan Cholasta wrote:
>>>>> Hi,
>>>>>
>>>>> recently I and David discussed the direction of installers with regard to
>>>>> requesting certificates. Currently there are four (!) different ways of
>>>>> requesting certificates in the installer [1][2][3][4]. We would like to reduce
>>>>> it to one.
>>>>>
>>>>> Since all the certificates are tracked by certmonger and certmonger already
>>>>> knows how to request certificates from Dogtag (and other CAs), we believe that
>>>>> all certificates should be requested using certmonger.
>>>>>
>>>>> Taking our meditation further, we thought "Why not use certmonger for the
>>>>> cert-request command as well?" What is the benefit, do you ask?
>>>>>
>>>>>    a) single code path for requesting certificates (seriously, the current state
>>>>> is ridiculous)
>>>>>
>>>>>    b) use any CA supported by certmonger as the IPA CA (i.e. Let's Encrypt [5],
>>>>> once certmonger gains support for it)
>>>>>
>>>>>    c) automate external CA install, using any CA supported by certmonger [6]
>>>>>
>>>>>    d) support multiple different CAs at once (generalization of the Sub-CA feature)
>>>>>
>>>>>    e) uniform configuration on clients (configure once, use forever, even for
>>>>> CA-less)
>>>>>
>>>>> The idea is to store configuration for the different CAs in LDAP and have
>>>>> cert-request redirect requests to a proper CA helper according to that
>>>>> configuration. This would require a new certmonger D-Bus method to call a CA
>>>>> helper without associated certificate storage, but that should be rather easy
>>>>> to add. In return, it would be possible to do all of the above.
>>>>>
>>>>> Note that this should not conflict with tighter integration with Dogtag
>>>>> (profiles, ACLs, etc.).
>>>>>
>>>>> Comments are welcome.
>>>>>
>>>>> Honza
>>>>>
>>>>> [1]
>>>>> <https://git.fedorahosted.org/cgit/freeipa.git/tree/ipapython/certmonger.py#n305>
>>>>> [2]
>>>>> <https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/certs.py#n329>
>>>>>
>>>>> [3]
>>>>> <https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/certs.py#n355>
>>>>>
>>>>> [4]
>>>>> <https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/cainstance.py#n878>
>>>>>
>>>>> [5] <https://fedorahosted.org/freeipa/ticket/5431>
>>>>> [6] <https://fedorahosted.org/freeipa/ticket/5317>
>>>>
>>>> Interesting idea! I would be definitely interested to hear what Fraser, Rob or
>>>> Simo thinks here.
>>>
>>> Sounds great to me in principle.
>>>
>>> How do you handle CAs that do not have automatic workflows for csr
>>> handling ?
>>>
>>> That's the reason we did the 2 step process (in reference to [6])
>>
>> This could be handled by a dummy "manual" CA helper in certmonger, which
>> would dump the CSR into the filesystem and wait for the user to provide
>> the signed certificate in the filesystem and resume the certmonger request.
>>
>> As you pointed out, we currently do the same, although manually, in
>> external CA install. It is also done when renewing the externally signed
>> CA certificate - this time it is done using certmonger, but it is
>> handled by the dogtag-ipa-ca-renewal-agent helper rather than a separate
>> helper.
>
> The reason why we did the 2 step process is that it can take days in
> some cases to get back a cert given a csr.
>
> I do not think it is safe to wait for days mid-install.
> At the very least we'll need to be able to stop the install and resume
> it when the certs are available.

I'm not suggesting to wait, we don't wait in ipa-cacert-manage when 
renewing the CA certificate either. We can monitor the status of the 
certmonger request and interrupt the install when it reaches 
NEED_GUIDANCE (which means user intervention is needed).

-- 
Jan Cholasta