On Wed, Dec 16, 2015 at 09:17:09AM +0100, Jan Cholasta wrote: > On 16.12.2015 08:54, Martin Kosek wrote: > >On 12/16/2015 08:09 AM, Jan Cholasta wrote: > >>On 16.12.2015 01:40, Fraser Tweedale wrote: > >>>On Tue, Dec 15, 2015 at 04:23:33PM +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. > >>>> > >>>For the installer cases, +1 from me. > >>> > >>>For the general cert-request case, currently Certmonger calls `ipa > >>>cert-request' using host credentials (Kerberos), and IPA framework > >>>does some validation (e.g. ensure CN and altNames correspond to > >>>subject principal), before requesting cert from Dogtag using RA > >>>Agent credentials (TLS client cert). > >>> > >>>There are a few things that have to happen before Certmonger can > >>>request certs directly from Dogtag, in IPA scenario: > >>> > >>>1. support SNPEGO authentication in Dogtag (work has started) > >>> > >>>2. perform all validation that IPA framework currently performs in > >>> Dogtag, or make the validation no longer required by pulling cert > >>> data straight from LDAP according to the profile. > >>> > >>>3. Requestor credentials must be delegated to Certmonger so that the > >>> correct principal is used to talk to Dogtag. Presumably this would > >>> be S4U2Proxy constrained delegation with host/<hostname> as > >>> impersonator and Dogtag service principal as target. > >>> > >>>At that point `ipa cert-request' can become a client-side command > >>>that merely configures Certmonger to request the cert. > >> > >>I'm not proposing to change cert-request to a client side command - I'm > >>proposing to change the way cert-request is handled *on the server*. > > > >I do not think Fraser was suggesting to change cert-request to a client > >side command. More below. > > See 3 paragraphs above: "... `ipa cert-request' can become a client-side > command...". > Indeed; my commentary was based on misunderstanding that Jan was proposing Certmonger on would talk to Dogtag. Thanks for clarifying, Jan.
> > > >>This way > >>we can keep all the configuration on the server and make changes to it > >>without > >>having to reconfigure all clients. > >> > >>This is how I envision the workflow: > >> > >> 1. client requests a certificate with "getcert request", using "IPA" > >>as the > >>CA and, optionally, a string identifying the sub-CA (for the lack of > >>better term) > >> > >> 2. "getcert request" forwards the request to certmonger over D-Bus > >>and exits > >> > >> 3. certmonger creates CSR for the request > >> > >> 4. certmonger executes the IPA CA helper to handle the request > >> > >> 5. the IPA CA helper calls the cert-request command on the server > >>over RPC, > >>using local host credentials for authentication > >> > >> 6. cert-request on the server validates the request > > > >Right. These are the steps that happen already, AFAIK. > > Correct. > > > > >> 7. cert-request fetches the configuration for the specified sub-CA, > >>or the > >>default sub-CA if none was specified, from LDAP > >> > >> 8. cert-request forwards the request to the certmonger CA helper > >>specified in > >>the LDAP configuration over D-Bus (this is the D-Bus method that > >>currently does > >>not exist and needs to be implemented) > >> > >> 9. certmonger executes the specified CA helper to handle the request > >> > >> 10. the CA helper requests the certificate from the CA and returns > >>either the > >>certificate, wait delay or error > >> > >> 11. certmonger returns the result back to cert-request > > > >These steps are subject to Fraser's question (and I am curious too), i.e.: > > > >- how is authentication done? certmonger runs with FreeIPA server host > >principal. > > We are on the server, so the RA agent cert is used to authenticate to Dogtag > as usual, and whatever authentication is configured for other CAs is used > for other CAs. > > >- how will we handle 3-step certificate request, i.e.: > > - certificate is requested and in moderation/wait queue > > - request have to be acked by Dogtag administrator (we do not have > >API yet) > > - client should be able to ask for generated certificate > > This is not really related to my proposal, since we have to figure this out > for our Dogtag IPA CA anyway, but the CA helper can return a wait delay in > this case, so certmonger can poll the request until it is approved. > > > > >> 12. cert-request returns the result back to IPA CA helper on the client > >> > >> 13. the IPA CA helper on the client returns the result back to > >>certmonger > >> > >> 14. if the result was wait delay, certmonger waits and then retries the > >>request from step 4, otherwise it stores the certificate or sets error > >>status > >> > > > >Right, 12-14 is again the standard flow. Good summary of the steps! > > > -- > Jan Cholasta -- 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
