This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Trying to secure client pack and ChangeMan ZMF

Securing Client Pack and ChangeMan ZMF with TLS.  Has any one gotten this to work.

We have 2 separate rules. One to cover port  ZMF port and one to cover port  Client Port. Other than the port, the rules are identical:
They use the same cert/keyring.
They are for inbound traffic (so it's a "server" rule).
TLSv1.2 only.
No client authentication (except by user id/pass from client pack and TSO logon).
When Application Controlled is OFF client pack works but TSO doesn't. When it's ON client pack doesn't work but TSO does.The error we are getting when TSO access doesn't work is 5003 Data Decryption.We tried adding a third rule to cover the TSO connection. This was a client rule/outbound traffic. Application Controlled on and off had the same effect: 5003 Data Decryption. We did NOT have a client cert/keyring specified for this rule.

Labels:

Changeman ZMF
  • 0  

    This issue is also being investigated under a Support case. The current understanding is that ApplicationControlled Off should be specified for all AT-TLS rules related to the CMN= and XCH= port numbers. However, if any customers do have any experiences related to use of ApplicationControlled On that they would like to share then their input is welcome in this discussion. Thank you.

  • 0   in reply to   

    ZMF will not function properly in an AT/TLS environment when application controlled is enabled (APPLICATIONCONTROLLED=ON).   This setting delegates session setup and configuration from AT/TLS into the ZMF application code.

    The setup fails for client pack with this setting because ZMF does not include this functionality.  Client Pack starts the session setup which AT/TLS delegates to ZMF;  ZMF does not perform any SSL setup so the connection fails.  TSO/ISPF clients will work in this environment because neither side performs any SSL setup (The end result may appear to work, but this connection will not be encrypted).

    AT/TLS rules (TTLSRULE) must be in added to include/exclude the ZMF ISPF Client from AT/TLS setup.  This is accomplished by adding a TTLSRULE statement with a Local Address (LocalAddr/LocalAddrRef etc) that uniquely identifies the local ZMF ISPF client.  Include processing would add statements to have AT/TLS manage the client side of the ISPF -> ZMF connection.  Exclude processing would add statements that include TTLSEnabled=OFF

    Note that ISPF <–> ZMF connections are likely on the same machine - TCP/IP communication in this environment will be cross-memory.  This is the reasoning behind excluding these connections from AT/TLS processing.   The 3270 Telnet connection in this environment must be enabled for SSL independently (3270 Client <-> Telnet)

    AT/TLS setup can be quite tricky.  It may be beneficial to enable tracing during initial setup to assist in getting the proper TTLSRule statements in place.

    AT/TLS configuration statements:  https://www.ibm.com/docs/en/zos/2.5.0?topic=applications-tls-policy-statements
    AT/TLS aware application:  https://www.ibm.com/docs/en/zos/2.5.0?topic=considerations-tls-aware-application
    AT/TLS controlling application: https://www.ibm.com/docs/en/zos/2.5.0?topic=considerations-tls-controlling-application

  • Suggested Answer

    0  

    After working with IBM this customer has successfully defined AT-TLS rules allowing secure communication between the ZMF Server task and both the TSO and Client Pack user interfaces.

  • Verified Answer

    +1

    We put a certificate in the installation directory C:\IBM\SDP\jdk\jre\lib\security for IDz.  We needed 3 pageant rules on the mainframe.

  • 0   in reply to 

    Many thanks for the confirmation.