Perhaps the cause is the obvious: RACDCERT has some options which require ICSF. For example a certificate that is migrated from one RACF system to another will have PKDS. So fairly easy to wind up using ICSF unexpectedly.
On Sat, Jun 22, 2024 at 8:12 AM Phil Smith III <[email protected]> wrote: > (Cross-posted to IBMTCP-L and IBM-MAIN) > > Had an odd one this morning: a customer who was doing some testing could > not connect to our server (on premises at their site) from z/OS (server is > an x86 Linux machine). I saw the email when I woke up and thought "OK, > gsktrace to the rescue!" > > But by the time I got to my desk, I had more email saying "Nevermind, ICSF > wasn't running--once we started it, all is fine". And now that's working, > they can't break it again to run with gsktrace. > > Meanwhile, I can connect just fine without ICSF running. Of course, that's > to one of OUR versions of the same server, using one of OUR certificates. > Wild guess is that the customer's cert is using some certificate feature > that requires ICSF interpretation, but I had them send me both the root and > the leaf, and various online cert analyzers don't show anything obvious. > > Anyone know of any certificate features that absolutely require ICSF > intervention? Our product uses GSK directly -- no AT-TLS or anything like > that. > > I realize this is vague but hoping someone (maybe at IBM?) has a guess... > > Thanks, > ...phsiii > > ---------------------------------------------------------------------- > 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
