in reply to Re^3: Net::SSLeay::connect -> -1
in thread Net::SSLeay::connect -> -1

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

Replies are listed 'Best First'.
Re^5: Net::SSLeay::connect -> -1
by haj (Vicar) on Oct 24, 2018 at 12:38 UTC

    I admit that I've almost totally forgotten about the "random" part.... I myself have never seen timing issues (other than broken OCSP responders or certificate authorities with huge CRLs; with digicert this should not be a problem), but this is just personal experience.

    There are two other questions to narrow down the problem:

    • Does it work with browsers or do they have the same random issues? If browsers work just fine, this would point to a problem with Perl's libraries but still leave the question why your client works with other HTTPS sites.
    • Is this "one server" or something load-balanced? Check whether the server's name resolves to more than one IP address, and if so, point your client or OpenSSL's s_client to the individual IP-adresses and check whether it makes a difference.