Re: I hate to be a pain (Cross-Posted)
Radoslaw, The "cracking exercise" is not so difficult. Those private keys in RACF are not encrypted. They are stored in field CERTPRVK. I think they are BER encoded. Details are in the RACF Macros and Interfaces manual. It's easy to display them using zSecure if you know how. Good reason to make sure the absolute minimum of people have READ access to the RACF database. With ICSF the keys are stored in the ICSF CKDS with each key encrypted under the ICSF master key. That master key is protected using FIP-140-2 level 4 standards. Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: 18 January 2024 22:32 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: I hate to be a pain (Cross-Posted) Is ICSF xKDS file a VSAM? Yes. So, why to keep the keys in CKDS/PKDS instead of RACFdb? 1. Because the keys in CKDS/PKDS are *well encrypted* using secret key (CryptoExpress MK). Assumed you have CEX. 2. Because any key kept in RACF is kept along with the encryption key for that key. 3. Because still a majority of RACF installations do not use encrypted VSAM db (yet). In such scenario any authorized person (i.e. bad RACF admin) can read whole db and then do the cracking excercises. BTW: Recently I did encrypt RACF db. Results: none. Nothing happened. The database is encrypted - the only change, but it is invisible to administrators. -- Radoslaw Skorupka Lodz, Poland W dniu 17.01.2024 o 21:29, Steve Beaver pisze: > On z/OS isn't that the ICSF CKDS VSAM file? Yes > > Steve > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Farley, Peter > Sent: Wednesday, January 17, 2024 1:38 PM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: I hate to be a pain (Cross-Posted) > > On z/OS isn't that the ICSF CKDS VSAM file? > > Peter > > From: IBM Mainframe Discussion List On Behalf Of > Steve Beaver > Sent: Wednesday, January 17, 2024 1:32 PM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: I hate to be a pain (Cross-Posted) > > > This is not may area of expertise, and I can't find a YOUTUBE or a step by > > step checklist > > > > How does one create a keystore on zOS? > > > > Regards, > > > > Steve > > -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
Is ICSF xKDS file a VSAM? Yes. So, why to keep the keys in CKDS/PKDS instead of RACFdb? 1. Because the keys in CKDS/PKDS are *well encrypted* using secret key (CryptoExpress MK). Assumed you have CEX. 2. Because any key kept in RACF is kept along with the encryption key for that key. 3. Because still a majority of RACF installations do not use encrypted VSAM db (yet). In such scenario any authorized person (i.e. bad RACF admin) can read whole db and then do the cracking excercises. BTW: Recently I did encrypt RACF db. Results: none. Nothing happened. The database is encrypted - the only change, but it is invisible to administrators. -- Radoslaw Skorupka Lodz, Poland W dniu 17.01.2024 o 21:29, Steve Beaver pisze: On z/OS isn't that the ICSF CKDS VSAM file? Yes Steve -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter Sent: Wednesday, January 17, 2024 1:38 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: Re: I hate to be a pain (Cross-Posted) On z/OS isn't that the ICSF CKDS VSAM file? Peter From: IBM Mainframe Discussion List On Behalf Of Steve Beaver Sent: Wednesday, January 17, 2024 1:32 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: I hate to be a pain (Cross-Posted) This is not may area of expertise, and I can't find a YOUTUBE or a step by step checklist How does one create a keystore on zOS? Regards, Steve -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
I gotta plead guilty to this. I know the basickest of basics about Unix security, mostly from reading "The Cuckoo's Egg" multiple times; I've also hit the manuals occasionally, but I'm woefully ignorant and I know it. I guess it helps that I know it, but it'll be better still to learn more. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* I still believe that standing up for the truth of God is the greatest thing in the world. This is the end (purpose) of life. The end of life is not to be happy. The end of life is not to achieve pleasure and avoid pain. The end of life is to do the will of God, come what may. -Martin Luther King, Jr. */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Troth Sent: Thursday, January 18, 2024 11:14 What Itschak said about USS/Unix being unfamiliar to mainframe security teams is reality. Unix and USS matter when you're in a multi-platform environment (where I live). -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: Thursday, January 18, 2024 08:59 unix file system is less understood and maintained by the mainframe security teams, so the risk is built in uss security (if you do not use external security for this). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
> Files in Unix are pretty unsecure. ... That's the popular wisdom. I could argue that the evidence is circumstantial, even coincidental. (Bad rap because of bad practice by OTHER PEOPLE.) But I'll back down. What Itschak said about USS/Unix being unfamiliar to mainframe security teams is reality. Unix and USS matter when you're in a multi-platform environment (where I live). If you stay in MVS then you're better off with SAF and ICSF. -- R; <>< On 1/18/24 10:32, Colin Paice wrote: My H'penth Files in Unix are pretty unsecure. I feel that any keystore in Unix is an exposure. With ICSF you can define a public/private key pair, and protect them with a SAF profile such as RDEFINE CSFKEYS label... You then give people access to the label, and hence to the key(s). I think it is harder to get access to these RACF resources than access to Unix files, so the recommendation is use ICSF and SAF. I tend to use certificates etc in RACF and not ICSF (for ease of use) but I think ICSF is more secure. Colin On Thu, 18 Jan 2024 at 13:53, Rick Troth wrote: On 1/18/24 02:53, ITschak Mugzach wrote: see below the relevant STIG (V8r11)- TSS0-ES-000100: IBM z/OS for PKI-based authentication must use ICSF or the ESM to store keys. Why? (And I realize that YOU are not making this up, so don't take any challenge personally.) Any keys or Certificates must be managed in ICSF or the external security manager and not in UNIX files. Here too, why? I found the following, but with no rationale or justification for the above mandates. https://www.stigviewer.com/stig/ibm_zos_tss/2021-03-30/finding/V-223883 "If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys." I was going to breaking that down in this note for sake of understanding, but that would be tedious. Instead I'll cut to the chase: _none of the above identifies a problem with keys residing in USS_. The statement correctly indicates the need to protect the private key, but stops short of evaluating means of protection. What is the risk? discovery of the private key. Can that happen with USS? yes (that's an area I am very familiar with) Can that happen with ICSF? you tell me (but I'll wager yes) Can that happen with an ESM? you tell me (same) Because of my familiarity with USS and things like it, combined with the common techniques used there and in other systems, it appeals to me. That's both subjective (personal) and objective (common techniques and methods, win/win). Observation: EVERY DAY I find doors closing on existing security methods in favor of obscure alternatives. The reasoning seems to be that attackers know the familiar routes and therefore the familiar routes must be avoided. That reasoning does not scale, and Wirth's law comes into play: "software is getting slower more rapidly than hardware becomes faster". Someone should expound on why ICSF or ESM is actually better or I'm calling BS on this. -- R; <>< ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III wrote: Itschak Mugzach wrote: The STIG does not allow a uss keystore. Ummmkay? I see no mention of a STIG here. But as I said, I'm even SWAGging what he really wants/needs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
My H'penth Files in Unix are pretty unsecure. I feel that any keystore in Unix is an exposure. With ICSF you can define a public/private key pair, and protect them with a SAF profile such as RDEFINE CSFKEYS label... You then give people access to the label, and hence to the key(s). I think it is harder to get access to these RACF resources than access to Unix files, so the recommendation is use ICSF and SAF. I tend to use certificates etc in RACF and not ICSF (for ease of use) but I think ICSF is more secure. Colin On Thu, 18 Jan 2024 at 13:53, Rick Troth wrote: > On 1/18/24 02:53, ITschak Mugzach wrote: > > see below the relevant STIG (V8r11)- TSS0-ES-000100: > > > > IBM z/OS for PKI-based authentication must use ICSF or the ESM to store > > keys. > > > Why? > (And I realize that YOU are not making this up, so don't take any > challenge personally.) > > > > Any keys or Certificates must be managed in ICSF or the external security > > manager and not in UNIX files. > > > Here too, why? > > I found the following, but with no rationale or justification for the > above mandates. > > https://www.stigviewer.com/stig/ibm_zos_tss/2021-03-30/finding/V-223883 > > "If the private key is discovered, an attacker can use the key to > authenticate as an authorized user and gain access to the network > infrastructure. The cornerstone of the PKI is the private key used to > encrypt or digitally sign information. If the private key is stolen, > this will lead to the compromise of the authentication and > non-repudiation gained through PKI because the attacker can use the > private key to digitally sign documents and pretend to be the authorized > user. Both the holders of a digital certificate and the issuing > authority must protect the computers, storage devices, or whatever they > use to keep the private keys." > > I was going to breaking that down in this note for sake of > understanding, but that would be tedious. > Instead I'll cut to the chase: _none of the above identifies a problem > with keys residing in USS_. The statement correctly indicates the need > to protect the private key, but stops short of evaluating means of > protection. > > What is the risk? discovery of the private key. > > Can that happen with USS? yes (that's an area I am very familiar with) > > Can that happen with ICSF? you tell me (but I'll wager yes) > > Can that happen with an ESM? you tell me (same) > > Because of my familiarity with USS and things like it, combined with the > common techniques used there and in other systems, it appeals to me. > That's both subjective (personal) and objective (common techniques and > methods, win/win). > > Observation: > EVERY DAY I find doors closing on existing security methods in favor of > obscure alternatives. > The reasoning seems to be that attackers know the familiar routes and > therefore the familiar routes must be avoided. > That reasoning does not scale, and Wirth's law comes into play: > "software is getting slower more rapidly than hardware becomes faster". > > Someone should expound on why ICSF or ESM is actually better or I'm > calling BS on this. > > -- R; <>< > > > > ITschak Mugzach > > *|** IronSphere Platform* *|* *Information Security Continuous Monitoring > > for z/OS, x/Linux & IBM I **| z/VM coming soon * > > > > > > > > > > On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III wrote: > > > >> Itschak Mugzach wrote: > >>> The STIG does not allow a uss keystore. > >> Ummmkay? I see no mention of a STIG here. But as I said, I'm even > SWAGging > >> what he really wants/needs. > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
Rick, You blond the messenger. STIGs are developed by DISA. We only automate the process. This is why I am very familiar with the STIG rules. Btw, unix file system is less understood and maintained by the mainframe security teams, so the risk is built in uss security (if you do not use external security for this). ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* בתאריך יום ה׳, 18 בינו׳ 2024 ב-15:53 מאת Rick Troth : > On 1/18/24 02:53, ITschak Mugzach wrote: > > see below the relevant STIG (V8r11)- TSS0-ES-000100: > > > > IBM z/OS for PKI-based authentication must use ICSF or the ESM to store > > keys. > > > Why? > (And I realize that YOU are not making this up, so don't take any > challenge personally.) > > > > Any keys or Certificates must be managed in ICSF or the external security > > manager and not in UNIX files. > > > Here too, why? > > I found the following, but with no rationale or justification for the > above mandates. > > https://www.stigviewer.com/stig/ibm_zos_tss/2021-03-30/finding/V-223883 > > "If the private key is discovered, an attacker can use the key to > authenticate as an authorized user and gain access to the network > infrastructure. The cornerstone of the PKI is the private key used to > encrypt or digitally sign information. If the private key is stolen, > this will lead to the compromise of the authentication and > non-repudiation gained through PKI because the attacker can use the > private key to digitally sign documents and pretend to be the authorized > user. Both the holders of a digital certificate and the issuing > authority must protect the computers, storage devices, or whatever they > use to keep the private keys." > > I was going to breaking that down in this note for sake of > understanding, but that would be tedious. > Instead I'll cut to the chase: _none of the above identifies a problem > with keys residing in USS_. The statement correctly indicates the need > to protect the private key, but stops short of evaluating means of > protection. > > What is the risk? discovery of the private key. > > Can that happen with USS? yes (that's an area I am very familiar with) > > Can that happen with ICSF? you tell me (but I'll wager yes) > > Can that happen with an ESM? you tell me (same) > > Because of my familiarity with USS and things like it, combined with the > common techniques used there and in other systems, it appeals to me. > That's both subjective (personal) and objective (common techniques and > methods, win/win). > > Observation: > EVERY DAY I find doors closing on existing security methods in favor of > obscure alternatives. > The reasoning seems to be that attackers know the familiar routes and > therefore the familiar routes must be avoided. > That reasoning does not scale, and Wirth's law comes into play: > "software is getting slower more rapidly than hardware becomes faster". > > Someone should expound on why ICSF or ESM is actually better or I'm > calling BS on this. > > -- R; <>< > > > > ITschak Mugzach > > *|** IronSphere Platform* *|* *Information Security Continuous Monitoring > > for z/OS, x/Linux & IBM I **| z/VM coming soon * > > > > > > > > > > On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III wrote: > > > >> Itschak Mugzach wrote: > >>> The STIG does not allow a uss keystore. > >> Ummmkay? I see no mention of a STIG here. But as I said, I'm even > SWAGging > >> what he really wants/needs. > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
On 1/18/24 02:53, ITschak Mugzach wrote: see below the relevant STIG (V8r11)- TSS0-ES-000100: IBM z/OS for PKI-based authentication must use ICSF or the ESM to store keys. Why? (And I realize that YOU are not making this up, so don't take any challenge personally.) Any keys or Certificates must be managed in ICSF or the external security manager and not in UNIX files. Here too, why? I found the following, but with no rationale or justification for the above mandates. https://www.stigviewer.com/stig/ibm_zos_tss/2021-03-30/finding/V-223883 "If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys." I was going to breaking that down in this note for sake of understanding, but that would be tedious. Instead I'll cut to the chase: _none of the above identifies a problem with keys residing in USS_. The statement correctly indicates the need to protect the private key, but stops short of evaluating means of protection. What is the risk? discovery of the private key. Can that happen with USS? yes (that's an area I am very familiar with) Can that happen with ICSF? you tell me (but I'll wager yes) Can that happen with an ESM? you tell me (same) Because of my familiarity with USS and things like it, combined with the common techniques used there and in other systems, it appeals to me. That's both subjective (personal) and objective (common techniques and methods, win/win). Observation: EVERY DAY I find doors closing on existing security methods in favor of obscure alternatives. The reasoning seems to be that attackers know the familiar routes and therefore the familiar routes must be avoided. That reasoning does not scale, and Wirth's law comes into play: "software is getting slower more rapidly than hardware becomes faster". Someone should expound on why ICSF or ESM is actually better or I'm calling BS on this. -- R; <>< ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III wrote: Itschak Mugzach wrote: The STIG does not allow a uss keystore. Ummmkay? I see no mention of a STIG here. But as I said, I'm even SWAGging what he really wants/needs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
see below the relevant STIG (V8r11)- TSS0-ES-000100: IBM z/OS for PKI-based authentication must use ICSF or the ESM to store keys. Any keys or Certificates must be managed in ICSF or the external security manager and not in UNIX files. ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III wrote: > Itschak Mugzach wrote: > >The STIG does not allow a uss keystore. > > Ummmkay? I see no mention of a STIG here. But as I said, I'm even SWAGging > what he really wants/needs. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
The STIGs don't cover a lot of things until someone like Fire-eye or IRS auditors Come in and complain. STIGs don't cover digital certifies but we use the hell out of them Regards, Steve -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Wednesday, January 17, 2024 3:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: I hate to be a pain (Cross-Posted) Itschak Mugzach wrote: >The STIG does not allow a uss keystore. Ummmkay? I see no mention of a STIG here. But as I said, I'm even SWAGging what he really wants/needs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
Itschak Mugzach wrote: >The STIG does not allow a uss keystore. Ummmkay? I see no mention of a STIG here. But as I said, I'm even SWAGging what he really wants/needs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
Phil The STIG does not allow a uss keystore. ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* בתאריך יום ד׳, 17 בינו׳ 2024 ב-22:47 מאת Phil Smith III : > If you mean certificates for TLS, the USS gskkyman utility is great for > testing/verification. Nothing wrong with it for production, but most sites > in my experience are happier with the certs in SAF (RACF/ACF2/TSS) for > production. The beauty of gskkyman is that it's isolated AND discrete. With > SAF you can screw other folks up and/or think you have it working correctly > when you don't. With gskkyman you can create a database containing just the > certificate(s) you think you need and verify that they work, then move them > to SAF. > > > > gskkyman operates via a series of prompts, so it's pretty easy to use: > > * Get the certificate in a USS file, preferably as a Base64-encoded > file (doesn't have to be, just easier to say "Yep, that looks like a > certificate") > * Go into gskkyman and import it > * Point the application truststore at the gskkyman database and test > > > > Obviously I'm making a bunch of assumptions about what you're doing in the > above, so none of it may apply. > > > > ...phsiii > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
If you mean certificates for TLS, the USS gskkyman utility is great for testing/verification. Nothing wrong with it for production, but most sites in my experience are happier with the certs in SAF (RACF/ACF2/TSS) for production. The beauty of gskkyman is that it's isolated AND discrete. With SAF you can screw other folks up and/or think you have it working correctly when you don't. With gskkyman you can create a database containing just the certificate(s) you think you need and verify that they work, then move them to SAF. gskkyman operates via a series of prompts, so it's pretty easy to use: * Get the certificate in a USS file, preferably as a Base64-encoded file (doesn't have to be, just easier to say "Yep, that looks like a certificate") * Go into gskkyman and import it * Point the application truststore at the gskkyman database and test Obviously I'm making a bunch of assumptions about what you're doing in the above, so none of it may apply. ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
On z/OS isn't that the ICSF CKDS VSAM file? Yes Steve -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter Sent: Wednesday, January 17, 2024 1:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: I hate to be a pain (Cross-Posted) On z/OS isn't that the ICSF CKDS VSAM file? Peter From: IBM Mainframe Discussion List On Behalf Of Steve Beaver Sent: Wednesday, January 17, 2024 1:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: I hate to be a pain (Cross-Posted) This is not may area of expertise, and I can't find a YOUTUBE or a step by step checklist How does one create a keystore on zOS? Regards, Steve -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
On z/OS isn't that the ICSF CKDS VSAM file? Peter From: IBM Mainframe Discussion List On Behalf Of Steve Beaver Sent: Wednesday, January 17, 2024 1:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: I hate to be a pain (Cross-Posted) This is not may area of expertise, and I can't find a YOUTUBE or a step by step checklist How does one create a keystore on zOS? Regards, Steve -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
Your keystore should be RACF or TSS. Depending on keylength, ICSF will likely store parts of the key in CKDS or PKDS datasets. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Steve Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu> Date: Wednesday, January 17, 2024 at 1:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: I hate to be a pain (Cross-Posted) This is not may area of expertise, and I can't find a YOUTUBE or a step by step checklist How does one create a keystore on zOS? Regards, Steve -- For IBM-MAIN subscribe / This is not may area of expertise, and I can't find a YOUTUBE or a step by step checklist How does one create a keystore on zOS? Regards, Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
I use keyrings - but not every product supports these. I think you can Java programs in USS. You need to know what your application/server supports Colin On Wed, 17 Jan 2024 at 18:32, Steve Beaver < 050e0c375a14-dmarc-requ...@listserv.ua.edu> wrote: > This is not may area of expertise, and I can't find a YOUTUBE or a step by > step checklist > > > > How does one create a keystore on zOS? > > > > > > Regards, > > > > > > Steve > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I hate to be a pain (Cross-Posted)
This is not may area of expertise, and I can't find a YOUTUBE or a step by step checklist How does one create a keystore on zOS? Regards, Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
