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.
--
Petr³
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
