Ah sorry.. just realising that ID certs (& client auth) require private key lol.
I'm sure others will correct me if I'm wrong... afraid you've to use GENCERT, GENREQ and then get it signed by your off-mainframe PKI. That way, private keys for ID certificates exist on mainframe... which isn't an unusual way of doing things. Alternatively, I think PCOMM, HoD, etc. will have some support for working with external keystore for client auth. https://www.ibm.com/support/knowledgecenter/SSEQ5Y_14.0.0/com.ibm.pcomm.doc/books/html/admin_guide11.htm#cfgssl Check point #12 here. "Send Personal Certificate Trusted by Server" or "Select or Prompt for Personal Client Certificate" may work. For option 2, PCOMM lists Personal certificates from the following location: [certmgr.msc] ->[Current User->Personal -> Certificates] - KB ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, July 24, 2020 8:49 AM, Luke Wilby <[email protected]> wrote: > cURL requires the client's private key for mutual auth. > > I'm not familiar with CWET but I imagine the security considerations are the > same. > > My clients need to authenticate to the server. The server then needs to > perform authorization checks. > > It's the authentication part that we need to sort out. > > Our company's internal certificate management is done on Windows. Our Windows > clients have personal certificates, installed by our Windows team. They don't > have access to the private keys. > > Our z/OS clients don't have certificates and even if they did, they would > come from the Windows team and our clients wouldn't have access to the > private keys to issue the cURL call. > > > Just mentioned ASM / COB CWET for options really. > > They're a a lot more involved than the Python client (when that's > > available). > > curl is ok as a user, but when you want to productionize something, I would > > think the recommendation would be to use CWET. > > Not saying curl is a bad tool, it is handy & does what it does. > > Ease of use does not mean it's the solution of choice in many controlled > > environments. > > By loved I mean does it get upgrades/improvements? > > I don't know I'm just asking.. > > curl-ing a shell script directly is bit ... dangerous. > > Not in this case as the script is available to inspect. > > > > - KB > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, July 24, 2020 7:59 AM, David Crayford [email protected] > > wrote: > > > > > On 2020-07-23 2:17 PM, kekronbekron wrote: > > > > > > > It would be best to consider switching to the z/OS Client Web > > > > Enablement Toolkit. > > > > > > > There are sample programs for REXX / ASM / COB .. and I'm positive > > > > there'll be a Python client pretty soon (IBM Open Enterprise Python for > > > > z/OS). > > > > > > To me the idea of writing a web client in assembler is preposterous. > > > COBOL is almost as bad and I would opt to use bpxwunix() with curl > > > over the Web Enabelment Toolkit any day. > > > I can create a Jira ticket with a couple of lines of curl. I would > > > suggest writing a REXX script using the WET would be considerably more > > > effort. > > > > > > > Don't think cURL is loved that much on Z. > > > > > > Are you speaking from experience? Not loved by who? Anybody who > > > knows > > > how to use z/OS UNIX shells knows how to use curl. I used curl only > > > yesterday to install a shell utility from github with a simple one-liner. > > > sh -c "$(curl -fsSL > > > https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" > > > > > > > Hmm .. unless client auth is required at the cURL target, you don't need > > > > to worry about client certs, right? > > > > > > > Just plop on the target server's CA cert (interim & root CA) public > > > > keys in a > > > > user keyring, and point CWET to the user keyring. > > > > > > > Server auth will work just fine. > > > > > > > > - KB > > > > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > > On Thursday, July 23, 2020 10:20 AM, Filip Palian [email protected] > > > > wrote: > > > > > > > > Hey, > > > > > You can read login credentials from within a script at run time > > > > > from a separate file containing password. This file should have an > > > > > adequate permissions and ownership set of course. > > > > > Alternatively, if you control the target, perhaps you can > > > > > whitelist your curl/client. > > > > > I hope that helps. > > > > > Cheers, > > > > > F > > > > > W dniu czwartek, 23 lipca 2020 Luke [email protected] napisał(a): > > > > > > > > > > > Hi All > > > > > > I'm wondering if anyone is using cURL on z/OS in a production > > > > > > setting? > > > > > > I'm interested how to utilise cURL when the target URL requires > > > > > > authentication. > > > > > > We can't use Basic Auth because we are not able to store > > > > > > usernames and password in scripts or batch jobs. > > > > > > We can't easily use certificates because our users on z/OS do > > > > > > not have certificates and our Windows based corporate > > > > > > certificate management doesn't allow users access to the private > > > > > > keys > > > > > > of their Windows certificates. > > > > > > > > > Anyone else using cURL for DevOps on z/OS and how are you securing > > > > > > it? > > > > > > > > > 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 > > > > > > > > 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 > > > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
