Question:
We have set up the Webcenter listener port in our AT-TLS policy. We can still log into WebCenter unsecured, and attempts to use HTTPS fail - what are we missing?
Answer:
T The different flavors of AT-TLS implementation are as follows:
Not enabled
– No policy or policy explicitly disables AT-TLS for application traffic
– Application may optionally use System SSL directly
– Applications that use the Pascal API and Web Fast Response Cache Accelerator
(FRCA) fall into this category
Basic <<<<<<< supported by WebCenter
– Policy enables AT-TLS for application traffic
– Application is unchanged and unaware of AT-TLS
– Application protocol unaffected by use of AT-TLS (think HTTP vs. HTTPS)
Aware
– Policy enables AT-TLS for application traffic
– Application uses the SIOCTTLSCTL ioctl to extract AT-TLS information such as
partner certificate, negotiated version and cipher, policy status, etc.
Controlling
– Policy enables AT-TLS and specifies ApplicationControlled ON for application
traffic
– Application protocol may negotiate the use of TLS in cleartext with its partner
– Application uses the SIOCTTLSCTL ioctl to extract AT-TLS information (like an
aware application) and to control TLS operations:
•Start secure session
•Reset session
•Reset cipher
In order for AT-TLS to be completely transparent to the application and thus supported by WebCenter, the WebCenter port should be set up as the "Basic" type in the AT-TLS policy with policy parm "ApplicationControlled" set to OFF. Otherwise, AT-TLS expects WebCenter to handle the security calls, and this in turn causes the port to remain unsecured since WebCenter no longer supports System SSL security calls. With the ApplicationControlled policy parm set to OFF, the port is secured at the TCPIP layer with no further interaction or changes required in NetMaster or WebCenter.
Additional Information:
Please refer to the IBM documentation covering implementation of AT-TLS security or contact IBM support for additional information.