Having trouble with TLS and server verification

[Paul Liu]

Hi,

I'm trying to use Net::LDAP to do LDAPS authentication against my Server 2008 Active Directory and I'm having a hard time getting server verification to work.

So far, my (super simple) code works if I use verify => none in start_tls, but as soon as I set it to "require" or "optional", I get this error:

SSL connect attempt failed with unknown error error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm at ./ldap.pl line 23, line 522.

When I test from the command line using Openssl s_client it works okay, so I don't think it's an OpenSSL problem. But I'm kind of a noob with Perl, so I'm not sure what else to debug next.

Here's the relevant code snippet:

#!/usr/bin/perl
use Net::LDAP;

$ldap = Net::LDAP->new('ho.mydomain.com',
) or die "LDAP error";
$mesg = $ldap->start_tls(
sslversion => 'tlsv1',
verify => 'require',
capath => '/etc/ssl/certs/',
);
die $mesg->error if $mesg->is_error;

All the certs in the chain are signed with SHA512RSA. Also the CA Cert is 4096 bits and the server certs I am checking are all 2048 bits. I thought I might be missing a module or something, but I am pretty sure I have all the prerequisites installed, including Digest::SHA, Digest::HMAC and IO::Socket::SSL. I'm kind of stuck. Has anyone ever had this problem before? I'm working with Perl 5.10 on SLES 11 SP1. My OpenSSL version is 0.9.8h.

Thanks very much,
Paul

[Dieter Kluenter]

Paul Liu <paul...@kanetix.ca> writes:

start_tls is an extended operation on port 389 and ldap uri, use port
636 and ldaps uri.

-Dieter

--
Dieter Klünter | Systemberatung
sip: 777...@sipgate.de
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6

[Paul Liu]

Hi, thanks for the info. I still have the same error with LDAPS instead of TLS. The behaviour is the same too, it works if I don't require verification, but fails if I do.

[Prentice Bisbal]

Paul,

Check the permsissions ownership of your certificates and the directory
containing them. Also check that there are no typos in your capath.

I'm using start_tls without a problem. Here's an example of my code in a
subroutine.

Since I don't know if the server(s) in @servers are
ldap://host.example.com or ldaps://host.example.com, I check the scheme
and then start_tls if the server is of the form ldap://host.example.com.

Prentice

sub ldap_connect
{
my $description = $_[0];
my $cacertfile = $_[1];
my $debug = $_[2];
my @servers = $_[3];

my $ldap;
my $mesg;
my $scheme;
my $code;
my $error;

if ($debug) {
print "Connecting to $description\n";
}

$ldap = Net::LDAP->new(@servers);
if ($ldap) {
if ($debug) {
print "Connected to $description\n";
}
$scheme = $ldap->scheme;
# If scheme != 'ldaps', Start TLS. Fail if we can't.
if ($scheme ne 'ldaps') {
$mesg = $ldap->start_tls(verify=>'require',
cafile => $cacertfile);
$code = $mesg->code;
if ($code == 0) {
if ($debug) {
print "Started TLS on $description\n";
}
} else {
$error = $mesg->error;
print "$error\n";
print "Error: Could not start TLS for $description\n";
$ldap->unbind;
return(undef);
}
} else {
if ($debug) {
print "TLS already started for $description\n";
}
}
return($ldap);
} else {
print "Error: Could not connect to $description\n";
return(undef);
}
}

--
Prentice Bisbal
Linux Software Support Specialist/System Administrator
School of Natural Sciences
Institute for Advanced Study
Princeton, NJ

[Dieter Kluenter]

Paul Liu <paul...@kanetix.ca> writes:

> Hi, thanks for the info. I still have the same error with LDAPS
> instead of TLS. The behaviour is the same too, it works if I don't
> require verification, but fails if I do.

man s_client(1)

openssl s_client connect ldaphost:636 -CAfile <path to CA> -showcerts

-Dieter

[Paul Liu]

Hi,

Thanks for your help. I have determined that the problem was actually with OpenSSL after all. Verification fails on 0.9.8h, but I have confirmed it works on 0.9.8k. I tested it with s_client and when that worked I assumed the problem must have been in Perl, but actually it turns out s_client is a liar. As you can see, it returns okay with s_client on the host with old OpenSSL:

overwatch:~ # openssl s_client -connect DC03.ho.mydomain.com:636 -showcerts -CApath /etc/ssl/certs -verify 5
verify depth is 5
CONNECTED(00000003)
depth=1 /DC=com/DC=mydomain/DC=ho/CN=DC01
verify return:1
depth=0 /CN=dc03.ho.mydomain.com
verify return:1
---
Certificate chain
0 s:/CN=dc03.ho.mydomain.com
i:/DC=com/DC=mydomain/DC=ho/CN=DC01
-----BEGIN CERTIFICATE-----
[snip]
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=dc03.ho.mydomain.com
issuer=/DC=com/DC=mydomain/DC=ho/CN=DC01
---
Acceptable client certificate CA names
/CN=dc03.ho.mydomain.com
/DC=com/DC=mydomain/DC=ho/CN=DC01
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
/OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority
/CN=NT AUTHORITY
---
SSL handshake has read 2631 bytes and written 477 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID: [snip]
Session-ID-ctx:
Master-Key: [snip]
Key-Arg : None
Start Time: 1279127821
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

But then with curl (or anything else, like for example IO::Socket::SSL):

overwatch:~ # curl --capath /etc/ssl/certs/ -v https://DC01.ho.mydomain.com (A webserver with a separate cert is also running on DC01)
* About to connect() to DC01 port 443 (#0)
* Trying [ip]... connected
* Connected to DC01 ([ip]) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm
* Closing connection #0
curl: (35) error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm

I'm not sure what the cause is precisely (something to do with using SHA512RSA maybe), but it works on OpenSUSE 11.2 and Kubuntu 10.04 (both with OpenSSL 0.9.8k) but not on SLES11 SP1 (OpenSSL 0.9.8h). But in any case, Net::LDAP is definitely not the cause.

Thanks again for the help,
Paul