running this script from a Linux machine against our Active Directory
---------------------------< schnipp schnapp >--------------------------
#!/usr/bin/perl
use Net::LDAPS;
$ldap = Net::LDAP->new(
'ldaps://<my_dc>:636',
timeout => 1000,
verify => 'require',
capath => '/etc/ssl/certs/',
) || die "cant make initial connection: $@";
$result - $ldap->bind(
'<my_dn>',
password => '<my_pass>',
) || die $!;
$ldap->unbind();
exit;
---------------------------< schnipp schnapp >--------------------------
gives the following result:
cant make initial connection: IO::Socket::SSL: Timeout at ./x line 4,
<DATA> line 253.
Any idea, why this might happen?
The same script from any Windows box in here works as expected.
versions:
- Novell SLES 10 (x86_64)
- Net::LDAP 0.36
- Net::SSLeay 1.32
- openssl 0.9.8a-18.23
TIA.
Bye.
Michael.
> - Novell SLES 10 (x86_64)
> - Net::LDAP 0.36
> - Net::SSLeay 1.32
> - openssl 0.9.8a-18.23
First thoughgt ...
SLES has some iptables filtering going by default, check whether
you can reach the port via telnet... if you get a connection refused
or a time-out, try with iptables disabled. If that works, tune your
iptables rules.
telnet my_dc 636
> TIA.
>
> Bye.
> Michael.
Cheers,
Andrej
--
Please don't top post, and don't use HTML e-Mail :} Make your quotes concise.
> On 19/07/2008, _V-IT-Systemhaus-Perl-LDAP von extern
> <Perl...@arbeitsagentur.de> wrote:
> > Hi *,
>
> > - Novell SLES 10 (x86_64)
> > - Net::LDAP 0.36
> > - Net::SSLeay 1.32
> > - openssl 0.9.8a-18.23
> First thoughgt ...
> SLES has some iptables filtering going by default, check whether
> you can reach the port via telnet... if you get a connection refused
> or a time-out, try with iptables disabled. If that works, tune your
> iptables rules.
there is no firewall active at all.
>
> telnet my_dc 636
Yes, works ok.
I can even get an LDAPS connection using openssl:
openssl s_client -connect <my_dc>:636 -CAfile <my_cafile> -ssl3
>
>
> > TIA.
> >
> > Bye.
> > Michael.
> Cheers,
> Andrej
Thx for your answer.
Bye.
Michael.
running this script from a Linux machine against our Active Directory
---------------------------< schnipp schnapp >--------------------------
#!/usr/bin/perl
use Net::LDAPS;
$ldap = Net::LDAP->new(
'ldaps://<my_dc>:636',
timeout => 1000,
verify => 'require',
capath => '/etc/ssl/certs/',
) || die "cant make initial connection: $@";
$result - $ldap->bind(
'<my_dn>',
password => '<my_pass>',
) || die $!;
$ldap->unbind();
exit;
---------------------------< schnipp schnapp >--------------------------
gives the following result:
cant make initial connection: IO::Socket::SSL: Timeout at ./x line 4,
<DATA> line 253.
Any idea, why this might happen?
The same script from any Windows box in here works as expected.
versions:
- Novell SLES 10 (x86_64)
- Net::LDAP 0.36
- Net::SSLeay 1.32
- openssl 0.9.8a-18.23
TIA.
Bye.
Michael.
Can you write a simple program just using IO::Socket::SSL that shows the
problem? If you can, then you should ask the IO::Socket::SSL developers
about it...
Cheers,
Chris
[...]
> Can you write a simple program just using IO::Socket::SSL
> that shows the
> problem? If you can, then you should ask the IO::Socket::SSL
> developers
> about it...
thx for this hint.
A newer version of IO::Socket::SSL (1.14) solved this problem.
But now I get
cant make initial connection: IO::Socket::SSL: SSL connect attempt failed
with unknown errorerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:
certificate verify failed at ./x line 4, <DATA> line 253.
when using verify => 'require'.
Without this option the connection request succeeds.
What am I missing here?
I read a lot of reports about this error in the web, but never a solution.
Is this also an IO::Socket::SSL problem?
>
> Cheers,
>
> Chris
>
Thx again.
Bye.
Michael.
> Hi Chris,
>
> [...]
>> Can you write a simple program just using IO::Socket::SSL
>> that shows the
>> problem? If you can, then you should ask the IO::Socket::SSL
>> developers
>> about it...
>
> thx for this hint.
> A newer version of IO::Socket::SSL (1.14) solved this problem.
Great!
> But now I get
>
> cant make initial connection: IO::Socket::SSL: SSL connect attempt
> failed
> with unknown errorerror:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:
> certificate verify failed at ./x line 4, <DATA> line 253.
>
> when using verify => 'require'.
> Without this option the connection request succeeds.
>
> What am I missing here?
>
> I read a lot of reports about this error in the web, but never a
> solution.
> Is this also an IO::Socket::SSL problem?
No, this is just because of the way you're configuring the socket.
Using verify => require means that the server's SSL certificate is
*required* to be checked by IO::Socket::SSL, and if that check fails
the socket is closed.
The common reason for a certificate check to fail is that you don't
have (or don't trust) the signing CA's certificate. In Net::LDAP, you
configure that using either cafile or capath. Without looking at the
code, I can't remember what IO::Socket::SSL methods that ends up
using :-) Note the Net::LDAP manpage talks about certificate
verification.
By default IO::Socket::SSL *probably* uses a default capath pointing
at the CA certificates installed with the copy of OpenSSL that it
uses, so you could try installing your CA certificate in that
directory. (There's a special way to install a CA certificate, check
the OpenSSL docs for all the details.)
Cheers,
Chris
[...]
> > cant make initial connection: IO::Socket::SSL: SSL connect attempt
> > failed
> > with unknown errorerror:14090086:SSL
> > routines:SSL3_GET_SERVER_CERTIFICATE:
> > certificate verify failed at ./x line 4, <DATA> line 253.
> >
> > when using verify => 'require'.
> > Without this option the connection request succeeds.
> >
> > What am I missing here?
> >
> > I read a lot of reports about this error in the web, but never a
> > solution.
> > Is this also an IO::Socket::SSL problem?
>
> No, this is just because of the way you're configuring the socket.
> Using verify => require means that the server's SSL certificate is
> *required* to be checked by IO::Socket::SSL, and if that check fails
> the socket is closed.
[...]
> By default IO::Socket::SSL *probably* uses a default capath pointing
> at the CA certificates installed with the copy of OpenSSL that it
> uses, so you could try installing your CA certificate in that
> directory. (There's a special way to install a CA certificate, check
> the OpenSSL docs for all the details.)
uhm, I thought, I had understood and configured that correctly 8-(
Shouldn't think too much.
I installed our root certificate in /etc/ssl/certs, where "capath"
points
to. The .pem file is correctly linked to the file with the hashed name
of
itself.
But I will double check this - obviously something is wrong here.
>
> Cheers,
>
> Chris
>
Thx.
Bye.
Michael.
> uhm, I thought, I had understood and configured that correctly 8-(
> Shouldn't think too much.
>
> I installed our root certificate in /etc/ssl/certs, where "capath"
> points
> to. The .pem file is correctly linked to the file with the hashed name
> of
> itself.
> But I will double check this - obviously something is wrong here.
Try using something like truss (Linux uses strace?) to see what files
in that directory are actually getting opened.
Is the server returning a complete chain of certificates?
Cheers,
Chris
[...]
> > I installed our root certificate in /etc/ssl/certs, where "capath"
> > points
> > to. The .pem file is correctly linked to the file with the
> hashed name
> > of
> > itself.
> > But I will double check this - obviously something is wrong here.
>
> Try using something like truss (Linux uses strace?) to see
yes, Linux has strace.
> what files in that directory are actually getting opened.
Thx for this hint, I will give it a try, but the logfile usually gets
huge.
>
> Is the server returning a complete chain of certificates?
Uhm, this really seems to be the reason for that problem.
And whats more - I'm no longer sure that I use the correct certificate
at all. Will check all of this next week.
>
> Cheers,
>
> Chris
>
Thx and bye.
Michael.