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

[Petr Viktorin]

On 03/20/2013 06:34 PM, Dmitri Pal wrote:
> 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.

Well, if we allow more than one CA in the PEM we can lift this 
restriction. More below.

>>> 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.

I don't think it would, but if we allow more than one CA (possibly in 
the future) there is a bigger chance of confusion after all.
I'll use --root-ca-file instead.

>>> 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.

Yes, enforcing this isn't hard.
Creating is them easy too, it's the default (if not only) option in most 
tools. PKCS#12s with more than one cert chain are fairly exotic, from 
what I've read some Java tools that can use them but they run into 
interoperability problems.

>>> 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 don't want the whole chain in the PEM, because then it's not obvious 
which cert(s) to trust. We certainly don't want to give root trust to 
every cert in the chain.
So if we allow more CAs here they'd have to be different *root* CAs. 
That would allow the server certs to be signed by different CAs, so I 
guess we want to do this.

I don't know of a robust way to know that we have separate root CAs and 
not a chain (or several partial chains, etc.), so we'd have to document 
this well.

But more importantly, this would mean we'd have to put several certs in 
/etc/ipa/ca.crt, and in LDAP. This is rather invasive so I'd like to 
stay out of this for now (but design so it's possible in the future).

>> 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).

We still need to put something in /etc/ipa/ca.crt.
I'll investigate what happens when I try to import and trust a cert 
that's already trusted, but I don't think it will cause any trouble?

>>> 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.

OK. I'll just finish this informal discussion first so I don't have to 
re-type everything.

>>> 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.

Let's see if Trac lets me do that :)

Thanks,

Petr³