Key ring configuration feedback

[JirkaAichler]

I would like to share the feedback from a customer who is trying to install and configure Zowe into production. The issues are related to Zowe v1 but I think they also partially apply to v2. I will also add my perception based on the feedback.

1. Zowe log does not contain a version. Components should not log a lot of details but focus on information important for admins. It is difficult to spot errors inside now.

2. Certificate configuration is difficult to understand and the documentation is not helpful. We were trying to configure key rings that were already prepared.

The certificate configuration scripts are trying to automate and simplify the whole process. This is great for keystores and also for the test environments but does not work well for key rings in production. The majority of customers are following IBM's recommended roles and processes in security.

See: https://www.ibm.com/docs/en/zos-basic-skills?topic=zos-roles-in-security

Separation of duties does not allow any individual to run the automation script. The documentation should contain numbered configuration steps that the users will easily follow and try to divide the sections by roles (sys prog, security admin ..). I think system programmers will appreciate automation and security admin would prefer just the SAF commands or JCL (different for each security package and simple as possible since they need to review it closely).

It would be also nice to prepare different steps the generate all certificates and different for using the existing key ring.

[jackjia-ibm]

Thanks for the feedbacks.

For logging, I think in later v1 versions and v2, Zowe launch script will write the current Zowe level at the beginning of the log. Hope it helps. There are still a lot of works to clean up component logs. It could be a good topic for TSC to discuss what component should write to log, what shouldn't.

I don't think v2 had fully solved the certificate problem.

There are 2 changes in v2 may help in some way, mainly for the awareness of the roles involved during setup.

• zwe init certificate is a separated command can run out of zwe init command group. An admin can decide which steps are applicable for them.
• zwe init certificate, zwe init security and zwe init apfauth have an option of --security-dry-run. If this is enabled, there are no real RACF commands will be issued but it will render a JCL in zowe.setup.dataset.jcllib for review purpose. With this option, automation part will succeed but leave the JCLs to be submitted by security admin.

What kept from v1 is the ZWEKRING jcl. This JCL is a combination of 3 scenarios mentioned in zowe.yaml zowe.setup.certificate section:

• Senario 3: JCERACFKS (z/OS Keyring) with Zowe generated certificates.
• Senario 4: JCERACFKS (z/OS Keyring) and connect to existing certificate. <=== This could be the most common use case.
• Senario 5: JCERACFKS (z/OS Keyring) with importing certificate stored in data set.

But the JCL itself is a little complicated, hard to read, in order to support 3 security managers. And some use cases are not fully covered. There were discussions related to this #2482 as well as security setup related #2451. They are not mature enough right now so no actions yet.

[GilPen]

Hello

I totally agree with the comment below.

The documentation explains to generate a certificate with ZOWE processes.
But I generated the certificate outside ZOWE documentation because I had to use our company CA chain.

I would like to connect my own keyring using the zowe.yaml but it doesn't work ( I use TOP SECRET not RACF ).

/usr/lpp/zowe/bin/zwe init certificate -v -c testSAF.yaml --update-config
"Error ZWEL0175E: Failed to connect existing certificate to Zowe keyring xxxxx/yyyyy"

[ZOSSYSPROG]

Hello Guys,
we are experiencing a similar situation like GilPen, zowe is not able to load or connect the keyring with -> ZWEL0175E. We also use a keyring that is generated outside of ZOWE due to company compliance, but we use RACF.

We tried already all possible Szenarions, different Syntax, it just won't work.

Is there an Update on this so far?

Regards

[1000TurquoisePogs]

@ZOSSYSPROG its been possible to bring-your-own-keyring with zowe for probably 2 years but I don't think the documentation points this out well.
I was working on a quick-start guide that covers this however
https://github.com/zowe/zowe-install-packaging/blob/feature/v3/jcl/INSTALLATION.md#keystore-or-keyring-configuration

I hope that helps.

[GilPen]

Hello

I can give you the process I use. @achmelo gave me advices and It works for me.

I generate a pem file with the command :
openssl req -config csr_config_zowe_SYS.conf -newkey rsa:2048 -nodes -keyout zowe.key -sha256 -out zowe.csr

The conf file includes the CNAME, DNS ... and details about the certificates

The csr file generates from the previous command is given to our PKI. The PKI generates a pem file

I used the pem file in this command to generate a new p12 certificate file
openssl pkcs12 -export -in zowe.pem -inkey zowe.key -out zowe.p12

The p12 file is given to SAF Team to be install in a SAF keyring of the STC ZOWE owner.

I hope it helps.

Regards
Gilles

[ZOSSYSPROG]

@1000TurquoisePogs
Exactly that is what i was searching for! The 5 given scenarios does not cover our case, i wasnt sure if i have to include the custom scenario in the zowe.setup.certificate section because this let the security-dry-run fail. Now i did it according to the described scenario 6, and it worked out, some other problems occur but now zowe accept the keyring and the application startup works!

@GilPen
Thanks for your information, interessting to see that there a different ways to make it work. According to our compliance we dont use cert-files at all, but i will test that in dev stages. Thank you for sharing your process!