How does the Secure+ Handshake work with Connect:Direct for z/OS?

Answer

It is critical to always remember which end of the transfer is the PNODE (Submitter or Sender) and which end is the SNODE (receiver). The PNODE is the Client to the SNODE Server. Connect:Direct ALWAYS performs Server Authentication in a Secure+ Session.

When the PNODE submits a process script the connection request is made to the Remote Node. The Remote Node checks the Connect Direct NETMAP and validates the request and then determines if a Secure Session is being requested. Once it has determined that a Secure Session has been requested the SNODE “Remote Node” opens the KEYCERT (key ring or key database if a mainframe) on their end and extracts the Public Certificate part of the file and sends that to the PNODE. The PNODE then
takes the Public Certificate and matches it to the certificate stored in the TRUSTED file or key ring / key database that was sent to them by the remote node.

If they match the connection proceeds with other checks on a Connect Direct level like the Submitter ID, file names, etc.. If they do NOT match then you know the TRUSTED file emailed and stored on the PNODE (Submitter) does not match the Public part of the KEYCERT (or key ring/database) on the Remote Node. This means either the SNODE has provided a “non-matching” TRUSTED file to the PNODE or the PNODE did not load the received certificate into their key ring/database correctly. Problems can be either a bad certificate (e.g. wrong format), a TRUSTED that does not have a full chain (ROOT and all Intermediates) or the PNODE loaded mishandled the certificate chain when loading it (e.g. each certificate and intermediate must be loaded individually, not all at once). In this case either the SNODE needs to provide you a new Trusted that does match or the PNODE needs to reload the certificate(s) into their key ring/database.

Once the Server Authentication is completed, you can utilize a Secure+ option called Client Authentication. Client Authentication is determined by the SNODE using the Client Auth flag (pre-C:D 5.2) or the Enable Client Auth flag (C:D 5.2). To use Client Authentication only the SNODE needs to set the Enable Client Auth flag. When Client Authentication is enabled the SNODE also requires that the PNODE send their certificate from their KEYCERT (or key ring/database). If the SNODE has Client Authentication enabled, both the PNODE certificate(s) and the SNODE certificate(s) are authenticated before the session can transfer.

If Client Authentication is enabled and one side makes changes or has an issue and transfers begin to fail, Client Authentication will need to be disabled to determine which end of the transfer has a problem with their certificates.