Re: [Freeipa-devel] certmonger everywhere

[Jan Cholasta]

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 
.


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

Re: [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

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

Re: [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

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

Re: [Freeipa-devel] certmonger everywhere

[Rob Crittenden]

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

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? How will those work in the two-step case?

rob

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

Re: [Freeipa-devel] certmonger everywhere

[Alexander Bokovoy]

On Wed, 16 Dec 2015, Simo Sorce wrote:

On Wed, 2015-12-16 at 15:41 +0100, Jan Cholasta wrote:

On 16.12.2015 15:29, Simo Sorce wrote:
> On Wed, 2015-12-16 at 07:17 +0100, Jan Cholasta wrote:
>> On 15.12.2015 18:22, Simo Sorce wrote:
>>> On Tue, 2015-12-15 at 16:23 +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]
> 

> [2]
> 

>
> [3]
> 

>
> [4]
> 

>
> [5] 
> [6] 

 Interesting idea! I would be definitely interested to hear what Fraser, 
Rob or
 Simo thinks here.
>>>
>>> Sounds great to me in principle.
>>>
>>> How do you handle CAs that do not have automatic workflows for csr
>>> handling ?
>>>
>>> That's the reason we did the 2 step process (in reference to [6])
>>
>> This could be handled by a dummy "manual" CA helper in certmonger, which
>> would dump the CSR into the filesystem and wait for the user to provide
>> the signed certificate in the filesystem and resume the certmonger request.
>>
>> As you pointed out, we currently do the same, although manually, in
>> external CA install. It is also done when renewing the externally signed
>> CA certificate - this time it is done using certmonger, but it is
>> handled by the dogtag-ipa-ca-renewal-agent helper rather than a separate
>> helper.
>
> The reason why we did the 2 step process is that it can take days in
> some cases to get back a cert given a csr.
>
> I do not think it is safe to wait for days mid-install.
> At the very least we'll need to be able to stop the install and resume
> it when the certs are available.

I'm not suggesting to wait, we don't wait in ipa-cacert-manage when
renewing the CA certificate either. We can monitor the status of the
certmonger request and interrupt the install when it reaches
NEED_GUIDANCE (which means user intervention is needed).
\

Ok so we'll keep the 2 stages install for this case, fine with me and +1
to reducing parallel paths.

I guess this still wouldn't help automated installs as there are
problems in running certmonger in Anaconda's chroot but it would
probably be unlikely that someone would do automated installs with
two-stage process.
--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] certmonger everywhere

[Simo Sorce]

On Wed, 2015-12-16 at 15:41 +0100, Jan Cholasta wrote:
> On 16.12.2015 15:29, Simo Sorce wrote:
> > On Wed, 2015-12-16 at 07:17 +0100, Jan Cholasta wrote:
> >> On 15.12.2015 18:22, Simo Sorce wrote:
> >>> On Tue, 2015-12-15 at 16:23 +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]
> > 
> > [2]
> > 
> >
> > [3]
> > 
> >
> > [4]
> > 
> >
> > [5] 
> > [6] 
> 
>  Interesting idea! I would be definitely interested to hear what Fraser, 
>  Rob or
>  Simo thinks here.
> >>>
> >>> Sounds great to me in principle.
> >>>
> >>> How do you handle CAs that do not have automatic workflows for csr
> >>> handling ?
> >>>
> >>> That's the reason we did the 2 step process (in reference to [6])
> >>
> >> This could be handled by a dummy "manual" CA helper in certmonger, which
> >> would dump the CSR into the filesystem and wait for the user to provide
> >> the signed certificate in the filesystem and resume the certmonger request.
> >>
> >> As you pointed out, we currently do the same, although manually, in
> >> external CA install. It is also done when renewing the externally signed
> >> CA certificate - this time it is done using certmonger, but it is
> >> handled by the dogtag-ipa-ca-renewal-agent helper rather than a separate
> >> helper.
> >
> > The reason why we did the 2 step process is that it can take days in
> > some cases to get back a cert given a csr.
> >
> > I do not think it is safe to wait for days mid-install.
> > At the very least we'll need to be able to stop the install and resume
> > it when the certs are available.
> 
> I'm not suggesting to wait, we don't wait in ipa-cacert-manage when 
> renewing the CA certificate either. We can monitor the status of the 
> certmonger request and interrupt the install when it reaches 
> NEED_GUIDANCE (which means user intervention is needed).
> \
Ok so we'll keep the 2 stages install for this case, fine with me and +1
to reducing parallel paths.

Simo.



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

Re: [Freeipa-devel] certmonger everywhere

[Jan Cholasta]

On 16.12.2015 15:29, Simo Sorce wrote:

On Wed, 2015-12-16 at 07:17 +0100, Jan Cholasta wrote:

On 15.12.2015 18:22, Simo Sorce wrote:

On Tue, 2015-12-15 at 16:23 +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]

[2]


[3]


[4]


[5] 
[6] 


Interesting idea! I would be definitely interested to hear what Fraser, Rob or
Simo thinks here.


Sounds great to me in principle.

How do you handle CAs that do not have automatic workflows for csr
handling ?

That's the reason we did the 2 step process (in reference to [6])


This could be handled by a dummy "manual" CA helper in certmonger, which
would dump the CSR into the filesystem and wait for the user to provide
the signed certificate in the filesystem and resume the certmonger request.

As you pointed out, we currently do the same, although manually, in
external CA install. It is also done when renewing the externally signed
CA certificate - this time it is done using certmonger, but it is
handled by the dogtag-ipa-ca-renewal-agent helper rather than a separate
helper.


The reason why we did the 2 step process is that it can take days in
some cases to get back a cert given a csr.

I do not think it is safe to wait for days mid-install.
At the very least we'll need to be able to stop the install and resume
it when the certs are available.


I'm not suggesting to wait, we don't wait in ipa-cacert-manage when 
renewing the CA certificate either. We can monitor the status of the 
certmonger request and interrupt the install when it reaches 
NEED_GUIDANCE (which means user intervention is needed).


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

Re: [Freeipa-devel] certmonger everywhere

[Simo Sorce]

On Wed, 2015-12-16 at 07:17 +0100, Jan Cholasta wrote:
> On 15.12.2015 18:22, Simo Sorce wrote:
> > On Tue, 2015-12-15 at 16:23 +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]
> >>> 
> >>> [2]
> >>> 
> >>>
> >>> [3]
> >>> 
> >>>
> >>> [4]
> >>> 
> >>>
> >>> [5] 
> >>> [6] 
> >>
> >> Interesting idea! I would be definitely interested to hear what Fraser, 
> >> Rob or
> >> Simo thinks here.
> >
> > Sounds great to me in principle.
> >
> > How do you handle CAs that do not have automatic workflows for csr
> > handling ?
> >
> > That's the reason we did the 2 step process (in reference to [6])
> 
> This could be handled by a dummy "manual" CA helper in certmonger, which 
> would dump the CSR into the filesystem and wait for the user to provide 
> the signed certificate in the filesystem and resume the certmonger request.
> 
> As you pointed out, we currently do the same, although manually, in 
> external CA install. It is also done when renewing the externally signed 
> CA certificate - this time it is done using certmonger, but it is 
> handled by the dogtag-ipa-ca-renewal-agent helper rather than a separate 
> helper.

The reason why we did the 2 step process is that it can take days in
some cases to get back a cert given a csr.

I do not think it is safe to wait for days mid-install.
At the very least we'll need to be able to stop the install and resume
it when the certs are available.

Simo.



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

Re: [Freeipa-devel] certmonger everywhere

[Fraser Tweedale]

On Wed, Dec 16, 2015 at 11:11:42AM +0100, Martin Kosek wrote:
> On 12/16/2015 09:17 AM, Jan Cholasta wrote:
> > On 16.12.2015 08:54, Martin Kosek wrote:
> ...
> >>>   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.
> 
> Right, this is how it works now. However, in FreeIPA 4.4 or later, we plan to
> switch GSSAPI authentication with Dogtag to get better authorization 
> capabilities:
> 
> https://fedorahosted.org/freeipa/ticket/5011
> 
> But maybe this could be done via S4U2Proxy as Fraser suggested, although in
> this case it would be more complicated as certmonger itself does not have
> access to user HTTP/ipa.server ticket, like Apache does, given that Apache
> would contact certmonger via DBUS.
> 
If I am not mistaken, Certmonger already uses host credentials, so
IPA framework can S4U2Proxy to get user ticket for Certmonger, then
Certmonger can S4U2Proxy to get user ticket for Dogtag.

Big +1 to the fact that we are pushing away from RA cert to GSS-API
for authenticating to Dogtag.

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

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

Re: [Freeipa-devel] certmonger everywhere

[Fraser Tweedale]

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]
> >
> >
> >
> >[2]
> >
> >
> >
> >
> >[3]
> >
> >
> >
> >
> >[4]
> >
> >
> >
> >
> >[5] 
> >[6] 
> 
> 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/ 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
> >>C

Re: [Freeipa-devel] certmonger everywhere

[Martin Kosek]

On 12/16/2015 09:17 AM, Jan Cholasta wrote:
> On 16.12.2015 08:54, Martin Kosek wrote:
...
>>>   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.

Right, this is how it works now. However, in FreeIPA 4.4 or later, we plan to
switch GSSAPI authentication with Dogtag to get better authorization 
capabilities:

https://fedorahosted.org/freeipa/ticket/5011

But maybe this could be done via S4U2Proxy as Fraser suggested, although in
this case it would be more complicated as certmonger itself does not have
access to user HTTP/ipa.server ticket, like Apache does, given that Apache
would contact certmonger via DBUS.

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

Ok.

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

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

Re: [Freeipa-devel] certmonger everywhere

[Jan Cholasta]

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]



[2]




[3]




[4]




[5] 
[6] 


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





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 th

Re: [Freeipa-devel] certmonger everywhere

[Martin Kosek]

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]


[2]



[3]



[4]



[5] 
[6] 


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



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.


  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 

Re: [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]

[2]


[3]


[4]


[5] 
[6] 


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

Re: [Freeipa-devel] certmonger everywhere

[Jan Cholasta]

On 15.12.2015 18:22, Simo Sorce wrote:

On Tue, 2015-12-15 at 16:23 +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]

[2]


[3]


[4]


[5] 
[6] 


Interesting idea! I would be definitely interested to hear what Fraser, Rob or
Simo thinks here.


Sounds great to me in principle.

How do you handle CAs that do not have automatic workflows for csr
handling ?

That's the reason we did the 2 step process (in reference to [6])


This could be handled by a dummy "manual" CA helper in certmonger, which 
would dump the CSR into the filesystem and wait for the user to provide 
the signed certificate in the filesystem and resume the certmonger request.


As you pointed out, we currently do the same, although manually, in 
external CA install. It is also done when renewing the externally signed 
CA certificate - this time it is done using certmonger, but it is 
handled by the dogtag-ipa-ca-renewal-agent helper rather than a separate 
helper.


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

Re: [Freeipa-devel] certmonger everywhere

[Fraser Tweedale]

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]
> > 
> > [2]
> > 
> > 
> > [3]
> > 
> > 
> > [4]
> > 
> > 
> > [5] 
> > [6] 
> 
> 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/ 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.

Cheers,
Fraser

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

Re: [Freeipa-devel] certmonger everywhere

[Simo Sorce]

On Tue, 2015-12-15 at 16:23 +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]
> > 
> > [2]
> > 
> > 
> > [3]
> > 
> > 
> > [4]
> > 
> > 
> > [5] 
> > [6] 
> 
> Interesting idea! I would be definitely interested to hear what Fraser, Rob or
> Simo thinks here.

Sounds great to me in principle.

How do you handle CAs that do not have automatic workflows for csr
handling ?

That's the reason we did the 2 step process (in reference to [6])

Simo.

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

Re: [Freeipa-devel] certmonger everywhere

[Martin Kosek]

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]
> 
> [2]
> 
> 
> [3]
> 
> 
> [4]
> 
> 
> [5] 
> [6] 

Interesting idea! I would be definitely interested to hear what Fraser, Rob or
Simo thinks here.

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

Re: [Freeipa-devel] certmonger everywhere

[Martin Basti]

On 15.12.2015 08:54, 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] 

[2] 

[3] 

[4] 


[5] 
[6] 


LGTM

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

Re: [Freeipa-devel] certmonger everywhere

[Petr Spacek]

On 15.12.2015 08:54, 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.

It makes a lot of sense to me!

Petr^2 Spacek

> Honza
> 
> [1]
> 
> [2]
> 
> 
> [3]
> 
> 
> [4]
> 
> 
> [5] 
> [6] 

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