in reply to Net::SSLeay::connect -> -1

Just a guess, from memory of a similar experience: Do you have some "non-standard" server certificate, e.g. issued by an inhouse CA? If so, maybe there's an issue with the OCSP responder of that certificate. If IO::Socket::SSL can't retrieve an OCSP response, it can't proceed and will apparently hang until the server gives up and terminates the connection.

To isolate this problem, you can disable server certificate checking for testing only by setting SSL_verify_mode => SSL_VERIFY_NONE in the ssl_opts of your LWP user agent. If the problem persists, remove that insecure setting and look elsewhere; if the problem vanishes, examine the certificate: Maybe the OCSP URL can't be reliably received, or it uses a non-standard transport mechanism/port which is blocked by a firewall.

Replies are listed 'Best First'.
Re^2: Net::SSLeay::connect -> -1
by bliako (Abbot) on Oct 23, 2018 at 22:00 UTC

    Thanks for the hint. I tried it but the errors still persist. This is what I did:

    my $ua = LWP::UserAgent->new(ssl_opts => { verify_hostname => 0, SSL_v
+erify_mode => IO::Socket::SSL::SSL_VERIFY_NONE });

    [download]

    Btw, on hitting google I can see mention of OCSP:

    DEBUG: .../IO/Socket/SSL.pm:750: using SNI with hostname www.google.co
+m
DEBUG: .../IO/Socket/SSL.pm:785: request OCSP stapling
...

    [download]

    But with the server I am using there is no mention of OCSP with or without SSL_verify_mode => SSL_VERIFY_NONE. Does the following log suggest that SSL is set after a lot of failed (-1) attempts but finally the handshake is done? Because it is after that successful handshake that the server closes the connection.

    DEBUG: .../IO/Socket/SSL.pm:2853: new ctx 93967426517920
DEBUG: .../IO/Socket/SSL.pm:692: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:694: socket connected
DEBUG: .../IO/Socket/SSL.pm:717: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:750: using SNI with hostname xyz.com
DEBUG: .../IO/Socket/SSL.pm:806: set socket to non-blocking to enforce
+ timeout=60
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:832: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:842: waiting for fd to become ready: SSL w
+ants a read first
DEBUG: .../IO/Socket/SSL.pm:862: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:832: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:842: waiting for fd to become ready: SSL w
+ants a read first
DEBUG: .../IO/Socket/SSL.pm:862: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:832: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:842: waiting for fd to become ready: SSL w
+ants a read first
DEBUG: .../IO/Socket/SSL.pm:862: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:832: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:842: waiting for fd to become ready: SSL w
+ants a read first
DEBUG: .../IO/Socket/SSL.pm:862: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> 1
DEBUG: .../IO/Socket/SSL.pm:877: ssl handshake done
DEBUG: .../IO/Socket/SSL.pm:2875: free ctx 93967426517920 open=9396742
+6517920
DEBUG: .../IO/Socket/SSL.pm:2886: OK free ctx 93967426517920

    [download]

    thanks, bliako

[reply]
[d/l]
[select]
      Does the following log suggest that SSL is set after a lot of failed (-1) attempts but finally the handshake is done?

      As far as I recall a -1 isn't a failure. It just indicates that the handshake isn't completed and yet another round of negotiation is required. So the return value 1 just says that the SSH handshake is done, but maybe server and client haven't found a common ground? During the handshake the SSL protocol version / TLS protocol version, the crypto algorithm and its parameters like forward secrecy need to be agreed upon. "Modern" web servers and "modern" LWP should easily find agreeable values, problems arise if an old or unpatched server only supports features which are considered not secure enough by a recent client - or vice versa.

      With OpenSSL's s_client you can dig into the steps of the handshake (expect lots of output):

      openssl s_client -connect your.server:443 -debug

      [download]
[reply]
[d/l]

        OK, I will check the output of your last suggestion. The server has just recently introduced "https" access, so I presume they are using something modern. I see IBM HTTP_server in the headers - don't know if that's comfort or woe. And the certificate is issued by /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA

        Would you agree that if the connection-closed-zero-data-received errors appear randomly then it is not likely that incompatibility issues are involved but rather, say, timing issues? I also tried with a fixed user-agent-string with same random problems.

        thanks for your help, bliako

[reply]
[d/l]

In Section Seekers of Perl Wisdom