The SIOgCertData (Get Certificate Data) IOCTL call extracts local or peer certificate data from an established TLS connection and returns it to the application. You can request the entire certificate and decode it (ASN.1), or you can request specific attributes culled from the distinguished name (DN) in the certificate. Unfortunately, if you want data from a Subject Alternate Name (SAN) extension that was not also encoded in the DN (such as an email address), then you will have to decode the certificate yourself.
While REXX Sockets does not include support for this IOCTL, I think you should be able to call the BPX1IOC CSL routine to get the data. Of course, your server must indicate that it wants a client certificate and it must decide what to do about the lack of a user certificate or an invalid certificate. When you establish a *client* connection to a server, you (the client) can provide information that will be compared to data within the server's certificate. Specifically, you can specify an IP address or a host name. It will be compared to the CN or SAN, and wildcard certificates are supported. It allows the client program to verify that your desire to connect to myhost.company.com was met with a certificate bound to that name. (If the server has a valid certificate, but it's for otherhost.company.com, then you may have a security problem.) Regards, Alan Alan Altmark IBM Senior z/VM Engineer and Consultant 1 607 321 7556 (Mobile) [email protected] > -----Original Message----- > From: CMSTSO Pipelines Discussion List <[email protected]> On > Behalf Of Rob van der > Heij > Sent: Saturday, June 14, 2025 12:08 PM > To: [email protected] > Subject: [EXTERNAL] Re: [CMS-PIPELINES] Tcplisten secure > > No you can't look inside, at least not with what we get from VM SSL. A client > certificate is within the > handshake, so the best you can do at that point is to close the connection. > But again, not really with > what you get from VM SSL. > I don't have a solution for your authentication requirements.
