[Freeipa-devel] Re: Certificate enrollment, principal names

[Rob Crittenden]

Nalin Dahyabhai wrote:
> I think I'm getting closer to having certmonger (the provider of the
> ipa-getcert command) be useful enough to throw certificate enrollment
> requests at the IPA server, and I've got a couple of questions about how
> the server decides what it will issue and what it puts in the
> certificates that it issues.
> 
> First, how we are we going to be expected to pass, to the server,
> information about the certificate we'd like it to issue?
> 
> Until now, I've been storing the principal name in a subjectAltName
> value in an extensionRequest attribute in the signing request.  I can
> actually put quite a bit of information in extensionRequests.
> 
> It's not a lot of trouble to also provide that information along with
> the signing request (as 1.9.0 expects, at least for the Kerberos
> principal name), but if the server's going to be taking direction from
> the client on any of these things, it might be more future-proof if it
> could parse the request and validate its contents directly.
> 
> This would make adding a requested dnsName subjectAltName possible
> without breaking any of the existing interfaces -- the client could
> request it, or not, or more than one value, and the server would pick
> and choose from everything that the client requested when deciding what
> to put into a certificate.
> 
> The other question is about client authorization:  have we set down the
> rules about which client identities are allowed to request what, and
> what they get?

There are 2 options. There is a rolegroup called certadmin. Members of 
this role are allowed to call cert-request, others will be rejected.

Alternatively you can specify which host(s) can request a certificate 
for a given service. Use the service-add-member command to add hosts 
that can request certs for it.

> I ask because I think that we'll have to use the client host's identity
> (via creds obtained using its keytab) to handle the case where the
> connection to the CA doesn't become available until long after the
> admin's logged out, but when I try that now, requests submitted using
> the host's identity are being denied by the access control mechanisms.

Yes, the first access method is really designed for 
users/administrators. The second if you are binding as a host.

> Anyone have some insight to share here?

A couple of tidbits:

- In 1.9.0 we'll issue a certificate for any subject requested. dogtag 
has a fix that we will be able to use once it's released that will let 
us pull the CN from the request and use just that with the subject and 
use a fixed value for the rest.
- The management framework doesn't do anything to the CSR right now, it 
literally just passes it onto the CA for processing.
- The whole ugly client IP thing has been ripped out post 1.9.0.
- I still compare the hostname in the subject with the hostname of the 
service. This is unfortunately currently broken in python 2.4-based systems.
- I'm not opposed to including more "stuff" into the CSR itself we just 
need to be sure the average admin who doesn't want to use certmonger can 
still make a request too. Right now the bar is pretty low to 
understanding what is required IMHO with the exception of pasting in the 
ugly one-line CSR :-(

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20091104/15f8c699/attachment.bin>