CWPKI0022E: SSL HANDSHAKE FAILURE caused by a Broken Pointer in Top Secret

Products

• Top Secret

Issue/Introduction

A digital certificate in production received the following message:

CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN "CN=XXXXXX, O=COMPANYABCD" was sent from target host:port "##.###.###.##:####". The signer may need to be added to local trust store "safkeyring:///XXXKeyring" located in SSL configuration alias "NodeDefaultSSLSettings" loaded from SSL configuration file "security.xml". The extended error message from the SSL handshake exception is: "Truststore contains no entries".

Environment

Release : 16.0

Resolution

The keyring contained a complete signing chain including a personal certificate and private key.  All three certificates in the chain were valid. There was one other certificate on the keyring which was no longer used.

Normally having extra certificates on a keyring does not cause a problem. But this certificate was actually removed from the owning acid; yet it showed as being on the keyring. It did not show when listing the owning acid. This is a broken pointer.

The invalid certificate was the first certificate on the keyring.  This means it is the first certificate read on the keyring; but, in this case there is no certificate and OMVS issued the following (seen in the TSSOERPT):

  R_datalib        USERABCD  GROUPABCD            0           0   8      8     44
   02/24/23  23.055    4.03.38 USERABCD                SYSX
   Failed - Record not found
    Function: DataGetFirst      Userid:
    Ring name: USERRING

The keyring was found but not the first certificate.  An 8  8  44 return code means end of file and OMVS stops reading the keyring. The rest of the valid certificate chain never gets read.

When broken pointers are found, the rule is to make what ever is untrue to be true. In this case, the first certificate on the keyring is untrue. If the certificate resides in a dataset outside of Top Secret, then it can be added back to the owning acid. If it contains a private key, the dataset will be password protected and you must use the password on the ADD Command.   

In this case the certificate along with the private key was on another system and was able to be EXPORTed to a dataset:

   TSS EXPORT(acid) DIGICERT(certificate) FORMAT(PKCS12DER) DCDSN(data,set.) PKCSPASS(password)

Then it was added back to the owning acid:

   TSS ADD(acid) DIGICERT(certificate) DCDSN(data.set) PKCSPASS(password) TRUST

When the acid was listed the certificate was there but it was no longer on the keyring.  Since the certificate was not needed on the keyring it was not added back.