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