Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
FYI, setting verify='none' doesn't help. –  Jayen Oct 31 '11 at 8:08

3 Answers 3

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.

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

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
share|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 '12 at 8:53
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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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