Several things.. I noticed you have LABEL00000002 CERTAUTH CERTAUTH NO
this is bad practice - it is better to give each certificate a meaningful label - so you know which CA's you have. Try using https://colinpaice.blog/2024/02/21/zwireshark-capturing-tcpip-trace-on-z-os-and-displaying-it-in-wireshark/ Most tools like gsktrace just dump out the hex data and do not interpret it which makes it very hard to debug problems My program captures the trace, and you can feed the output file into wireshare and so get all the fields interpreted. See https://colinpaice.blog/2023/10/11/understanding-a-wireshark-tls-handshake-trace/#certReq for an explanation of a TLS flow.. in summary There are several flows to a TLS handshake CLIENT HELLO The client initiates contact with the server saying I support these ciphers spec. SERVER HELLO Use this cipher spec. Here is my certificate Here is a list of CA certificates I know about. Please send me a certificate _______ Client then takes each CA in turn, looks for a valid certificate in the certificate store which uses that CA, and checks some other options from the server. If one is found - then send it up to the server. Else -- try the next CA. else return not found. The above is not 100% accurate - but give you the idea. __________________ So it may be that you do not have the CA from the server in your keystore. It may be that the server is asking for only an RSA handshake - but your certificate is EC.... there are several things that can go wrong in this area. Colin On Tue, 26 Aug 2025 at 19:37, 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 > > RC: 7 = “No certificates available.” > https://www.ibm.com/docs/en/zos/2.5.0?topic=sfrc-1#idg27338 > > I’ll add more details below, but we have configured the keys and > CA-signed crertificates both in RACF and in an omvs key database. Both > methods currently yield the same RC: 7 result. > > We can successfully connect using `openssl` pointing to the relevant key > and cert, but not from the client/PAGENT application. > > Any insight or pointers will be greatly appreciated. Adding some > additional details below. > > Thanks, > Brick Jones > The University of Texas at Austin > > > > The output of “pasearch -t” suggests the rules for ConnRuleJPMorganUAT > should lead to selection of expected certificate, for which we provided the > “Certificate Label” value: > Keyring: /var/pkiserv/jpmorgan/JPMkeys.kdb > > KeyringStashFile: /var/pkiserv/jpmorgan/JPMkeys.sth > > CertificateLabel: FinAppUAT > > When using RACF: > > CertificateLabel FinAppCertUAT > > Keyring DPDBA/AUTRNG > > > gskkyman tool shows: > > Key and Certificate List > > > Database: /SYSTEM/var/pkiserv/jpmorgan/JPMkeys.kdb > > > > 1 - FinAppUAT > > > and > > Certificate Information > > > Label: FinAppUAT > > Record ID: 14 > > Issuer Record ID: 13 > > Trusted: Yes > > > > The key database also has the CA and intermediate certs for both the > remote partner and the for the client certificate. Per JPMorgan > requirements, it is not a self-signed certificate. > > Certificate List > > > Database: /SYSTEM/var/pkiserv/jpmorgan/JPMkeys.kdb > > > > 1 - DigiCertGlobalRootG2 > > 2 - AAA Certificate Services > > 3 - USERTrust RSA CA > > 4 - InCommon RSA Server CA 2 > > 5 - DigiCert EV RSA CA G2 > > 6 - JPM Transport UAT > > > RACF: > > >AUTRNG< > > Certificate Label Name Cert Owner USAGE DEFAULT > > -------------------------------- ------------ -------- ------- > > AAA Certificate Services Root CERTAUTH CERTAUTH NO > > LABEL00000002 CERTAUTH CERTAUTH NO > > LABEL00000001 CERTAUTH CERTAUTH NO > > FinAppCertUAT ID(DPDBA) PERSONAL YES > > DigiCert Global Root G2 CERTAUTH CERTAUTH NO > > DigiCert Intermediate Root G2 CERTAUTH CERTAUTH NO > > JPMorganCertUAT ID(DPDBA) PERSONAL NO > > > > ---------------------------------------------------------------------- > 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
