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

Andrew Wnuk awnuk at redhat.com
Fri Nov 6 16:21:54 UTC 2009


On 11/06/09 07:22, Simo Sorce wrote:
> On Fri, 2009-11-06 at 09:08 -0500, Rob Crittenden wrote:
>    
>> Simo Sorce wrote:
>>      
>>> On Thu, 2009-11-05 at 13:21 -0500, Rob Crittenden wrote:
>>>        
>>>> This is about right. What you're missing is storing the certificate
>>>> in
>>>> the service record. To do this we need to know what the target is.
>>>>
>>>> Nalin and I simply took two different approaches to sending this. We
>>>> can
>>>> easily support either method by making the principal an optional
>>>> attribute and looking for it in the CSR if not provided (assuming I
>>>> can
>>>> get my head around PKCS#10 enough to grab attributes).
>>>>          
>>> Given we should prevent "tricks" from people the server side should
>>> really parse the CSR and validate it against the ACL IMO.
>>> Otherwise do we have any other part that checks that host
>>> foo.example.com is asking a certificate for itself and not for
>>> bar.example.com ?
>>>
>>> Simo.
>>>
>>>        
>> When binding using machine credentials, in order to request a
>> certificate for any host they need to be in the managedBy attribute of
>> the target service entry.
>>      
> I know, but I was referring to stuff like subjectAltName.
> Not sure if we need to test it against an ACL to be honest, but we need
> to validate that as well (and any other attribute that can affect client
> behavior). Whether this is done in IPA or in the CA is not really
> important as long as it is done by a component that have enough
> information to determine what is ok or not, depending on the "user"
> requesting the new cert.
> For example admin may be allowed to stuff just any random crap in
> subjectAltName but maybe a host shouldn't be.
>
> Simo.
>
>    
Some of this random stuff could be filtered on the client side before 
CSR is generated.
Andrew




More information about the Freeipa-devel mailing list