up vote 1 down vote favorite
share [g+] share [fb]

machines:

  1. debian wheezy
  2. suse 11

commands:

  1. ldapsearch -ZZ -h ad.unsw.edu.au -x
  2. perl -we "use Net::LDAP; print Net::LDAP->new ('ad.unsw.edu.au')->start_tls(verify => 'require', capath => '/etc/ssl/certs/')->{errorMessage}"

results:

  • machine 1, command 1: TLS: hostname does not match CN in peer certificate
  • machine 1, command 2: works
  • machine 2, command 1: works
  • machine 2, command 2: Cannot determine peer hostname for verification

i can't explain the inconsistency and i really want command 2 to work on machine 2. any ideas?

after an strace, it looks like debian-ldapsearch is looking at /etc/ssl/certs/ca-certificates.crt and suse-ldapsearch is looking at NOTHING. debian-Net::LDAP is looking at /etc/ssl/certs/157753a5.? (AddTrust_External_Root.pem) and suse-Net::LDAP is looking at NOTHING.

link|improve this question
33% accept rate
FYI, setting verify='none' doesn't help. – Jayen Oct 31 '11 at 8:08
feedback

3 Answers

up vote 1 down vote

You should check that the remote SSL certificate has "CN" part of the subject same as the hostname of the LDAPS server in your commands (ad.unsw.edu.au).

To see the remote certificate use:

echo ""|openssl s_client -connect ad.unsw.edu.au:636 |openssl x509 -noout -subject -dates -issuer

Full details:

echo ""|openssl s_client -connect ad.unsw.edu.au:636 |openssl x509 -noout -text

Check that the issuer's root certificate is imported and trusted in the ldap (see OpenLDAP SSL documentation) and perl SSL keystore (see IO::Socket::SSL). If it is a selfsign certificate, then that certificate should be added to the trusted SSL keychain.

link|improve this answer
1  
Interesting paths to openssl client, considering @Jayen seems to have Linux environment. I can see your Solaris-Fu is strong. :-) – Janne Pikkarainen Oct 31 '11 at 13:57
Yes :). I have a strong feeling that the /usr/sfw is missing in Linux. I will edit my answer. – Mircea Vutcovici Oct 31 '11 at 14:12
yup: echo -n | openssl s_client -connect ad.unsw.edu.au:636 | openssl verify -CAfile /tmp/COMODOHigh-AssuranceSecureServerCA.crt thanks! – Jayen Oct 31 '11 at 22:10
er no. even after installing the certificate, perl & ldapsearch aren't picking it up and the results are still the same. – Jayen Oct 31 '11 at 22:21
Use strace to see which file is trying to use perl and ldapsearch. Make sure they are reading the trusted certificated keychain. – Mircea Vutcovici Oct 31 '11 at 22:32
show 1 more comment
feedback
up vote 0 down vote accepted

line 233 of Net/LDAP.pm in Net::LDAP 0.43 says

SSL_verifycn_scheme => "ldap",

debian wheezy is using 0.40, but upgrading to 0.43 from unstable breaks it as well.

https://rt.cpan.org/Public/Bug/Display.html?id=70795

link|improve this answer
feedback
up vote 0 down vote

Net::LDAP::start_tls() is broken in perl-ldap-0.43. Your command-line should work fine if you upgrade to 0.44 or later. This is documented in the Changes file:

http://cpansearch.perl.org/src/MARSCHAP/perl-ldap-0.44/Changes

Bug Fixes
 * un-break certificate verification
link|improve this answer
thanks for that. i found a fix in github, and i wonder why they didn't release 0.44 sooner. github.com/perl-ldap/perl-ldap/pull/3 – Jayen Feb 18 at 8:53
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.