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. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code