Issue with docs.zowe.org/stable/user-guide/configure-certificates

[colinpaicemq]

Description

Pages to Update

It says

Zowe supports using either file-based (PKCS12) or z/OS key ring-based (when on z/OS) keystores and truststores, and can reuse compatible stores if they exist. Zowe can assist in creating the stores by either generating certificates or by allowing users to import their own compatible certificates via the zwe init certificate command.

I believe that PKCS12 (or .pem) files are not considered very secure - but you need to check with the security people. Anyone with super user authority can access this .pem file, and so steal your private key.

If you use a keyring, you have to explicity grant someone access to the keyring to be able to use it - and give them control/update access to the ring to be able to use any private key on the ring.

---

Take our Certificates Configuration Questionnaire to assist with determining which configuration scenario and associated zowe.yaml format best suits your use case.

broken link

Screenshots

Expected behavior

Additional context

[balhar-jakub]

That is very much correct understanding, and while Zowe does support PKCS#12. I definitely wouldn't recommend it for anything else then PoC deployments.

Is there any change in documentation that is missing to make sure this is clear?

[colinpaicemq]

How about

Zowe supports using either file-based (PKCS12) or z/OS key ring-based (when on z/OS) keystores and truststores, and can reuse compatible stores. file-based .pem certificates are inherently not secure because they files can be accessed and the credentials stolen. You should use keyring based stores for your systems

[1000TurquoisePogs]

On the JCL init page we took a more aggressive stance against PKCS12 and zowe-created keyrings.

1. we dont even mention pkcs12 there
2. we hide zowe-created keyring option under a collapsed box to reduce its visibility since it tends to be a trap where users do it because they thing it's their only good option and then miss the one they actually want (bring-your-own-keyring)

I advocate for collapsing PKCS12 under such boxes to reduce their visibility, because we know by know that almost nobody wants them.

[colinpaicemq]

I'l go back to the documentation. I didn't see this page when going through the installation process, so I wonder how I missed it.

I do find it hard to find a single path through the documentation which gives me what I need to know - and not too much information.

[1000TurquoisePogs]

There is not a single path through the documentation, because it covers different options. I fought a battle last year in trying to make the options obvious as options by giving them similar names, however there are some not obvious choices of the sidebar layout

The numbers explain what I believe to be the path one must take. It's mostly top-down, except

a,b,c. they're choices. the naming convention is as such. but some choices are better than others both in popularity and in documentation quality

*: This isnt an option, it's an alternative way to perform sections 3 & 4.

**: This isn't even remotely similar to the others in section 3, it's for a different platform than z/OS.

***: This is a page that explains the next page, 4a. I'm not sure if this should even exist, or at least should be moved to an appendix or something like that.

4.1, 4.2, 4.3: much of this is covered in the automation of 4a,4b,4c, but are in their own sections right below as a detailing of what's really needed, and how to do things manually instead of automated.

Hope you can appreciate the complexity of how does one make this linear when there's differences of opinion on what people want to see and do. I keep thinking do these all belong in one unified website or should there be different websites/PDFs for different occasions