Man, I am feeling stupid with this! I'm so frustrated that I am ready to quit and tell them to go find another developer.

I am the client side. As I said in the last email, the connection starts on the server sending "HELLO" in clear text to the IBMi. The IBMi responds back with its HELLO and part of its HELLO packet informs the server that it is capable of doing TLS1.2. At that point the server starts talking to the IBMi using TLS1.2. Does what you said in your first paragraph fit with that concept? The starting out in clear text and then going to TLS1.2 has me wondering. Do I use the normal socket read() and write() for the HELLO (because it is supposed to come and go clear text, not encrypted) and then switch the logic to the GSKit APIs? I'm thinking this yes but I am so confused that I want to confirm.

Now this is where I am totally lost. Using the GSKit APIs, how do I tell my program what certificate (or whatever the correct word is) to use so it is able to decrypt the communication?

This is why I am looking for a detailed set of steps for this. I don't know anything about any of this and have no idea what to try to search for with a google search.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Brad Stone
Sent: Wednesday, January 7, 2026 8:41 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: SSL communications programming

As a client you won't use a certificate. You just will want to "trust" the certificate that the server is using. That's all handled by the system.
You can either import the CA chain from their certificate, or, in the SSL APIs you have the option to ignore any "not trusted" errors from this.

I would also steer clear of the SSL APIs and make sure you're using the GSKit SSL APIs as years ago IBM called the SSL APIs "obsolete".

Now, if you are using a client side certificate then you'll tell it which certificate to use in the APIs during the handshake using an application ID that you set up in DCM and assign to a specific certificate. But it sounds like this is a client you're working on.



On Tue, Jan 6, 2026 at 8:38 PM <smith5646midrange@xxxxxxxxx> wrote:

I know I have started down this path a little while ago with questions
and got some good info to keep me rolling. I think that I understand
the concept of what needs to be done in the program.



For those that missed the first set of questions, I am working with a
company that has client / server software that is currently
communicating in clear text with their IBMi client and they want to
add TLS1.2. The server already has the ability to do TLS1.2 and it
already works with their Windows and Linux clients.



Let me quickly walk you through the high level of what the programs do.
Please forgive me if this sounds completely wrong. I am repeating
what I think I heard is the process.

1. The server sends a HELLO packet to the agent to initiate the
commumication. This packet is in clear text.
2. The agent returns a HELLO packet to the server. In this packet is
an SSL value that tell the server what modes the agent can process.
The values that we are concerned with are

a. NONE = 1
b. TLS = 3

3. If the agent sends back a 1, the server remains in clear text mode.
4. If the agent sends back a 3, the server then switches to TLS1.2
mode.



Now what I am trying to figure out is how to link the SSL APIs and the
certificate. I have already loaded the certificate in the DCM but
that is where I am stuck. Replacing an expired cert in the DCM is the
only thing I have ever done with DCM.



I know I need to use the SSL APIs for the communication (SSL_Read,
SSL_Write, etc.) but how do they know which certificate to use? I've
looked at SSL_Init_Application thinking that might be the missing
piece but I'm not understanding the definitions of the parameters.
For the first parm, do I have to use the QsyRegisterAppForCertUse API
or is this something that can be done in DCM?



Does anyone know of any good documentation that would walk me through
how all of these pieces fit together.



Thanks in advance.





--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.