(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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
