The PKINIT client code in krb5 1.8 and later can be used, if the KDC's been configured with a certificate, to obtain anonymous TGTs. For this to work, at minimum, the client just needs to trust the KDC's CA. While the location of the CA certificate can be passed as a command-line option to kinit, I think that since we're downloading the CA certificate and editing krb5.conf anyway, we should just go ahead and set up krb5.conf to trust the CA for the IPA realm. The setting is pkinit_anchors; like kdc, it can have multiple values; the value can be, among other things, FILE:pem_file. So I'm suggesting that when we download and store the CA certificate in '/etc/ipa/ca.crt', we also want to add this to krb5.conf:
[realms] IPAREALM = { pkinit_anchors = FILE:/etc/ipa/ca.crt }
I should note that this doesn't address issuing a cert to the CA; it's just the client parts. The CA cert would probably need to be issued with a profile that's different from what I currently see in caIPAserviceCert (which is a nice, vanilla server certificate profile).
My guess is that either the server installer would submit the request directly, or it would ask certmonger to do it. In turn, certmonger would either have to learn to request certificates (KDC certificates, at that) from dogtag, or learn how to ask the IPA server to request a specific certificate from dogtag using a profile other than caIPAserviceCert.
Argh. That last comment should have started by noting that this doesn't address issuing a cert to the KDC, and that the certificate for the KDC is the one for which caIPAserviceCert is not going to include all of the right settings.
That begs the question: what settings will be required?
I would vote that the KDC cert is handled by the installer. I feel we need to have a separate ticket for it.
Replying to [comment:3 rcritten]:
I didn't intend to leave you hanging; I didn't know we were going there yet. Mainly, the certificate needs to contain a subjectAltName value that includes the Kerberos principal name for the realm's ticket granting service, "krbtgt/REALM@REALM".
I'd also suggest including id-pkinit-KPKdc (1.3.6.1.5.2.3.5) as an EKU value, though that's optional if the subjectAltName is there. The keyUsage should include digitalSignature.
The more verbose description of the requirements the client places on the KDC's certificate is laid out in section 3.2.4 of RFC4556.
client side of pkinit freeipa-538-pkinit.patch
master: 2a85755
Metadata Update from @nalin: - Issue assigned to rcritten - Issue set to the milestone: FreeIPA 2.0 - 2010/09
Login to comment on this ticket.