[Freeipa-devel] certmonger everywhere

[Jan Cholasta]

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.

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

>
> 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?

-- 
Jan Cholasta