[Freeipa-devel] certmonger everywhere

[Jan Cholasta]

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*. 
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

  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

  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

-- 
Jan Cholasta