Improvements to Policy Agent

.This Idea contains two distinct requirements:
1. Provide a command to display the active AT-TLS certificate chain. Not the entire keyring but just the chain that was selected as of the last refresh command
2. Validate the entire keyring (don't stop after the first matching certificate). If multiple matching certificates are found, load them all, so that the 2nd match can become active right away (without a refresh command) if the first match expires.

The first of these actually applies to AT-TLS ? not policy agent. While the spirit of the requirement is valid, it would be difficult to build such a command because AT-TLS does not have direct visibility to the certificates or keyring -- System SSL does all that. However, it would be feasible to think about adding new AT-TLS log messages that contain key attributes of the local end-entity (server or client) certificate like subject and issue distinguished names, serial number and maybe even expiration date. Would that satisfy your needs? If so, please open a new Idea against z/OS Communications Server that indicates you need a way for AT-TLS to report which local certificate was used on a successful handshake. This will help other customers understand what?s been requested and, if they find the idea useful, to vote for it (unfortunately, the title of ZRACF-I-17 is very misleading and will likely not draw votes from other customers). You can use this link to open the new Communications Server requirement: https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas

The second requirement applies to System SSL ? not policy agent or AT-TLS. During a recent discussion with the System SSL team, we learned this requirement is also included in Idea https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3477 that was opened by the Vanguard Group against System SSL, which is currently being evaluated by that team. Given that, please refer to Idea ZOS-I-3477 for the disposition of this requirement.


Based on the above, we are declining this Idea, but we will look for a new Communications Server Idea, which we will be happy to accept as an uncommitted candidate.

Sorry for any confusion. The idea was reopened and also rerouted to z/OS, component communications server, where it is being considered. There is no other idea nor need to open a new idea. Please continue communication and voting under this idea.

Hi, which are the new Ideas that were created based on this? I'm interested to vote for those.

Hi.. Since CommServer is in a different division, it doesn't look like I can transfer it. So I think you'll have to open a new one against the correct component. I'll go ahead and cancel this one.

Yes, you're correct. This deals with AT-TLS and I should have opened it against CommServer. Are you able to forward this to that group or is a new ticket required? Here's the client's request (from Doyle Skipper at Vanguard)

I would like to follow up with a modification request to AT-TLS that would greatly improve reliability. I’m in agreement with the suggestion by IBM Com Support for better certification hygiene and we are implementing processes to address this. However, it requires continual manual attention to manage the certificates and keychains. I haven’t requested an IBM enhancement for some time now, but I have some suggestions to consider.

1. Provide a command to display the active AT-TLS certificate chain. Not the entire keyring but just the chain that was selected as of the last refresh command.

2. Validate the entire keyring (don't stop after the first matching certificate). If multiple matching certificates are found, load them all, so that the 2nd match can become active right away (without a refresh command) if the first match expires.

Please let me know the process for IBM developers to consider the two recommendations above.

Hi... did you mean to open this idea againd zSecure for z/VM or did you mean CommServer?