On Wed, 16 Dec 2015, Simo Sorce wrote:
On Wed, 2015-12-16 at 15:41 +0100, Jan Cholasta wrote:
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 
>>>>> it to one.
>>>>> Since all the certificates are tracked by certmonger and certmonger 
>>>>> knows how to request certificates from Dogtag (and other CAs), we believe 
>>>>> 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 
>>>>>    d) support multiple different CAs at once (generalization of the 
Sub-CA feature)
>>>>>    e) uniform configuration on clients (configure once, use forever, even 
>>>>> 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 
>>>>> helper without associated certificate storage, but that should be rather 
>>>>> 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]
>>>>> [2]
>>>>> [3]
>>>>> [4]
>>>>> [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).
Ok so we'll keep the 2 stages install for this case, fine with me and +1
to reducing parallel paths.
I guess this still wouldn't help automated installs as there are
problems in running certmonger in Anaconda's chroot but it would
probably be unlikely that someone would do automated installs with
two-stage process.
/ Alexander Bokovoy

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to