Here's our simple DB2 Secure port definition in AT-TLS:
TTLSRule DBRTSecureServer # Secure DBRT
{
LocalPortRange 4450 # DBRT Secure Port
Direction Inbound # Inbound Only
Priority 1 # Lowest
priority rule
TTLSGroupActionRef grp_Production # Uncomment once
debugging
TTLSEnvironmentActionRef DBRT_SecureServer_Action # DBRT Env Action
}
TTLSEnvironmentAction DBRT_SecureServer_Action
{
HandshakeRole Server
TTLSKeyRingParmsRef DBRT_Keyring_Parms
TTLSCipherParmsRef DB2_CipherParms
TTLSEnvironmentAdvancedParms
{
ClientAuthType PassThru
SSLv2 Off
SSLv3 Off
TLSv1 Off
TLSv1.1 Off
TLSv1.2 On
}
}
TTLSKeyRingParms DBRT_Keyring_Parms
{
Keyring DBRT/DBRT.KEYRING
}
On 5/1/2023 2:12 PM, Kurt J. Quackenbush wrote:
My understand is that ATTLS allows you to encrypt network traffic for
clients/servers which do not implement TLS themselves. It sounds like your Db2
traffic was formerly not encrypted with TLS, but your ATTLS rule now encrypts
that Db2 traffic without the client or server being any wiser. Unfortunately
that rule is also negatively affecting SMP/E and probably any other
applications that use HTTPS. SMP/E implements TLS itself, so it doesn't need
ATTLS to do so on its behalf.
I am absolutely NOT an expert in defining ATTLS rules, but my guess is you need
to define the rule more specifically to impact only the Db2 traffic and not all
HTTPS traffic. Hopefully some kind soul with may more experience in ATTLS can
offer suggestions, sorry.
Kurt Quackenbush
IBM | z/OS SMP/E and z/OSMF Software Management | ku...@us.ibm.com
Chuck Norris never uses CHECK when he applies PTFs.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
