[Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs

[Dmitri Pal]

On 03/20/2013 01:28 PM, Rob Crittenden wrote:
> Petr Viktorin wrote:
>> On 03/18/2013 10:24 PM, Rob Crittenden wrote:
>>> Petr Viktorin wrote:
>> [...]
>>>>  From what I've learned, PKCS#12 files are just a bag of certificates;
>>>> there are basically no restrictions on their contents. But we assume
>>>> there's only one cert inside that has a private key, and use that for
>>>> the server cert. We also pretty much assume that there's one CA
>>>> cert: if
>>>> not we pick the first one and trust it as root CA.
>>>> In short, I think --http_pkcs & friends are too vague for PKCS#12s we
>>>> don't control; we should have the user name the certs more explicitly.
>>>> Am I wrong here? Is this the usual way to import server certs?
>>>
>>> We can impose a requirement that the CA be included in the PKCS#12
>>> files. At least with NSS this happens automatically, I can't recall
>>> with
>>> openssl.
>>>
>>> Or we can add a new option to pass in the CA bundle in PEM format.
>>
>> After thinking about it, this is the way I want to go. It's a bit more
>> typing for the user, but it reduces the amount of guesswork the
>> installer needs to do. When deciding who to trust I'd rather be
>> explicit.
>> There's also a bit less validation to do and corner cases to watch
>> out for.
>
> Yeah, I think this will simplify things a lot. The only downside is
> the requirement that both certs come from the same CA, but we have to
> draw the line somewhere. We can always look into extending things
> later on as needed.
>
>>
>> The root CA certificate will be given by --external-ca-file. The trust
>> chains for both servers (dirsrv, http) must lead to that CA. This CA
>> will be trusted, and put in /etc/ipa/ca.crt.
>
> Just thinking out loud here, but will that cause any confusion, using
> an existing option? I don't think so but I may be too used to this.
>
>>
>> Each PKCS#12 file must contain exactly one cert with a private key. This
>> cert will be used for the corresponding server.
>> Of course you can use the same cert for both servers.
>
> I'm ok with that assuming we have an effective way of enforcing it.
> We'll need to provide some good documentation on how to create, or
> re-create, a PKCS#12 file to fit this format.
>
>>
>> The --external_ca_file must contain exactly one cert. Certs for any
>> intermediate CAs must be in the PKCS#12.
>
> It would be a lot easier to include all the CAs in a single PEM. This
> is not unprecedented, and just catting a bunch of certs together into
> a single file is easy and should not be error-prone.
>
> I think too we'll need to be able to handle the case of any Built-in
> certs. There is a chance we will need to simply drop on the floor any
> CA certs provided because some or all of them are already in NSS (all
> we really care about for this, I think).
>
>> Does that look good? Does it need a design page?
>
> I think a design page would be particularly helpful in this case. I
> think this is going to be rather complex, and whatever choices we make
> to simplify things are going to be important.

Yes the design is needed with the content of this thread plus some
examples of the command line plus some hints & guidance on how to
prepare files to be in the right format.
This includes:
How to check what format the files are?
How many are there in the file?
How to extact certs or or combine certs into files?
How to save in the format we want/need?

Explain why we require all this "more typing". We want to be explicit
but we also want people to understand why we want them to be explicit.
This is a very complex area and if we can explain why we ware requiring
what we are requiring it would go a long way to helping people
understand what they are doing and what would the implication be.

>
>>
>> I have some patches for this and for replication, but it'll take another
>> day to polish and test them.
>
> Sounds great.
>
>>
>> [...]
>>> I'm not sure the dogtag 9 removal code really fits in the context of
>>> these changes. It makes sense, but has nothing to do with this.
>>
>> I'll retire that patch for now.
>
> It would probably be a good idea to open a ticket and attach your
> current work.
>
> thanks
>
> rob
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/