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

Fri Mar 22 13:22:12 UTC 2013

On 03/21/2013 01:00 PM, Petr Viktorin wrote:
> 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.
>

Design is now at: http://freeipa.org/page/V3/CA-less_install

Patch 199 deferred to https://fedorahosted.org/freeipa/ticket/3529

Updated patches attached.

-- 
Petr³
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0197.2-ipa-server-install-Make-temporary-pin-files-availabl.patch
Type: text/x-patch
Size: 6412 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130322/c0cef54f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0198.2-ipa-server-install-Remove-the-selfsign-option.patch
Type: text/x-patch
Size: 10328 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130322/c0cef54f/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0200.2-Remove-unused-ipapython.certdb.CertDB-class.patch
Type: text/x-patch
Size: 6266 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130322/c0cef54f/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0201.2-ipaserver.install.certs-Introduce-NSSDatabase-as-a-m.patch
Type: text/x-patch
Size: 13843 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130322/c0cef54f/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0202.2-Trust-CAs-from-PKCS-12-files-even-if-they-don-t-have.patch
Type: text/x-patch
Size: 1126 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130322/c0cef54f/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0203.2-dsinstance-httpinstance-Don-t-hardcode-Server-Cert.patch
Type: text/x-patch
Size: 5772 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130322/c0cef54f/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0204.2-Support-installing-with-custom-SSL-certs-without-a-C.patch
Type: text/x-patch
Size: 20370 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130322/c0cef54f/attachment-0006.bin>