[Freeipa-devel] certmonger everywhere

[Rob Crittenden]

Jan Cholasta wrote:
> On 4.1.2016 19:57, Rob Crittenden wrote:
>> Jan Cholasta wrote:
>>> On 16.12.2015 01:40, Fraser Tweedale wrote:
>>>
>>> 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
>>>
>>
>> I guess this would work but I think you'd have quite a difficult time
>> returning usable error messages to a user (and they are pretty bad now
>> in cert-request).
> 
> I don't see why, error messages can be easily passed between all the
> involved interfaces.

The current messages aren't great but at least with some amount of
google-fu one can discover what the current ones mean. The certmonger
messages tend to be just "can't talk to http://...:9180/... and a
semi-documented status code.

>> I assume that a CSR can be seeded into the certmonger request process
>> but I've never tried it myself. Do you know if it works?
>>
>> I really wonder how the case of delayed issuance would be handled. Would
>> you leave the server-side certmonger request to idle until the second
>> step was handled? Wouldn't this have the potential to have an
>> unmanageable number of certmonger requests? It gets confusing enough for
>> users for the 8 typical tracked certs, what about hundreds?
> 
> See step 8: there won't be any new certmonger requests, everything will
> be forwarded directly to the proper certmonger CA helper using a new
> D-Bus call.

Ok, I read it as creating a request via the D-Bus call. Makes me wonder
what this means for masters that don't run CA.

>>
>> If you want to eventually use the requestors credentials won't this
>> require a pretty big change in certmonger to be able to use passed-in
>> credentials?
> 
> Yes, I guess. However, we can use the current Dogtag backed for our CA
> and certmonger for other CAs until that is implemented.
> 
>> How will those work in the two-step case?
> 
> What do you mean?

This question was based on my misunderstanding how certmonger would be
called via D-Bus. You'd have had to correlate a status request with an
existing certmonger request in some way, but since you aren't creating
one it's a no-op.

I think this is interesting in theory but I fear it is going to make a
complex process even more complex.

It does raise the interesting possibility of removing the need to store
the RA credentials in the Apache NSS database and to me that is the
bigger win.

rob