Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

IO::Socket::SSL: Timeout

497 views
Skip to first unread message

_V-IT-Systemhaus-Perl-LDAP von extern

unread,
Jul 18, 2008, 11:13:16 AM7/18/08
to perl...@perl.org
Hi *,

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.

Andrej Ricnik-Bay

unread,
Jul 18, 2008, 5:23:51 PM7/18/08
to _V-IT-Systemhaus-Perl-LDAP von extern, perl...@perl.org
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.

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.

http://www.american.edu/econ/notes/htmlmail.htm

_V-IT-Systemhaus-Perl-LDAP von extern

unread,
Jul 21, 2008, 4:50:45 AM7/21/08
to perl...@perl.org
Hi,

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

_V-IT-Systemhaus-Perl-LDAP von extern

unread,
Jul 21, 2008, 4:43:45 AM7/21/08
to perl...@perl.org
Hi *,

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.

Chris Ridd

unread,
Jul 21, 2008, 2:02:23 PM7/21/08
to _V-IT-Systemhaus-Perl-LDAP von extern, perl...@perl.org
_V-IT-Systemhaus-Perl-LDAP von extern wrote:
> Hi,
>
>> 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

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

_V-IT-Systemhaus-Perl-LDAP von extern

unread,
Jul 22, 2008, 5:59:46 AM7/22/08
to perl...@perl.org
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.

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.

Chris Ridd

unread,
Jul 23, 2008, 2:14:17 AM7/23/08
to Perl-LDAP Mailing List

On 22 Jul 2008, at 10:59, _V-IT-Systemhaus-Perl-LDAP von extern wrote:

> 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

_V-IT-Systemhaus-Perl-LDAP von extern

unread,
Jul 24, 2008, 1:13:32 PM7/24/08
to Perl-LDAP Mailing List
Hello,

[...]


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

Chris Ridd

unread,
Jul 24, 2008, 3:47:13 PM7/24/08
to Perl-LDAP Mailing List

On 24 Jul 2008, at 18:13, _V-IT-Systemhaus-Perl-LDAP von extern wrote:

> 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

_V-IT-Systemhaus-Perl-LDAP von extern

unread,
Jul 25, 2008, 10:47:48 AM7/25/08
to Perl-LDAP Mailing List
Hi 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.

0 new messages