Open-source Languages & Tools for z/OS

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)

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

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