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

[Rob Crittenden]

Andrew Wnuk wrote:
> On 11/04/09 16:16, Nalin Dahyabhai wrote:
>> On Wed, Nov 04, 2009 at 04:39:40PM -0500, Rob Crittenden wrote:
>>   
>>> 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.
>>>      
>> That sounds reasonable.  Is this new post-1.9.0?  I can add members to
>> various groups, but there's no service-add-member command yet.
>>
>>   
>>> 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.
>>>      
>> That sounds good -- the default request subject is just 'CN=hostname'
>> unless it's told different.
>>
>>   
>>> - 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.
>>>      
>> If we're requiring that every certificate has an associated principal
>> name, then ensuring it agrees with the hostname in the subject field
>> makes a lot of sense.  I'd kind of like to see both a dnsName and a
>> Kerberos principal name added to the subjectAltName fields in the issued
>> certificate, but that's as much because we can as anything else.
>>
>>   
>>> - 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.
>>>      
>> NSS's certutil can trivially add dns and email subjectAltName (SAN)
>> values and extendedKeyUsage (EKU) values.  I don't see a flag for adding
>> a Kerberos principal name.  OpenSSL's req command doesn't do most of
>> that by default, but the configuration file can be used to tell it to do
>> any of that.  It could be scripted, for sure.
>>
>>   
>>>                                           Right now the bar is pretty
>>> low to understanding what is required IMHO with the exception of
>>> pasting in the ugly one-line CSR :-(
>>>      
>> Yeah, it took me a while to figure out that that was how we were
>> supposed to pass it in.
>>    
> Passing entire CSR as a parameter to ipa command could avoided if 
> XML-RPC framework would provide pre and post processing callbacks on the 
> client side. Parameters could be used to describe CSR (instead of 
> passing entire CSR), pre-processing callback could generate CSR based on 
> provided description, then XML-RPC call could submit generated CSR and 
> finally post-processing callback could properly place obtained certificate.
> 
> Regards,
> Andrew

As I've said before, it is possible to do this right now by overriding 
execute(). Use the variable self.env.in_server to determine if you are 
on the client or server side. For the client you do the CSR generation, 
call forward(), then load the cert when forward() returns.

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/20091105/b05e12e7/attachment.bin>