Dmitri Pal wrote:
On 06/10/2013 12:13 PM, Petr Viktorin wrote:
On 06/10/2013 05:34 PM, Dmitri Pal wrote:
On 06/10/2013 09:56 AM, Petr Viktorin wrote:
On 06/10/2013 03:35 PM, Rob Crittenden wrote:
Dmitri Pal wrote:
On 06/10/2013 05:54 AM, Jan Cholasta wrote:
On 7.6.2013 15:36, John Dennis wrote:
On 06/07/2013 09:26 AM, Jan Cholasta wrote:
On 7.6.2013 15:17, John Dennis wrote:
On 06/07/2013 08:57 AM, Jan Cholasta wrote:
Yes, this is correct. The DS certificate must be directly signed
by the
CA trusted by IPA (specified by --root-ca-cert in
ipa-server-install),
there may be no intermediate CAs, because ldapsearch and
friends and
python-ldap don't like them.


That doesn't sound right. Do we understand why a chain length >
1 is
failing?


LDAP utilities and python-ldap only trust certificates directly
issued
by CAs you point them to (at least on Fedora 18).

This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto
provider).
Have we filed a bug? Let's file the bug here in the Red Hat
bugzilla,
not upstream, we're the maintainers of MozLDAP and upstream is
already
frustrated with it.


I have just tested with libldap compiled with OpenSSL on my Arch
Linux
box, it does not work as well:

$ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H
ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory
Manager' -W
-b '' -s base
ldap_start_tls: Connect error (-11)
       additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
(invalid CA certificate)

For the record, this is what happens with NSS on Fedora:

$ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H
ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory
Manager' -W
-b '' -s base
ldap_start_tls: Connect error (-11)
       additional info: TLS error -8179:Peer's Certificate issuer
is not
recognized.

Honza

If the options does not work we should hide it for now and clearly
state
in the docs and man pages that the case when certs come from
different
CA is not supported for the time being.


IIRC it was added for two reasons:

1. Because the CA is not required to be included in the PKCS#12 file.

Well, that's not a necessary requirement. A tester did have a bit of
trouble creating a PKCS#12 file with both the server cert and the CA
cert, but the trouble is comparable to having to create a PEM file.

2. Because previous attempts to figure out the nickname of the signing
CA was problematic.

This is the main reason. It could be done, but I believe we should
avoid any guessing to determine the root of trust.


I am not sure I get it.
So we inspect the certificate PKCS#12 file and there can be ambiguity
about the root of trust. How? This part is not clear to me.
Sorry for being slow here. Can someone explain it in more details?

A PKCS#12 file can contain any number of arbitrary certificates (or
other objects).
There is already some ambiguity in determining which cert to use for
the server. Here we error out if we don't find exactly one cert with
appropriate usage flags.
The root CA cert can be the one that signed the server cert (the only
scenario that works now), or it can be any one along the chain.
If you have an intermediate CA signed by a well-known authority, you
would probably not want to trust *everything* signed by that
authority; you'd want to trust "your" root CA which can be anywhere
along the chain.

If we exclude scenarios with Intermediate CAs (which don't currently
work), the situation is much simpler, but we don't want to limit the
CLI to that.

Note that users can't usually carefully control what's inside the
PKCS#12 file: the tools will typically allow generating a file with
either only one cert, or with the entire chain.

Regardless...
If something can't be reliably determined then we should probably do
following:
If we have any issues with determining the root of trust we should fail
and request the caller to run the command again with additional command
line option that would explicitly provide the the name of the root CA.

Will that help?

That would be any time there's more than one CA in the trust chain.
Is it worth special-casing this? Are there real-world deployments that
only use one CA? Note that in this case you can just use a single-cert
PKCS#12 plus a PEM file for the CA, which is simple enough IMO.

So my point is that why we can't say that we support only a single-cert
PKCS#12 file plus a PEM file case and have a clear set of instructions
on how to produce these files?

The problem is that the user has very little control over what gets pulled in and doing so would probably require a whole lot of additional steps that may just make them throw up their hands altogether.

Take the NSS case. It will automatically pull in any needed CA certificates that are also in the database. So you'd have to go about deleting those certs prior to creating the PKCS#12 file or you'd have to create the PKCS#12 file, import it into a temporary NSS database, delete the unwanted certs, then re-create the PKCS#12 file. In short, rather a dreadful process.

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to