Received: by 10.204.154.143 with SMTP id o15mr460745bkw.4.1330166702906;
        Sat, 25 Feb 2012 02:45:02 -0800 (PST)
Newsgroups: perl.ldap
Path: t13ni68027bkb.0!nntp.google.com!news2.google.com!news.glorb.com!usenet.stanford.edu!nntp.perl.org
Return-Path: <chrisr...@mac.com>
Mailing-List: contact perl-ldap-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl-l...@perl.org
Received: (qmail 20943 invoked from network); 25 Feb 2012 10:32:29 -0000
Received: from x1.develooper.com (207.171.7.70)
  by x6.develooper.com with SMTP; 25 Feb 2012 10:32:29 -0000
Received: (qmail 2226 invoked by uid 225); 25 Feb 2012 10:32:29 -0000
Delivered-To: perl-l...@perl.org
Received: (qmail 2222 invoked by alias); 25 Feb 2012 10:32:29 -0000
X-Spam-Status: No, hits=-2.6 required=8.0
	tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD
X-Spam-Check-By: la.mx.develooper.com
Received: from st11p02mm-asmtp004.mac.com (HELO st11p02mm-asmtpout004.mac.com) (17.172.220.239)
    by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sat, 25 Feb 2012 02:32:26 -0800
MIME-version: 1.0
Received: from [192.168.0.104] ([77.102.38.131]) by st11p02mm-asmtp004.mac.com
 (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug
 10 2011)) with ESMTPSA id <0LZY00LF52LV0...@st11p02mm-asmtp004.mac.com> for
 perl-l...@perl.org; Sat, 25 Feb 2012 10:32:22 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
 engine=2.50.10432:5.6.7498,1.0.260,0.0.0000
 definitions=2012-02-24_07:2012-02-24,2012-02-24,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam
 adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000
 definitions=main-1202250040
Subject: Re: LDAPS via Oracle Internet Directory
In-reply-to: <20120223221922.11205.qmail@lists-nntp.develooper.com>
Date: Sat, 25 Feb 2012 10:32:19 +0000
Cc: perl-l...@perl.org
Message-ID: <9573197E-1F0A-4FE6-922F-919EEE2817A5@mac.com>
References: <20120223221922.11205.qm...@lists-nntp.develooper.com>
To: tBM <t...@somewhere.com>
X-Mailer: Apple Mail (2.1257)
Approved: n...@nntp.perl.org
From: chrisr...@mac.com (Chris Ridd)
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII


On 23 Feb 2012, at 22:19, tBM wrote:

> First let me ask for your forgiveness, I am a perl newbie.
> 
> We have a little perl script that is currently doing cleartext authentication against Oracle Internet Directory 10G that we've revised to use LDAPS and have the following in our NET::LDAP component:
> 
> verify => 'require', cafile => './OIDcertificate.pem'
> 
> The authentication is successful, but the part in the Wireshark packet scan where the "Certificate, Server Hello Done" is not there. It would look like this:
> 
> 
> - Certificate, Server Hello Done
>  Secure Socket Layer
>    Handshake Protocol: Certificate
>      Certificates
>        (here's where the certificate(s) are seen
> 
> 
> When other products pointed to our Oracle Internet Directory (which are also doing secure ldap) connect, the "Certificate, Server Hello Done" component is in the packet scan.
> 
> It looks like the verify => require is not happening.

I'm not so familiar with how Wireshark represents TLS traffic, but I think you're misinterpreting the verify setting.

During a TLS connection, the server sends the client its certificate (and maybe some CA certificates). The client is expected to verify 1) that the certificate is valid - signed by a CA it trusts to sign TLS certificates - *and* 2) is for the server that the client thinks it is talking to.

Setting verify to require should mean that these two steps are taken in the client. Having said that, Net::LDAP didn't used to do the final check until recent versions.

I don't think changing the verify setting will cause any change in the TLS traffic. Apart from stopping it completely if the checks fail!

Can you try other OpenSSL-based clients against that LDAP server? The openssl program can do it directly:

openssl s_client -connect server.example.com:636 -showcerts -debug -CAfile ./OIDcertificate.pem

It is important for step 2 that the hostname you are passing to Net::LDAP->new() is identical to the name in the certificate that the server returns. In other words if the server is using a certificate with 'oid.somewhere.com' then you must connect to it using that full hostname as well. (There are some ways to put wildcards in the certificate, but that's the rough idea.)

Cheers,

Chris