[Freeipa-devel] Re: Certificate enrollment, principal names
Andrew Wnuk
awnuk at redhat.com
Thu Nov 5 01:25:47 UTC 2009
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
More information about the Freeipa-devel
mailing list