IBM Support

Configuring Your IBM i System Secure Sockets Layer (SSL)/Transport Layer Security (TLS) Protocols and Cipher Suites

Question & Answer


Question

How do you configure the System SSL/TLS protocols and cipher suites on the IBM i OS?

Answer


 
The IBM i System Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocols and ciphers suites are managed through the interconnect of the QSSLPCL, QSSLCSLCTL, and QSSLCSL system values, Digital Certificate Manager application definitions, and the SSLCONFIG/TLSCONFIG IBM i System Service Tools (SST) Advanced Analysis (AA) Command. When configuring your IBM i System SSL/TLS protocols and cipher suites, it is not always required to change your existing configuration. In some cases, only your SSL/TLS protocol configuration needs to be changed. In reverse, some cases will only require you to change your SSL/TLS cipher suite configuration. IBM recommends you carefully consider your SSL/TLS protocol and cipher suite requirements before making any changes.

IBM strongly recommends that you always run your IBM i server with the network protocols and cipher suites specified below disabled. NOTE: Configuring your IBM i server to allow the use of weak protocols and weak cipher suites will result in your IBM i server potentially being at risk of a network security breach. IBM DISCLAIMS AND YOU ASSUME ALL RESPONSIBILITY AND LIABILITY FOR ANY DAMAGE OR LOSS, INCLUDING LOSS OF DATA, ARISING OUT OF OR RELATED TO YOUR USE OF THE SPECIFIED NETWORK PROTOCOL AND/OR CIPHER SUITES.

Weak protocols (as of December 2023):
Transport Layer Security version 1.1 (TLSv1.1)
Transport Layer Security version 1.0 (TLSv1.0)
Secure Sockets Layer version 2.0 (SSLv2)
Secure Sockets Layer version 3.0 (SSLv3)

Weak cipher suites (as of December 2023):
*RSA_RC4_128_SHA
*RSA_RC4_128_MD5
*RSA_NULL_MD5
*RSA_NULL_SHA
*RSA_NULL_SHA256
*RSA_DES_CBC_SHA
*RSA_EXPORT_RC4_40_MD5
*RSA_EXPORT_RC2_CBC_40_MD5
*RSA_RC2_CBC_128_MD5
*RSA_DES_CBC_MD5
*RSA_3DES_EDE_CBC_MD5
*RSA_3DES_EDE_CBC_SHA
*ECDHE_ECDSA_NULL_SHA
*ECDHE_ECDSA_RC4_128_SHA
*ECDHE_RSA_NULL_SHA
*ECDHE_RSA_RC4_128_SHA
*ECDHE_RSA_3DES_EDE_CBC_SHA
*ECDHE_ECDSA_3DES_EDE_CBC_SHA
*ECDHE_ECDSA_AES_128_CBC_SHA256
*ECDHE_ECDSA_AES_256_CBC_SHA384
*ECDHE_RSA_AES_128_CBC_SHA256
*ECDHE_RSA_AES_256_CBC_SHA384
*RSA_AES_128_CBC_SHA
*RSA_AES_128_CBC_SHA256
*RSA_AES_256_CBC_SHA
*RSA_AES_256_CBC_SHA256

-----------------------------------------------------------------------------

Enabled protocols

The QSSLPCL system value setting identifies the specific protocols that are enabled on the system. Applications can negotiate secure sessions with only the protocols that are listed in QSSLPCL. For example, to restrict the System SSL/TLS implementation to use only TLSv1.3 and TLSv1.2 and not allow any of the older protocol versions, set QSSLPCL to contain only *TLSV1.3 & *TLSV1.2.

The QSSLPCL special value *OPSYS allows the operating system to change the protocols that are enabled on the system on a release boundary. The value of QSSLPCL remains the same when the system upgrades to a newer operating system release. If the value of QSSLPCL is not *OPSYS, then the administrator must manually add in newer protocol versions to QSSLPCL after the system moves to a new release.


Table 1.
IBM i Release QSSLPCL *OPSYS definition
7.5 *TLSV1.3 *TLSV1.2
7.4 *TLSV1.3 *TLSV1.2
7.3 *TLSV1.3 *TLSV1.2 *TLSV1.1 *TLSV1
7.2 *TLSV1.2 *TLSV1.1 *TLSV1
7.1 *TLSV1 *SSLV3
6.1 *TLSV1 *SSLV3

Default protocols

When an application does not specify the protocols to enable, the System SSL/TLS default protocols are used. Applications use this design to pick up new TLS support without requiring application code changes. The default protocol setting has no meaning for applications that explicitly specify the protocols to enable for the application.

The default protocols on a system are the intersection of the enabled protocols from QSSLPCL and the eligible default protocols. The eligible default protocol list is configured by using SSLCONFIG/TLSCONFIG option eligibleDefaultProtocols.

To determine the current value of the eligible default protocol list and the default protocol list on the system, use SSLCONFIG/TLSCONFIG option –display.

An administrator should consider changing the default protocol settings only when no other configuration setting allows an application to interoperate with peers successfully. It is preferred to enable an older protocol for only the specific application that requires it. When the application has an “application definition,” then this enablement is accomplished through the Digital Certificate Manager (DCM).

WARNING:

Adding an older protocol version to the default list results in opening up all applications that use the default list to known security vulnerabilities. Loading a Group Security PTF might result in the removal of a protocol from the default protocol list. Subscribe to the Security Bulletin to receive notification when a security mitigation includes this type of change. If an administrator adds back an eligible protocol that was removed by a Security PTF, the system remembers this change and does not remove it a second time when the next Security PTF is applied.

If the default protocols must be changed on the system, use SSLCONFIG/TLSCONFIG option eligibleDefaultProtocols to change the value. SSLCONFIG/TLSCONFIG option -h displays the help panel that describes how to set the protocol list. Only protocol versions that are listed in the help text can be added to the list.

Note: The SSLCONFIG/TLSCONFIG eligibleDefaultProtocols setting is reset by installing the Licensed Internal Code (LIC).

Example of setting TLSv1.2 to be the only default protocols on the system:
SSLCONFIG -eligibleDefaultProtocols:10

Example of setting TLSV1.3 and TLSv1.2 to be the only default protocols on the system (IBM i 7.3 only):
SSLCONFIG -eligibleDefaultProtocols:10,20

Example of setting TLSv1.3 and TLSv1.2 to be the only default protocol on the system (IBM i 7.4 and 7.5 only):
TLSCONFIG -eligibleDefaultProtocols:10,20

Table 2.
IBM i Release Eligible Default Protocol list with latest Security Group PTF
7.5 *TLSV1.3 *TLSV1.2
7.4 *TLSV1.3 *TLSV1.2
7.3 *TLSV1.3 *TLSV1.2 *TLSV1.1 *TLSV1
7.2 *TLSV1.2 *TLSV1.1 *TLSV1
7.1 *TLSV1
6.1 *TLSV1

Enabled cipher suites

The QSSLCSL system value setting identifies the specific cipher suites that are enabled on the system. Applications can negotiate secure sessions with only a cipher suite that is listed in QSSLCSL. The QSSLCSL system value setting identifies the specific cipher suites that are enabled on the system. No matter what an application does with code or configuration, it cannot negotiate secure sessions with a cipher suite if it is not listed in QSSLCSL. Individual application configuration determines which of the enabled cipher suites are used for that application.

For example, to restrict the System SSL/TLS implementation to use only Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) and not allow the RSA key exchange:

  1. Change QSSLCSLCTL system value to special value *USRDFN to allow the QSSLCSL system value to be edited.
  2. Remove all cipher suites from QSSLCSL that do not contain the ECDHE keyword.  
The QSSLCSLCTL system value special value *OPSYS allows the operating system to change the cipher suites that are enabled on the system on a release boundary. The value of QSSLCSLCTL remains the same when the system upgrades to a newer operating system release. If the value of QSSLCSLCTL is *USRDFN, then the administrator must manually add in newer cipher suites to QSSLCSL after the system moves to a new release. Setting QSSLCSLCTL back to *OPSYS also adds the new values to QSSLCSL.

A cipher suite cannot be added to QSSLCSL if the SSL/TLS protocol required by the cipher suite is not set in QSSLPCL.


Default cipher suites

When an application does not specify the cipher suites to enable, the ordered System SSL/TLS default cipher suite list is used. Applications use this design to pick up future new TLS support without requiring application code changes. The default cipher suite setting has no meaning for applications that explicitly specify the cipher suites to enable for the application.

The default cipher suites on a system are the intersection of the enabled cipher suites from QSSLCSL and the eligible default cipher suites. The eligible default cipher suites list is configured by using SSLCONFIG/TLSCONFIG option eligibleDefaultCipherSuites. The order of the default cipher suite list is the order the cipher suites appear in the QSSLCSL system value. To change the order, change QSSLCSL.

To determine the current value of the eligible default cipher suite list and the default cipher suite list on the system, use SSLCONFIG/TLSCONFIG option –display.

An administrator should only consider changing the default cipher suite list settings when no other configuration setting allows an application to interoperate with peers successfully. It is preferred to enable an older cipher suite for only the specific application that requires it. When the application has an “application definition,” then this enablement is accomplished through the Digital Certificate Manager (DCM).

WARNING:

Adding an older cipher suite to the default list results in opening up all applications that use the default list to known security vulnerabilities. Loading a Group Security PTF might result in the removal of a cipher suite from the default cipher suite list. Subscribe to the Security Bulletin to receive notification when a security mitigation includes this type of change. If an administrator adds back an eligible cipher suite that was removed by a Security PTF, the system remembers this change and does not remove it a second time when the next Security PTF is applied.

If the default cipher suite list must be changed on the system, use SSLCONFIG/TLSCONFIG option eligibleDefaultCipherSuites to change the value. SSLCONFIG/TLSCONFIG option -h displays the help panel that describes how to specify the changed cipher suite list. The help text includes the short hand values that are required by the option. Only cipher suites that are listed in the help text can be added to the list.

Note: The SSLCONFIG/TLSCONFIG eligibleDefaultCipherSuites setting is reset by installing the Licensed Internal Code (LIC).

Example of setting only ECDHE cipher suites as the default on the system:
SSLCONFIG -eligibleDefaultCipherSuites:YE,YD,YC,YB,YA,Y9,Y8,Y7,Y6,Y3

Example of setting only ECDHE and GCM cipher suites as the default on the system (IBM i 7.4 and later):
TLSCONFIG -eligibleDefaultCipherSuites:YI,YH,YG,YF,YC,YB,YE,YD
 

IBM i 6.1 OS

IBM i 7.1 OS

IBM i 7.2 OS

IBM i 7.3 OS

IBM i 7.4 OS

IBM i 7.5 OS


[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CIJAA2","label":"SSL TLS Communications"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"6.1.0;7.1.0;7.2.0;7.3.0;7.4.0;7.5.0;and future releases"}]

Document Information

More support for:
IBM i

Component:
SSL TLS Communications

Software version:
6.1.0, 7.1.0, 7.2.0, 7.3.0, 7.4.0, 7.5.0 and future releases

Operating system(s):
IBM i

Document number:
666411

Modified date:
06 December 2023

UID

nas8N1020876

Manage My Notification Subscriptions