On 6.1.2016 15:56, Rob Crittenden wrote:
Jan Cholasta wrote:
On 4.1.2016 19:57, Rob Crittenden wrote:
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 agree bad error messages should be improved, but that's completely orthogonal to my proposal.


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.

I don't think there are any behavior changes needed for masters without 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.

Right.


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

It will add some complexity wrt credential forwarding to certmonger, but besides that, it should actually reduce complexity - the goal of this is to maximize code reuse, to the point where there is only *one* code path for requesting certificates.


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.

This will be done one way or another, see <https://fedorahosted.org/freeipa/ticket/5011>.

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

Reply via email to