Actually, I inherited the current socket logic but I have played with it enough to understand it. :) Like I told someone offline, if I have a working shell, I can disassemble it an learn a ton during the disassembly.

I recently found out about Scott using the GSKit so I will be digging into that at some point.

I have been given the certificate from the server side to add to the IBMi.

I originally thought certs were like encryption keys which I realize after some digging around that they are not. I think I still keep using the words encrypt or decrypt though.

After all of this, I think the company has just changed priorities and wants me to work on a different enhancement. I'm sure I will be circling back for more information as I get back into this.

I have gotten some really good information from everyone and I appreciate all of the help.



-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Charles Wilt
Sent: Thursday, January 8, 2026 9:50 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: SSL communications programming

Take a breath...

You did the plain sockets stuff, this isn't much different.

You don't use certificates to encrypt/decrypt.
Certificates are only used to prove a machine's identity. Unless you've been given a specific client cert, or been told to generate one and pass it along to the server guys, you don't need to worry about it.

By default, clients will attempt to validate the certificate presented by the server.
Client - "Hey I want a talk securely to google.com"
Server - "I'm google.com, here's the cert to prove it"

They do this by ensuring that the presented cert is digitally signed by a trusted Certificate Authority (CA) The IBM i and PC both have a set of trusted CA's included in the OS. The PC's tends to have a larger list.
Thus the reason IBM i folks sometimes have to load additional certificates to the DCM.

But another option is to simply turn off the validation of the server cert. I wouldn't recommend doing so if you're passing data to a bank for instance. But if you're talking to an internal server with a "self-signed"
certificate, it makes things easier.

HTH,
Charles


On Wed, Jan 7, 2026 at 6:32 PM <smith5646midrange@xxxxxxxxx> wrote:

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.


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

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.