+1 to what Dr. Phil said about gskkyman as opposed to RACF. RACF is a "corporate resource." If you are like me you hold your breath and say "I hope I am not screwing anything up. I hope I am not going to regret this" every time you issue a RACF command.
OTOH your private gsk database is your little kingdom. You are the emperor of GSK! Do anything you want! Delete certificates. Add certificates. Trust certificates. Untrust them (is untrust a word?). Delete the whole database and start over. And a gsk database is EXACTLY comparable to a keyring in System SSL's mind. If you get it working in a gsk database, move the certificates to a keyring and -- given the right permissions -- it should work exactly the same. (You all know that System SSL is the component that "does" SSL/TLS -- not Comm Server, not PAGENT, not RACF, not ICSF, not gskkyman, right? They all can play a part, but System SSL is who "does" the TLS protocol.) Now, on to the specific problem. The client certificate has its private key available, right? You say that. > We have entries for JPMorgan’s CA, Intermediate, and Server/Host certificate Dr. Phil can explain why you really don't want JPM's Intermediate in there, but it probably is not the problem today, and even in the future you probably won't encounter Phil's problem because certificates have now gotten a little smarter. I sent you a gsktrace cheat sheet separately, and posted it separately. Phil is right -- gsktrace tends to have the answers that they should have provided you to begin with. (For all we know, the problem is with the server certificate -- you're not even getting up to the client part for all we know.) Again, good luck! Charles On Tue, 26 Aug 2025 21:02:20 +0000, Jones, Brick T <[email protected]> wrote: >Many thanks. Here’s more info in response to questions. And happy to focus >just on gskkyman to get this resolved. > >Our (Natural/Adabas) application must initiate an outbound/client connection >to JPMorgan, and must use certificate-based, two-way SSL to do so. They >require a CA-signed certificate; self-signed certs are not allowed. They have >a list of approved CAs. Since everything works with “openssl” in the omvs >environment, we believe the base keys/certificates should work if properly >configured. > > Those tests were conducted using the same key files also imported into the > gskkyman database. > >I’ll check on usage PERSONAL; keys/certs are all Trusted. > >We did create a new/unique key database for this case, and believe that >AT-TLS/PAGENT is properly invoking it. We have entries for JPMorgan’s CA, >Intermediate, and Server/Host certificate, as well as the CA and Intermediate >of private-key and certificate being used to authenticate. (Way at the bottom >of initial email are displays of kdb contents.) > >I’m not sure we’ve convinced them to look at server-side logs although I’ve >asked them several times. In recent meeting their engineer was confident they >wouldn’t have any useful logs for a handshake error. (Thanksalot) > >I will look into gsktrace now, and would greatly appreciate a cheat-sheet if >available. > >Thanks so much! >Brick > > > > > >From: IBM Mainframe Discussnon List <[email protected]> on behalf of >Phil Smith III <[email protected]> >Date: Tuesday, August 26, 2025 at 3:18 PM >To: [email protected] <[email protected]> >Subject: Re: AT-TLS Client Authentication as Client > >Everything Charles said, plus: because gskkyman is easier to use, it's a good >way to at least convince yourself you have the right certificate. I've seen >wayyy too much time wasted on certs where it turned out the reason it wasn't >liking the cert was, guess what, it was the wrong one in the first place! Doh. >With gskkyman you can create a database containing EXACTLY the certificate(s) >you think you need, no key rings, no RACF profiles or authority, and it Just >Works. Or doesn't. > >Also, as he suggests, gsktrace can be invaluable. We have internal testing >(server certs, not client) where the QA folks keep forgetting and using old >self-signed certificates that work fine with TLSv1.2 but not with v1.3. But >the ostensible failure is just one of the generic "Me no like dat cert" >errors; gsktrace drills down to "Yo, dummy, RFC5280!" > >(Now, why the ostensible failure can't say that is a whole 'nother >discussion...) > >-----Original Message----- >From: IBM Mainframe Discussion List <[email protected]> On Behalf Of >Charles Mills >Sent: Tuesday, August 26, 2025 4:11 PM >To: [email protected] >Subject: Re: AT-TLS Client Authentication as Client > >@Brick, my sympathies. Certificates are a bear, and client certificates are >particularly a bear because (a.) they are uncommon and (b.) you have to turn >everything around backwards in your head relative to the more common server >certificates. > >FWIW, I do not think it is a keyring ownership problem but I could be wrong. > >I would focus on either RACF or gskkyman. They are both capable of doing this. >Pick one. gskkyman is often simpler and easier but your corporate security >folks might be happier with RACF. > >May Ilclarify? You are trying to connect to JP Morgan. You are the client and >they are the server. They have a requirement for client certificates. Do I >have that right? > >Have they told you exactly what certificate they expect? Not just "not >self-signed" but rather "it must be a ______ (something) certificate" and most >importantly "issued by XXX or YYY" (say, Verisign or Comodo)? > >IIRC the protocol correctly there is a provision for the server to specify >what certificate (by name? I have forgotten) it wants. Did they tell you >anything like that? > >Not looking at your problem but starting from scratch, what you will need is > >1. A certificate that meets their standards, in a gskkyman database or on a >RACF keyring, TRUSTed, usage PERSONAL. > >2. I believe that to accomplish that you will need to first install that >certificate's root and intermediates. You should put them on the keyring, >TRUSTed, usage CERTAUTH. You need the Intermediate(s) for sure because >SystemSSL will have to send them with the client certificate. > >What error are they seeing on their end? > >Have you tried a GSK trace of your application? Let me know if you could use a >"GSK trace cheat sheet." > >Good luck! > >Charles > >On Tue, 26 Aug 2025 18:27:06 +0000, Jones, Brick T ><[email protected]> wrote: > >>Hi folks, >> First time poster; thanks for your forbearance, and for your input if >> possible. >> >> We are on z/OS 2.5 and I am trying to add PAGENT/TTLS configurations to >> support outbound/Client TLS(https) calls requiring Client Authentication >> (MutualTLS/MTLS/two-way SSL). We successfully support similar calls in >> PAGENT with things like a pki database holding trusted CA certs, and >> SNI-required configs for sites using cloudflare, etc., but have not had this >> requirement for client authentication before. >> >> The error we are stuck on is: >>EZD1284I TTLS Flow GRPID: 00000027 ENVID: 000041B0 CONNID: 0301E51B RC: >>7 Call GSK_SECURE_SOCKET_INIT - 0000005030853750 >>EZD1283I TTLS Event GRPID: 00000027 ENVID: 000041B0 CONNID: 0301E51B RC: >>7 Initial Handshake 0000000000000000 00000050308B6800 0000000000000000 >>EZD1286I TTLS Error GRPID: 00000027 ENVID: 000041B0 CONNID: 0301E51B LOCAL: >>128.83.216.11..46868 REMOTE: 146.143.6.65..443 JOBNAME: ABUTBTJ USERID: DPBTJ >>RULE: ConnRuleJPMorganUAT RC: 7 Initial Handshake 0000000000000000 >>00000050308B6800 0000000000000000 > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >[email protected] with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN >>> This message is from an external sender. Learn more about why this << >>> matters at https://links.utexas.edu/rtyclf. << > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
