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

[Andrew Wnuk]

On 11/04/2009 05:31 PM, Dmitri Pal wrote:
> 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.
>>
>>      
> I though we talked about these callbacks a year ago and planned to do them.
> Was this work ever finished?
>
>    
Jason, are there any dedicated pre and post processing callbacks 
available on the client side without using get_default 
<http://freeipa.org/developer-docs/ipalib.parameters.Param-class.html#get_default> 
for pre-processing and and display callback for post-processing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20091104/162eb403/attachment.htm>