z/OS Tools & Language

Expand all | Collapse all

OPENSSL s_client -connect fails

  • 1.  OPENSSL s_client -connect fails

    Posted 04-17-2019 15:53

    We have openssl installed but when I issue the following command results in no peer certificate and No client certificate CA names sent.

    Would this be because of the openssl not pointed to a certificate bundle?

    Command issued:
    openssl s_client -connect sfcertrequestTEST256.support.statefarm.org:443

    ***** Results ******
    CONNECTED(00000003)

    no peer certificate available

    No client certificate CA names sent

    SSL handshake has read 7 bytes and written 307 bytes

    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    SSL-Session:
    Protocol : TLSv1.2
    Cipher : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1555530422
    Timeout : 300 (sec)
    Verify return code: 0 (ok)



  • 2.  RE: OPENSSL s_client -connect fails

    Posted 04-19-2019 12:02

    We have installed in a different directory path than the default. Do we need to update other files with this new directory path for it to work?

    I look in files like:
    /sf/openssl.test/bin/c_rehash and they contain the default path
    my $dir = “/rsusr/rocket/ssl”;

    or

    /sf/openssl.test/lib/pkgconfig/openssl.pc

    prefix=/rsusr/rocket
    exec_prefix={prefix} libdir={exec_prefix}/lib
    includedir=${prefix}/include

    Name: OpenSSL
    Description: Secure Sockets Layer and cryptography libraries and tools
    Version: 1.0.2h
    Requires: libssl libcrypto



  • 3.  RE: OPENSSL s_client -connect fails

    Posted 04-26-2019 13:02

    *** Solved ****

    Running on Z/OS and attempting the connection to the server over port 443 was failing. However I attempted a connection to another server listening for HTTPS traffic on a non-standard port (10443) and the connection worked!!!

    Further investigation led us to the fact that AT-TLS setup on comservr was setup to route any client or server traffic routed on port 443 to leverage the default key ring /* AUTH */ .

    So when the server attempted to send the Hello back it was corrupting the traffic back because of the comservr intercepting the traffic on 443 and leveraging the default key ring.