CEDA allows installation of a TCPIPService or URIMap with an invalid certificate

This requirement has been re-assessed. It is not now likely that this will be implemented in the near future and so it is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. You also have an opportunity to resubmit in twelve months time if you wish it to be reconsidered then.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

I agree with your decision that the perforn ssl rebuild function should remain under operator control.However, I have verified that UI16182 is installed and I was still able to recreate the original issue.

I had a new certificate added to the keyring, I did NOT issue the rebuild, and used CEDA to install the resource. Upon use of the resource, it failed.

DFHSO0133 10/27/2014 15:09:44 CICSSXA2 TCPIPSERVICE TESTARSH has been installed.
DFHSO0107 10/27/2014 15:09:44 CICSSXA2 TCPIPSERVICE TESTARSH has been opened on port 01312 at IP address ANY.
DFHSO0123 10/27/2014 15:09:56 CICSSXA2 Return code 6 received from function 'gsk_secure_socket_init' of System SSL. Reason: No
certificate available. Peer: 114.2.82.156, TCPIPSERVICE: TESTARSH.


In our shop, to mitigate potential impact for this, we have created a CICS Event that calls an in-house written program that will close/disable the offending resource and email our team asking for investigation and someone to issue a REBUILD if necessary.
DFHPG0209 10/27/2014 15:09:57 CICSSXA2 CITEVNT WWEV Resource definition for WWEVTPGM has been autoinstalled using model WWPGAINP.
DFHPG0209 10/27/2014 15:09:57 CICSSXA2 CITEVNT WWEV Resource definition for WWEMAIL has been autoinstalled using model WWPGAINP.
DFHPG0209 10/27/2014 15:09:57 CICSSXA2 CITEVNT WWEV Resource definition for WWSYSTEM has been autoinstalled using model WWPGAINP.
DFHSO0108 10/27/2014 15:09:57 CICSSXA2 TCPIPSERVICE TESTARSH on port 01312 at IP address ANY has been closed.


My original RFE still stands. Since the TCPIPService has a status of Open, CEDA should return an installation failure rather than "INSTALL SUCCESSFUL". Or, the validation could be done by CICS and the port fail to open (like when experiencing a SAF failure to not be authorized to bind to the port). EIther way, the port should not be opened to take customer workloads while the certificate is invalid.

Arshia,
CICS obtains its information about the certificates on the keyring on SSL initialisation.
This is separate from the checking on the install process.
We have looked at automating the perform ssl rebuild function to reinitialise the SSL environment when a mismatch is detected.
However this could cause problems if a site is updating a number of certificates over a short period of time.
It was felt that it would be better therefore for the refresh to be under operator control after the last update had been made.
The message DFHSO0123 will be updated to clarify this.
I believe that PTF UI16182 solves your basic problem, so is this OK to close the RFE as fixed?

Colin, the APAR you mentioned connects to PTF UI16182. That PTF only released at the end of April, AFTER I submitted my SR about this issue and subsequently opened this RFE. Based on the description here: http://www-01.ibm.com/support/docview.wss?uid=swg1PI06257 , UI16182 ** may ** satisfy my RFE.

With UI16182 applied, a URIMAP installation would call for an INQUIRE_CERTIFICATE to validate it is completely valid (including it's private key). In SR 09720,379,000, it was indicated that CEDA would validate a certificate label was valid, but would not validate if the certificate itself was indeed valid for use. So the dumps I submitted then, the certificate label was valid, but no SSL REBUILD was performed and thus, the private key was not yet available. As such, use of the certifcate failed with an error along the lines of "certificate not available." The testing I did was with a TCPIPService.

Here is a snippet from the SR:
---
If we attempt to install a TCPIPService where a certificate is not on the CICS keyring, we get the message "Install of TCPIPSERVICE XYZ failed because CERTIFICATE ABC is invalid." This behavior is consistent between CICS 4.2 and CICS 5.1. However, if the certificate is loaded to the CICS keyring AND the CEMT PERFORM SSL REBUILD command is NOT issued, CEDA will allow for installation of this certifcate under CICS 5.1. We simply get "INSTALL SUCCESSFUL". However, if a user then tries to connect to this port, CICS spits the following out to MSGUSR:
DFHSO0123 01/30/2014 10:51:24 APPLID Return code 6 received from function 'gsk_secure_socket_init' of System SSL. Reason: No
certificate available.
---

Since I do not yet have this applied, I cannot see if I get a similar Certificate is invalid message as you do upon trying to do an install. However, the Change Team at the time indicated that this is the desired behavior. Their snippet is included below.
---
CEDA has no idea when the named certificate was added to the KEYRING.
The assumption is that the certificate was always on the KEYRING.
---

This makes it sound like a "deep inspection" of the certificate is not done, and simply an inspection to check if the certificate is on the keyring is done. The error message you get sounds like the error message I got without this PTF applied that only occurred if the certificate was not yet on the keyring.

Could you please clarify Colin?

Arshia,

Apologies for taking so long to get back to you about this RFE.
I believe this problem is fixed in APAR PI06257 on 680.

I've tried this on my system and get the message
S install of URIMAP HTTPS-S failed because CERTIFICATE My-Certificate is invalid.

Does this fix the problem that you are seeing?

Colin Penfold