[Freeipa-devel] certmonger everywhere

[Simo Sorce]

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.

Simo.