Documentation for Content Manager Enterprise Edition System Move

IBM® Content Manager

Configuring transport layer security

IBM Content Manager Configuring Transport Layer Security

Special notice

The information contained in this publication was derived under specific operating and environmental conditions

and is distributed on an ‘as is’ basis without any warranty either expressed or implied. IBM specifically disclaims

any implied warranties of merchantability or fitness for any particular purpose. IBM assumes no responsibility for

any errors that may appear in this document. The use of this information or the implementation of any of these

techniques are the responsibility of the user and depends on the user's ability to evaluate and integrate them into the

user's operational environment. While each item might have been reviewed by IBM for accuracy in a specific

situation, there is no guarantee that the same or similar results will be obtained elsewhere. Users attempting to adapt

these techniques to their own environments do so at their own risk.

The information contained in this document is subject to change without any notice. IBM reserves the right to make

any such changes without obligation to notify any person of such revision or changes. IBM makes no commitment

to keep the information contained herein up to date.

References in this publication to IBM products, programs, or services do not imply that IBM intends to make these

available in all countries in which IBM operates. Any reference to an IBM licensed program in this publication is

not intended to state or imply that only IBM's program may be used. Any functionally equivalent program may be

used instead. Equivalent product, program, or services that do not infringe any of the intellectual property rights of

IBM may be used instead of the IBM product, program, or service.

The evaluation and verification of operation in conjunction with other products, except those expressly designated

by IBM, are the responsibility of the user.

IBM may have patents or pending patent application covering the subject matter in this document. The furnishing of

this document does not give you license to these patents. Any information about non-IBM (‘vendor’) products in

this document has been supplied by the vendor and IBM assumes no responsibility for its accuracy or completeness.

IBM, the IBM logo, ibm.com, AIX, Db2, Tivoli, and WebSphere are trademarks of International Business Machines

Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or

other companies. A current list of IBM trademarks is available on the Web at ‘Copyright and trademark

information‘ at www.ibm.com/legal/copytrade.shtml.

Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other

countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, or service names may be trademarks or service marks of others.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP

Schedule Contract with IBM Corp.

IBM Content Manager Configuring Transport Layer Security 

Contents 
Planning for transport layer security  5 
1  Communication types  6 
2  Communication end points (nodes)  7 
3  X.509 certificates and keystores  9 
4  IBM Content manager configuration with SSL-enabled Db2 instance  10 
5  Transport security settings for the library server  10 
Node configuration  13 
1  Creating or acquiring security certificates  14 
2  Configuring transport layer security for library server and resource manager 
databases  15 
3  Configuring the resource manager database JDBC  20 
4  Configuring the resource manager on z/OS  22 
5  Configuring library server services for transport layer security  23 
6  Securing the network communication to the Db2 Text Search document 
constructor  25 
7  IBM Content Manager Java API to the resource manager  26 
8  IBM Content Manager Java API JDBC to library server  29 
9  Configuring Resource Manager Application or REST and Web Services when 
WebSphere Application Server administrative security is enabled  31 
10 Configuring REST and Web Services when running in Liberty  31 
11 Configuring IBM Content manger to communicate with LDAP server  32 
Examples of applying transport layer security  38 
1  Scenario 1: Configuring the IBM Content Manager system administration 
client and API on Windows to recognize resource manager security certificates

2  Scenario 2: Configuring the library server to recognize resource manager 
security certificates in an environment that contains Windows  40 
3  Scenario 3: Securing network communications in an environment that 
contains Windows and Db2 for Linux, UNIX, and Windows  42 
4  Scenario 4: Securing network communications for TLS 1.3 in an environment 
that contains Windows and Db2 for Linux, UNIX, and Windows  47 
5  Scenario 5: Securing network communications in a Db2 z/OS database and 
z/OS resource manager environment  59 
6  Scenario 6: Securing network communications for REST or Web Services  66 

IBM Content Manager Configuring Transport Layer Security 

Key and certificate tools and examples  72 
1  Using the GSKit gsk8capicmd_64.exe command in 64-bit environments  72 
2  Using the keytool.exe tool to import certificates in java cacerts keystore  72 
3  Using the gskkyman program to manage security keys and certificates in a 
z/OS environment for resource manager  73 
 

IBM Content Manager Configuring Transport Layer Security

1 Planning for transport layer security

Transport Layer Security (TLS), and its predecessor Secure Sockets Layer (SSL), are

cryptographic protocols that you can use to secure your network environment. They encrypt

portions of network connections, for example, when data is exchanged using a web browser.

TLS and SSL use asymmetric cryptography for key exchange, and they use symmetric

encryption to keep data confidential. They also use authentication codes for messaging.

In this document, transport layer security refers to both TLS and SSL, unless stated.

Planning for transport layer security can be a complex task. You must consider:

 the capabilities of the programs on both sides of any communication channel

 the desired level of security. Higher levels of security can make performance slower.

 the limitations of the system software, and your optimum level of system software and

transport layer security if those limitations are removed in the future.

For example, your database might limit the configuration levels that are supported for security

purposes. These limitations might force you to avoid configuring the databases for TLS at all,

even as you configure other system nodes for more desirable, tighter levels of security.

The IBM Content Manager design strategy for security allows secure communication requests to

be accepted without requiring that non-secure links be removed. In other words, your security

scheme could allow calls to both non-secure URLs, such as http://www.sitename.com, and

to secure URLs, such as https://www.sitename.com. Therefore, do not remove the

non-secure paths until the secure paths are fully tested and you are sure that removal is required.

The IBM Content Manager system administration client opens connections to the resource

managers that are always created by the API as secure. For IBM Content Manager Enterprise

Edition, the resource manager enforces the requirement that all administrative functions have a

secure connection; if the communications channel is not encrypted the resource manager issues

an error. Similarly, you can configure the library server to require that clients use the secure port

for all communication without requiring the removal of the non-secure port.

Supported versions of TLS

TLS 1.3 is supported in IBM Content Manager starting with version 8.7 fix pack 2 with

limitations below. These are not supported:

1)LS DB or RMDB on Oracle configured with TLS 1.3

TLS 1.3 supported items in IBM Content Manager 8.7 fix pack 3

IBM Content Manager Configuring Transport Layer Security

1)Db2 Constructor: TLS 1.3 Support to RM

2)Library Server LDAP User Exit: Support TLS 1.3 to communicate with LDAP servers

3)zOS Library Server LDAP User Exit: Support TLS 1.3 to communicate with LDAP

servers

4)RMAPP(WAS) that is configured to use TLS 1.3 to communicate with LDAP servers

5)REST Services configured with TLS 1.3 in WAS/Liberty and/or Java

6)Web Services configured with TLS 1.3 in WAS and/or Java

7)System Administration Client LDAP: Support TLS 1.3 to communicate with LDAP

server

1.1 Communication types

When the transport layer security handshake occurs, the components that are communicating

agree on a key exchange protocol, signature algorithm, and encryption algorithm. They also

establish a trust relationship between the client and the server. The meaning of “trust” here is the

positive validating of the X.509 certificate that the client or server has. The trust relationship can

be one of the following types:

Type

Client

Server

Untrusted

Trusted

Untrusted

Trusted

The most common connection is type 2. Type 1 and type 3 are not often used. When browsers

detect an untrusted server, they usually tell you that the certificate is untrusted and that you

should not make the connection.

The IBM Content Manager system administration client uses a type 1 trust relationship by

default when it communicates with the resource manager. This client does not have a digital

certificate, but the resource manager server does have one. This configuration can be made more

secure.

IBM Content Manager Configuring Transport Layer Security

However, on Linux, UNIX, and Windows, the server certificate can often be the default

certificate that is installed by WebSphere Application Server. This certificate normally fails the

default trust checks. The system administration client has a custom trust manager that accepts

any certificate.

The certificates for resource manager on z/OS are stored in two ways:

 For incoming communications, certificates are stored in a keystore that is used by the IBM

HTTP Server.

 For outgoing communications, certificates are stored in a keystore that is used directly by the

resource manager on z/OS to initiate a secure replication to another z/OS or Enterprise

Edition resource manager.

1.2 Communication end points (nodes)

How you secure network communication is determined by the end points (nodes) in your

environment that you are trying to protect. Several security options are available.

For transport layer security in IBM Content Manager environments, you can use the IBM GSKit.

Other supported security providers include OpenJDK, and options from Oracle and supported

browsers.

After you have chosen your security provider options, you can configure them on the following

network nodes, or application program units, for inbound and outbound communication. For

information about which versions of the databases, operating systems, and other software that

IBM Content Manager supports, see its system requirements.

Node

Transport layer

security provider

Inbound

(server)

Outbound

(client)

Db2 database server (library server,

resource manager)

GSKit V8

Yes

Not applicable

Db2 on z/OS

System SSL,

Application

transparent TLS

(AT-TLS)

Yes

Not applicable

Oracle database server (library

server, resource manager)

Oracle

Yes

Not applicable

IBM Content Manager Configuring Transport Layer Security

Node

Transport layer

security provider

Inbound

(server)

Outbound

(client)

IBM Content Manager Java API

client

Varies for each JRE

provider

Not applicable

Yes

IBM Content Manager Java API

client JDBC

Varies for each

JDBC driver

Not applicable

Yes

Library server services

GSKit V8

Not applicable

Yes

Resource manager application server

Java 8

Yes

Resource manager database JDBC

Java 8

Not applicable

Yes

z/OS resource manager

IBM HTTP Server;

System SSL

Yes

Db2 Text Search

(Db2 Text Search does not support

transport layer security, but the Db2

Text Search document constructor

does support it. See “Securing the

network communication to the Db2

Text Search document constructor”

on page 25.)

Not supported by

Db2 for Linux,

UNIX, Windows, or

z/OS

Not supported by

Db2 for Linux,

UNIX, Windows,

or z/OS

Not supported

by Db2 for

Linux, UNIX,

Windows, or

z/OS

browser

Varies per browser

Not applicable

Yes

Each node requires a separate configuration process.

For each node, the chosen protocol level and security cipher suites must be compatible with all

the other nodes that are communication partners. Each cipher suite is a combination of the

authentication type (where the authentication takes place), digital key exchange algorithm, and

security cipher specification that is used to secure any exchange of data. This compatibility

requirement might limit the chosen protocol to the lowest common level. For an example, see

Authentication types supported with Db2 Connect Server.

With some nodes, inbound and outbound communication channels can be configured separately.

Some nodes support multiple protocol levels; others do not. Some nodes limit the combinations.

IBM Content Manager Configuring Transport Layer Security

1.3 X.509 certificates and keystores

You can establish certificates for transport layer security in several ways, depending on your site

requirements:

 Purchase certificates from a certificate provider.

 Use self-signed certificates.

 Set up your own certificate authority, and then create your own certificates. For more

information, see:

Creating a certificate authority

Trust Yourself: Become your own Certification Authority

To decide which method to use:

1 Consider the certificate type and the key strength that you need in your network environment.

2 Consider the distribution of the required certificates. If you are purchasing certificates, then

consider the key length of the purchased certificates, the key length of the signer certificates,

and the signing algorithms, so that they are adequate for your needs. Weak keys or signing

algorithms in signer certificates can be a security risk.

If client authentication is enabled, each client requires a certificate.

The strength and type of certificate that you require depends on your target configuration level.

It is possible, and sometimes necessary, to have more than one server certificate per server to be

able to communicate successfully with various clients.

Access to keystores and stash files

All keystores and stash files should have restricted access permissions. Secure these resources as

the operating system permits. The process owner must have read access to these files.

Using keystores

Keystores can store both private keys and certificates, which contain public keys. Some nodes

distinguish between keystores for personal certificates and truststores for holding signer

certificates that are trusted. All the keystores can hold personal certificates, private keys, and

trusted certificates. You have the option to keep all keys and certificates in a single keystore or

to keep separate keystores and trust stores.

Available command line tools have limitations on transferring private keys. However, it is

relatively easy to transfer, import, and export personal or trusted certificates. Therefore, you can

create any self-signed certificates in the type of keystore that you require to access private keys.

IBM Content Manager Configuring Transport Layer Security

Some utilities populate a keystore with a set of well-known signer certificates. These signer

certificates aid in establishing connections to servers that might use certificates signed by these

trusted signers. However, these certificates should be reviewed and removed if they are not

required and do not meet your security requirements.

Certification management system (CMS) keystores support a password stash file. Db2 and

library server require stash files, for example. Using the stash file means that they do not need to

store the password for the keystore.

Certificates can be read from a Java keystore (JKS) without a password. The password is

required to access a private key in the keystore.

Some nodes, such as the Db2 database server, require one personal certificate. Other nodes, such

as the WebSphere Application Server node, accept multiple personal certificates, one to match

each of the suggested cipher suites of the clients.

If you use multiple personal certificates on a server, make sure that only their algorithms differ

and that their name information is identical. Otherwise, there might some confusion in the

network communication.

1.4 IBM Content manager configuration with

SSL-enabled Db2 instance

To use IBM Content Manager with a Db2 instance that is SSL-enabled, you must make the

certificate files that are used by Db2 available to the IBM Content Manager configuration

program, and then tell IBM Content Manager to use SSL communication.

For more information, see Using a Db2 instance that is SSL-enabled.

1.5 Transport security settings for the library server

To set transport security settings for the library server, go to the Library Server Configuration

screen in the IBM Content Manager system administration client.

The outbound connections in this section are library server to resource manager only. The library

server is a set of stored procedures and API calls. Stored procedures through the Db2 connection

and library server does not have direct control over Db2 communication.

IBM Content Manager Configuring Transport Layer Security

These options correspond to IBM Content Manager Java API methods in DKLSCfgDefICM.

Disable Transport Layer Security (TLS) protocols earlier than TLS 1.2

When this option is set, API and library server outbound communications to the resource

manager require TLS 1.2 or higher. The API uses outbound communication to get or set

resource manager information or content.

When this option is enabled, the following library server functions that communicate with the

resource manager are affected:

 library server monitor service heartbeat

 library server retrieve of content for NSE text search indexing.

 Db2 text search constructor fetching content for indexing.

Require secure communication with resource managers

When this option is set, library server outbound communications to the resource manager use

HTTPS.

IBM Content Manager Configuring Transport Layer Security

When this option is enabled, the following library server functions that communicate with the

resource manager are affected:

 library server monitor service heartbeat

 library server retrieve of content for NSE text search indexing.

 Db2 text search constructor fetching content for indexing.

Request secure communication

When this option is set, the IBM Content Manager Java API uses HTTPS communications to the

resource manager if it is configured and available. If it is not configured in the resource manager,

HTTP communication to the resource manager is used.

This option links to the following option; that is, Require secure communication. For example,

if Require secure communication is on, Request secure communication must also be on.

Require secure communication

When this option is set, a companion bit is set by library server in all new tokens. The IBM

Content Manager Java API uses HTTPS communications to the resource manager or, if it is not

configured, returns an error. The resource manager rejects any request that has the companion bit

set in the token and is not transmitted over a secure connection.

If you are using an HTTP server with WebSphere Application Server, the connection is

considered secure if the link from the client to the HTTP server is SSL. (The link from the

WebSphere Application Server plugin on the HTTP server to the WebSphere Application Server

itself might or might not be configured as SSL.)

This secure communication affects the API when it communication to get or set resource

manager information or content.

Enforce 128 bit object tokens

When this option is set, the library server generates only 128-bit tokens.

Require certificate signature encryption with Secure Hash

Algorithm-2 (SHA-2)

When this option is set, the library server only accepts certificates signed with a minimum

SHA-256 signature hash.

IBM Content Manager Configuring Transport Layer Security

2 Node configuration

Set up transport layer security on the nodes for your IBM Content Manager environment in the

following order:

1 Create or acquire the security certificates that you need for your configuration.

2 Apply the certificates to the Db2 or Oracle database servers for the library server and the

resource manager.

3 Apply a certificate for the resource manager application server.

4 Apply a certificate for the resource manager database JDBC configuration.

5 Apply a certificate for the library server services.

6 Apply a certificate for each IBM Content Manager Java API client.

7 Apply a certificate for each IBM Content Manager Java API JDBC configuration.

Note: After adding a certificate for the resource manager application server if you get an error

like in the example below when starting or stopping WebSphere application server from an

adminstrator command window refer to WebSphere “Secure installation for client signer

retrieval in SSL” for possible solutions. Be sure to backup your trust.p12 before making any

changes.

Example:

C:\WebSphere90\AppServer\profiles\AppSrv01\bin>startServer server1

…

CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN

"CN=mufasa.unicom.local, OU=cm, O=unicom, C=US" was sent from target host:port

"xx.xxx.xx.xxx:8880". The signer may need to be added to local trust store

"C:/WebSphere90/AppServer/profiles/AppSrv01/etc/trust.p12" located in SSL configuration

alias "DefaultSSLSettings" loaded from SSL configuration file

"file:C:\WebSphere90\AppServer\profiles\AppSrv01/properties/ssl.client.props". The extended

error message from the SSL handshake exception is: "PKIX path validation failed:

java.security.cert.CertPathValidatorException: Path does not chain with any of the trust

anchors".

IBM Content Manager Configuring Transport Layer Security

2.1 Creating or acquiring security certificates

Before you begin, you must create or acquire the certificates that you need. You must have a

certificate for each physical or virtual server that you want to configure. A server certificate

identifies the domain name of the server. If all the program nodes are on one server, they can use

the same certificate.

GSKit providers

GSKit providers read only CMS and P12 keystores. In this context, P12 (or PKCS #12), is one

of the family of standards called Public-Key Cryptography Standards (PKCS). It is commonly

used to bundle a private key with its associated certificate, or to bundle all members of a security

chain of trust. For the library server, Db2 requires a CMS keystore, because it needs a password

stash file. GSKit includes a certificate tool called gsk8capicmd_64.exe that creates CMS

keystores. Db2 does not read Java keystores.

Java providers

Java providers can read Java keystores, P12 keystores, and CMS keystores if the CMS provider

is installed. To read keystores, the IBM SDK provides two utilities: Keytool and ikeyman.

 Keytool reads Java keystores and P12 keystores.

 ikeyman reads Java keystores, P12 keystores, and CMS keystores. To configure ikeyman to

support CMS keystores, you must ensure that:

 the java.security file in your Java installation includes a line similar to this:

security.provider.X=com.ibm.security.cmskeystore.CMSProvider

 the jre/lib/ext directory contains an ibmcmsprovider.jar file from the GSKit

installation.

OpenJDK providers

OpenJDK providers can read Java keystores and P12 keystores. To read keystores, the OpenJDK

provides the Keytool utility. Keytool reads Java keystores and P12 keystores.

Oracle wallets

Oracle wallets are P12 keystores. The Oracle wallet is needed when using an Oracle library

server database that is configured for SSL. However, they use a different encryption suite from

the IBM P12 keystores. An Oracle wallet does not provide a self-signed certificate generator.

You can install the Oracle PKI provider to work with Oracle wallets. The normal process for an

Oracle certificate is to create a Certificate Request by using the Oracle interface, and export the

certificate signing request (CSR) for signing. When you use an Oracle database on Linux, UNIX,

IBM Content Manager Configuring Transport Layer Security

or Windows, an Oracle wallets certificate must be added to the WebSphere Application Server

JRE cacerts to enable the resource manager communicate with the Oracle database, for example:

“%WAS_HOME%\java\8.0\bin\keytool" -import -v -noprompt -trustcacerts

-alias CMrootRSCA -file CMrootRSCA.arm -storepass changeit -keystore

"%WAS_HOME%\java\8.0\jre\lib\security\cacerts”

2.2 Configuring transport layer security for library

server and resource manager databases

The library server is contained in the database in which it runs. This means that when you

configure the database for inbound TLS connections, you also configure the library server.

2.2.1 Setting up transport layer security for the Db2 server for

Linux, UNIX, and Windows

For general information about configuring transport layer security for a Db2 database, see the

following Db2 documentation: Configuring TLS support on a Db2 server.

The following steps are based on that documentation, and include some information that is

specific to IBM Content Manager.

Complete the following steps for each database instance you want to configure. If resource

manager and library server are using different database instances, then complete the steps for

each instance.

1 Verify that the GSKit libraries are in the system path.

2 Make sure that the connection concentrator is deactivated, so that TLS support can be

enabled.

To check this, run the database manager configuration command on the Db2 command line:

db2 get dbm cfg

Verify that the value of MAX_CONNECTIONS is equal to or less than the value of

MAX_COORDAGENTS. If it is not, the connection concentrator is activated.

For example, the following result indicates that MAX_CONNECTIONS is set to

MAX_COORDAGENTS, which means that connection concentrator is deactivated:

Max number of coordinating agents (MAX_COORDAGENTS) = AUTOMATIC(200)

Max number of client connections(MAX_CONNECTIONS) = AUTOMATIC(MAX_COORDAGENTS)

3 Get a server certificate and private key for the Db2 instance.

IBM Content Manager Configuring Transport Layer Security

You can either create a certificate request using GSKit and have it signed by a Commercial

Certificate provider, or create a self-signed certificate. For information on creating your

certificate authority, see “X.509 certificates and keystores” on page 8.

4 Import the signed certificate into a GSKit CMS keystore as myDB2key.p12.

5 Create a stash file for the password that protects the keystore as myDB2key.sth.

6 Export the server certificate to a file in base64-encoded form as db2ServerCert.cer.

This value is used later when you configure the WebSphere Application Server data source.

7 Create a new service name and assign an unused port.

These values are used for Db2 SSL connections in the services file of the server.

8 From a Db2 administration client or command line, change the database manager

configuration for the Db2 instance by using the following table.

Description

Key

Example value

SSL server key database file

SSL_SVR_KEYDB

/usr/certificates/myDB2key.p12

SSL server password stash

file

SSL_SVR_STASH

/usr/certificates/myDB2key.sth

SSL server certificate label

SSL_SVR_LABEL

mydb2.com

SSL service name

SSL_SVCENAME

db2c_TLS

SSL version

SSL_VERSIONS

TLSV12,TLSV13

9 Change the Db2 environment setting to read:

db2set -i db2 DB2COMM=SSL,TCPIP.

This action configures the Db2 to use both SSL and TCPIP as communication protocols.

10 Restart Db2.

Db2 now listens on two ports: one for TCPIP and one for SSL.

2.2.2 Setting up transport layer security for the Oracle server

Install the Oracle Advanced Security Package, and then configure Oracle Net to listen for SSL

connections:

1 Use Oracle Wallet Manager to create a new Oracle wallet (PKCS12).

IBM Content Manager Configuring Transport Layer Security

2 Create a certificate signing request.

For the Common Name value, enter the fully-qualified domain name of the server.

3 Get the certificate request signed, and then import it and any required signer certificates to the

Oracle wallet.

4 Select Wallet from the menu, and then select Auto-login.

IBM Content Manager Configuring Transport Layer Security

5 Make sure that the Wallet Directory value is correct.

6 Click Add. For the domestic cipher suites, add RSA_AES128_CBC_SHA,

RSA_DES_CBC_SHA,RSA_EXPORT_DES40_CBC_SHA in that order.

7 Make sure that Revocation Check is set to NONE, Require SSL version is set to TLS 1.0,

and Client Authentication is not selected.

8 Navigate to Oracle Net Configuration > Local > Listeners > LISTENER, and then select

Listening Locations.

9 Click Add. For Protocol, select TCP/IP with SSL, and then enter the database server host

name and port.

10 Click File > Save Network Configuration.

11 Edit the NETWORK > ADMIN > sqlnet.ora file for the Oracle instance. Change the

following line:

SSL_VERSION = 3.1

SSL_VERSION = 1.0.

IBM Content Manager Configuring Transport Layer Security

12 Restart the listener service. For example, enter the following commands on the command

line:

lsnrctl stop

lsnrctl start

2.2.3 Setting up transport layer security for Db2 for z/OS for

library server

To configure transport layer security for a Db2 for z/OS database for library server on z/OS, see

the information for your database version in the Db2 for z/OS documentation. For example, for

version 12 information, see Encrypting your data with Secure Socket Layer support.

For more information, see this Redbook:

 Db2 for z/OS: Configuring SSL for Secure Client-Server Communications

2.2.4 Configuring inbound communications for the enterprise

edition resource manager

By default, the resource manager listens for inbound communication on two ports: one for

normal TCPIP traffic, and one for TLS traffic.

To configure transport layer security for the TLS port

1 In the WebSphere Application Server administration client, navigate to Servers >

WebSphere application servers > {icmrm} > Web container settings > Web container

transport chains > NodeDefaultSSLSettings > SSL inbound channel (SSL_2) > SSL

configurations > CellDefaultSSLSettings > Quality of protection (QoP) settings.

2 In the Client authentication selection list, and then select Supported.

This setting enables the resource manager to request the Clients X.509 certificate. Clients are

not required to provide a certificate.

3 Save the configuration.

2.2.5 Configuring resource manager outbound communications

Outbound resource manager communication covers traffic flowing from the resource manager to

other resource manager services, for processes such as replication and remote migration.

These services run as threads inside the resource manager application server.

IBM Content Manager Configuring Transport Layer Security

1 To configure a target server to use TLS, open the IBM Content Manager system

administration client, and then go to the server properties screen.

2 Specify HTTPS for the protocol.

3 Ensure that the port is the TLS port on which the server is listening.

2.3 Configuring the resource manager database JDBC

For transport layer security for each resource manager, you must configure a data source for the

library server database and the resource manager database.

Add each database server certificate, or its signer certificate chain, to the WebSphere

Application Server truststore. For more information about how to do this, see Adding a signer

certificate to a keystore in the WebSphere product documentation.

2.3.1 Configuring Db2 JDBC for the resource manager

Configure the resource manager data sources for Db2 in the WebSphere Application Server.

This configuration is required for both the library server and resource manager data source.

To configure the resource manager data sources

1 Navigate to Resources > JDBC > Data sources.

2 Find the data source names that start with the resource manager application name, such as

icmrm_database and icmrm_LS_database.

3 For each data source, make the following changes:

 Change the port to use the db2 SSL port.

 Add the sslConnection property, with a value of true to the data source custom

properties.

 Add the sslVersion property, with a value of the ssl version (ie TLSv12 or TLSv13) to

the data source custom properties if you wish to specify a particular ssl version.

 Save the configuration, and then test the data source.

2.3.2 Configuring Oracle JDBC for the resource manager

On WebSphere Application Server, change the resource manager Java virtual machine (JVM)

custom properties with the required Oracle properties to configure SSL for the data sources.

To make sure that that the test connection function in WebSphere Application Server works, you

must change the JVM properties for the JVM that runs the test connection function. In a

IBM Content Manager Configuring Transport Layer Security

Network Deployment (ND) environment, apply the change to the nodeAgent JVM for each

NODE. You might have to restart the nodeAgent to apply the changes.

The Oracle connection pool class for JDBC does not support a constructor that accepts

properties as input. Therefore, you must set the properties as JVM system properties.

To modify the resource manager JVM custom properties

1 In the WebSphere administrative console, select Server > Server Types > WebSphere

application servers.

2 Double-click the application server to go to Application servers > icmrm.

3 Expand Java and Process Management.

4 Select Process definition.

5 Select Java Virtual Machine.

6 Select Custom Properties.

7 Click New, and then add the following properties:

Property

Value

Description

oracle.net.ssl_version

Use TLS V1.0

oracle.net.ssl_client_authentication

FALSE

No client certificate

oracle.net.ssl_cipher_suites

(SSL_RSA_WITH_AES_1

28_CBC_SHA,

SSL_RSA_FIPS_WITH_D

ES_CBC_SHA)

Allows cipher suites

oracle.net.crypto_checksum_client

REJECTED

No check sum

oracle.net.encryption_client

REJECTED

No additional encryption

8 Save the configuration.

9 Change the resource manager data sources URLs, so that they contain the correct port and

protocol. The PROTOCOL statement in the URL tells the Oracle JDBC classes to use SSL.

The format of the URL must be similar to this:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=newfdog.ibm.com)

(PORT=2845))(CONNECT_DATA=(SERVICE_NAME=orcl.ibm.com)))

IBM Content Manager Configuring Transport Layer Security

2.4 Configuring the resource manager on z/OS

For the resource manager on z/OS, you must configure security for both inbound and outbound

network communications.

Configuring inbound communications for the resource manager on

z/OS

The resource manager on z/OS runs under the IBM HTTP Server for z/OS. It can be configured

to listen on ports for only HTTP; only HTTPS; or both. The resource manager receives all of its

inbound traffic from the HTTP server; therefore, it does not need to be configured separately to

support inbound HTTPS requests. For transport layer security, only the HTTP server must be

configured; the resource manager does not have to be configured.

Configuring outbound communications for the resource manager on

z/OS

Changes to the definitions of resource managers are not dynamically propagated to pending

replicas. Therefore, when you change either the protocol or the port for a resource manager that

is the target of a replication, make sure that at least one of the following conditions is met:

 No pending replicas exist.

 The protocol and port values that are specified for the pending replicas will still be valid

when the Asynchronous Replication runs again.

To secure outbound communications that are performed by the resource manager on z/OS

Asynchronous Outbound Replication, you must configure the resource manager to access and

trust a specific keystore.

Specifically, you must identify the keystore in the ?SSLKEYFILE? JCL keyword that is in the

ICMMRMAP sample. The ?SSLKEYFILE? JCL keyword tells the resource manager on z/OS

Asynchronous Replication which keystore to trust and open. Both Key database and SAF

keyrings are supported. For more information, see the samples and the ISPF Job Configuration

tool screen.

For more information, see Certificate/Key Management in the z/OS Cryptographic Services

System SSL Programming documentation.

Enforcing TLS 1.2 and TLS 1.3

To enforce outbound communications over TLS 1.2 and TLS 1.3, and not allow lower protocols,

set the ENFORCE_TLS12 column to 1 in one row of the ICMRMCONTROL table of the

IBM Content Manager Configuring Transport Layer Security

resource manager on z/OS. This setting disables all protocols lower than TLS 1.2, including SSL

V3, TLS V1.1, and TLS V1.0.

2.5 Configuring library server services for transport

layer security

The ICMFetchFilter and ICMFetchContent UDFs (user-defined functions) and the

ICMKEYMGMT stored procedure for KeyFlush are library server services. LS Monitor is also a

library server service. ICMFetchFilter and ICMFetchContent are used only if you have NSE text

search installed.

Note: NSE is deprecated; support for NSE will be removed in a future release.

To configure these library server services to use TLS, change the following new library server

database columns in the ICMSTSYSCONTROL. To change the columns, use either the IBM

Content Manager system administration client or the associated API. For more information, see

“Error! Reference source not found.” on page 10. This information applies to IBM Content

Manager Enterprise Edition and IBM Content Manager for z/OS. The keystore that is defined

must be a CMS keystore with a stash file. On z/OS, GSKit supports CMS keystores as well as a

System Authorization Facility (SAF) keyring, which requires no stash file but should be secured

by Resource Access Control Facility (RACF) system permissions.

Column

Data type

Attribute

Definition

KEYSTOREFILE

VARCHAR(259)

nullable

The full name, including path and

file name, of the keystore file that is

used by the library server for secure

communication to its resource

managers. This field is required

when bit 22 of SystemFlag2 is on.

KEYSTORESTASHFILE

VARCHAR(259)

nullable

The full name, including path and

file name, of the keystore stash file

that is associated with the keystore

file that is defined in the

KEYSTOREFILE field. This

KEYSTORESTASHFILE field is

required if the keystore file is

password protected.

IBM Content Manager Configuring Transport Layer Security

Column

Data type

Attribute

Definition

KEYSTORECERTLABEL

VARCHAR(128)

nullable

The certificate label associated with

a client certificate in the keystore

that is defined in the

KEYSTOREFILE field. This

defined certificate can be used by

the library server to authenticate

with its resource managers over a

secure connection. This field is

optional.

The library server SYSFLAG2 definitions control the transport layer security by using the

following bits, which correspond to the methods in DKLSCfgDefICM:

Bit

Description

When set to 1, the communication from library server to its resource manager is secured.

When set to 1, and the bit 22 is set to 1, library server services and API requires TLS 1.2

or higher.

When set to 1, the API attempts to use TLS to contact resource manager. This setting

requires a minimum amount of API configuration. If TLS communication is not

successful, the API uses TCPIP.

When set to 1, the library server includes in all new tokens the secure communications

required flag. The resource manager refuses any such requests that are not made over a

secure connection.

Not yet implemented; reserved for future use.

When set to 1, and bit 25 is set to 1, library server sets the client-authentication-required

bit in the new token. This setting requires that the client has an X.509 certificate that is

passed from the API to the library server and is included in the new token. The resource

manager must be configured to request a client certificate by using TLS, and checks that

the certificate that is presented matches the one that library server was given.

Must be set to 0 on z/OS to indicate that ICSF is enabled. No other values are supported.

IBM Content Manager Configuring Transport Layer Security

Bit

Description

When set to 1, the library server accepts only certificates that are signed with a minimum

of SHA256.

2.6 Securing the network communication to the Db2

Text Search document constructor

The Db2 Text Search document constructor retrieves documents from the resource manager by

using an HTTP or HTTPS connection depending on the library server security settings. You can

configure it to use a more secure transport layer.

To configure the document constructor connection to resource

manager to be SSL enabled

1 In the Library Server Configuration screen of the IBM Content Manager system

administration client, open the Security tab, and then enable the following options:

Require secure communication with resource managers: Enables the secure connection to

the resource manager. The constructor will try to use TLS 1.3, but fallback to weaker

protocols if needed.

Disable Transport Layer Security (TLS) protocols earlier than TLS 1.2 (optional):

Enforces TLS 1.2 or higher for this secure connection.

2 Import the certificate required to authenticate with the resource manager into the Java

keystore for the Java that is used to run the Db2 Text Search server. Currently, only the Java

keystore is supported.

The Java keystore that is used is determined by the Java home (JAVA_HOME) system

property, as in $(JAVA_HOME)/lib/security/cacerts. The keystore and trust manager

are initialized when they are first used. If you change the certificate, you must restart the text

search server. If Java Home is not set explicitly, the Java that is installed with Db2 will be

used to start the text search server. For example

/opt/ibm/db2/V11.1/java/jdk64/jre on Unix or C:\IBM\SQLLIB\java\jdk\jre

on Windows.

Note: If you update or upgrade Db2, you may need to restore any certificates that are in the

cacerts for the Db2 JRE.

IBM Content Manager Configuring Transport Layer Security

2.7 IBM Content Manager Java API to the resource

manager

The following IBM Content Manager API configuration properties are specified in the

cmbicmsrvs.ini file. You can set comparable options in the datastore connection string,

which override the settings that are in the cmbicmsrvs.ini file. The names of the datastore

connection string options are slightly different from the names of the cmbicmsrvs.ini file

properties: they do not have ICM at the start.

The IBM Content Manager Java API has entries for both a truststore and a keystore. These

entries can be the same physical keystore. The default keystore is the Java keystore (JKS) called

cacerts.

The configured truststore must be populated with the certificates that are used for the Library

server database and the resource manager application server.

Note: If you update or upgrade IBM Content Manager, you must restore any certificates that

are in the cacerts to the IBM Content Manager Java JRE. This is because the IBM Content

Manager Java JRE is overwritten when you update or upgrade IBM Content Manager.

Configuration settings

The following configuration settings affect how the API communicates with the resource

manager.

For sample configurations for the Java implementations that are supported, see:

https://www.ibm.com/docs/en/content-manager/8.7.0?topic=8-configuring-transport-layer-securi

For information about options that are referenced in the Javadoc for DKDatastoreICM::connect

method, see:

https://www.ibm.com/docs/en/content-manager/8.7.0?topic=comibmmmsdkserver-dkdatastoreic

Property

Example value or allowed

value

Description

ICMRMCOMMTYPE

HTTPS_AVAILABLE |

HTTPS_ONLY | HTTP

To force HTTPS, use

HTTPS_ONLY

ICMRMSSLTRUSTSTORE

C:\jdk-11.0.18+10\lib

\security\cacerts

Full path name of the

truststore

IBM Content Manager Configuring Transport Layer Security

Property

Example value or allowed

value

Description

ICMRMSSLTRUSTSTORE

TYPE

JKS

Format of the truststore

ICMRMSSLTRUSTSTORE

PROVIDERNAME

SUN

Name of the truststore

provider

ICMRMSSLTRUSTMGR

ALGORITHM

PKIX

Trust manager algorithm

ICMRMSSLTRUSTMGR

PROVIDERNAME

SunJSSE

Name of the truststore

manager provider

ICMRMSSLKEYSTORE

C:\jdk-11.0.18+10\lib

\security\cacerts

Fully qualified path of the

keystore

ICMRMSSLKEYSTORE

TYPE

JKS

Format of the keystore

RMSSLKEYSTOREPWD

Only on the datastore connect

string

ICMRMSSLKEYMGR

ALGORITHM

SunX509

Keystore manager algorithm

ICMRMSSLKEYMGR

PROVIDERNAME

SunJSSE

Name of the keystore manager

provider

ICMRMSSLCERTIFICATE

AUTH

TRUE | FALSE

Certificate authorization

RMSSLCERTIFICATE

LABEL

my-rm-client-cert

Keystore label name for client

certificate

IBM Content Manager Configuring Transport Layer Security

Property

Example value or allowed

value

Description

ICMRMSSLCBC

PROTECTION

TRUE | FALSE

Specifies whether cipher block

chaining (CBC) protection is

enabled for secure

communication with the

resource manager; the

recommend value is TRUE

ICMRMSSLPROTOCOL

MINTLS12

TRUE | FALSE

Set to FALSE until you are

sure all TLS partners can

support TLS 1.2 or higher

ICMRMSSLCIPHERSUITE

FILTERING

TRUE | FALSE

TRUE allows weak ciphers to

be disallowed

ICMRMSSLCIPHERSUITE

TLS_AES_128_GCM_SHA25

6,TLS_AES_256_GCM_SHA

384

Cipher suites supported by

web server and java

ICMRMSSLCONTEXT

PROTOCOL

SSL | SSLv3 | TLS | TLSv1

| TLSv1.1 | TLSv1.2 |

TLSv1.3 | SSL_TLS |

SSL_TLSv2

Context Protocol

ICMRMSSLRNGALGORIT

Secure random number

generator algorithm used for

secure context

ICMRMSSLRNGPROVIDE

Secure random number

generator provider used for

secure context

ICMRMUSESSLFORURLB

ASEDRETRIEVES

TRUE | FALSE

Specifies whether to use

secure communications for

URL-based retrieves;

recommend TRUE

IBM Content Manager Configuring Transport Layer Security

Property

Example value or allowed

value

Description

ICMRMCONNTIMEOUT

Connection timeout value

ICMRMCONNPOLLINTER

VAL

Connection polling interval,

which can affect response

times

ICMRMCONNREADTIME

OUT

5000

The timeout on waiting to read

data

2.8 IBM Content Manager Java API JDBC to library

server

The IBM Content Manager API configuration options (properties) are specified in the

cmbicmsrvs.ini file. Options can also be set in the datastore connection string which

overrides those options that are set in the cmbicmsrvs.ini file. Datastore options do not have

“ICM” at the start of their name.

Configuration settings

The following configuration settings affect how the API communicates with the library server.

For information about the options that are referenced in the Javadoc for the

DKDatastoreICM::connect method, see:

https://www.ibm.com/docs/en/content-manager/8.7.0?topic=comibmmmsdkserver-dkdatastoreic

Property

Example value or

allowed values

Description

ICMDBSSL

TRUE | FALSE

Set to TRUE to enable TLS

ICMDBSSLPORT

(Db2 only) Database SSL port

number

ICMDBSSLTRUSTSTORE

(Oracle only) Database truststore

name

IBM Content Manager Configuring Transport Layer Security

Property

Example value or

allowed values

Description

ICMDBSSLTRUSTSTORE

TYPE

(Oracle only) Database truststore

type

DBSSLTRUSTSTOREPWD

(Oracle only) Database truststore

password; only needed on the

datastore connect string

ICMDBSSLKEYSTORE

(Oracle only) Database keystore

name

ICMDBSSLKEYSTORE

TYPE

JKS

(Oracle only) Database keystore

type

DBSSLKEYSTOREPWD

(Oracle only) Database keystore

password; only needed on the

datastore connect string

ICMDBSSLVERSION

1.0

TLSv1.2 | TLSv1.3

(Oracle) Database SSL version

(DB2) Database SSL version

ICMDBSSLCIPHERSUITES

SSL_RSA_WITH_AES_1

28_CBC_SHA |

SSL_RSA_FIPS_WITH_

DES_CBC_SHA

(Oracle only) Database cipher

suites

ICMDBSSLDISTINGUISHED

NAMEMATCH

TRUE | FALSE

(Oracle only) Specifies whether

mutual authentication is enabled

between a database server and

other systems over an SSL

junction. See:

SSL With Oracle JDBC Thin

Driver: An Oracle Technical

White Paper

IBM Content Manager Configuring Transport Layer Security

2.9 Configuring Resource Manager Application or REST

and Web Services when WebSphere Application

Server administrative security is enabled

1. The server certificate needs to be added to the client trust store (example:

C:\WebSphere90\AppServer\profiles\AppSrv01\etc\trust.p12) when administrative security is enabled.

This is true regardless of whether WAS QoP is set to TLS 1.3 or not.

2. Find the location of the ssl.client.props file (example: C:\WebSphere90

\AppServer\profiles\AppSrv01\properties\ssl.client.props). When TLS 1.3 is the only protocol set in WAS

QoP, com.ibm.ssl.protocol=TLSv1.3 must be set in the ssl.client.props file.

For more information, see Configuring the resource manager application or REST/Web Services

when the WebSphere Application Server is limited to only TLS.

For more information, see Configuring the REST Services and web services.

2.10 Configuring REST and Web Services when running in

Liberty

To configure REST and Web Services to run under WebSphere Liberty see Configuring the

REST Services and web services. Once the configuration is done, it is straight forward to add

support for TLS.

To configure REST and Web Services to communicate with IBM Content Manager servers that

are TLS enabled, you need to configure the IBM Content Manager API that is used with REST

and Web Services. The INI files will be found in the directory

${server.config.dir}/configDropins/overrides/cmgmt. This configuration is described

in section IBM Content Manager Java API to the resource manager and IBM Content Manager

Java API JDBC to library server.

If JDBC pooling is configured for REST or Web Services, the pool configuration must also be

updated to communicate using TLS to the IBM Content Manager library server. In the data

source definition, you must make sure to reference the TLS port of the database. You must

also add the following configuration:

sslConnection="true"

If TLS 1.3 is used, you must also add:

sslVersion="TLSv1.3"

An example data source definition in Liberty may look like this:

<dataSource id="cmrest_icmnlsdb_tls_ds" isolationLevel="TRANSACTION_READ_COMMITTED"

IBM Content Manager Configuring Transport Layer Security

type="javax.sql.ConnectionPoolDataSource" jndiName="jdbc/cmrest_icmnlsdb_tls">

<properties.db2.jcc portNumber="50020" serverName="10.130.30.2"

databaseName="icmnlsdb" currentSchema="ICMADMIN"

user="icmconct" password="password"

sslConnection="true" sslVersion="TLSv1.3"/>

</dataSource>

To configure REST or Web Services to provide a TLS interface, you must expose an HTTPS

port. In the server.xml, this would look like this:

<httpEndpoint id="defaultHttpEndpoint"

httpPort="9090"

httpsPort="9453"/>

By default, this should use TLS 1.2. If you need to configure for TLS 1.3, also add the follow-

ing to server.xml:

Once these configuration changes are done, the server running REST or Web Services must be

restarted for the changes to take effect.

Note that if REST or Web Services are configured to provide TLS communication, any client

application that accesses them will need to import the certificate that is used in the WebSphere

Liberty server.

2.11 Configuring IBM Content manger to communicate

with LDAP server

Users can integrate LDAP with your content management system, from 8.7 fix pack 3 you can

configure all LDAP communication with TLS 1.3. This will involve LDAP server side settings,

content manager LDAP communication configuration, configuration of the system administrator

client import LDAP user and LDAP user import Scheduler, and configuration of the library

server to authenticate LDAP user.

See detailed description at

https://www.ibm.com/docs/en/content-manager/8.7.0?topic=ldap-integrating-content-manager-e

nterprise-edition.

IBM Content Manager Configuring Transport Layer Security

See detailed description at for LDAP with Content Manager for z/OS

https://www.ibm.com/docs/en/content-manager/8.7.0?topic=ldap-integrating-content-manager-z

zOS LDAP user exit with Content Manager for z/OS from 8.7 fix pack 3 add the following

variables

 TLS 1.2

GSK_PROTOCOL_TLSV1_2=ON

 TLS 1.2 and TLS 1.3

GSK_PROTOCOL_TLSV1_2=ON

GSK_PROTOCOL_TLSV1_3=ON

LDAP_SSL_CIPHER_FORMAT=CHAR4

GSK_V3_CIPHER_SPECS_EXPANDED=13021303003500380039002F00320033

GSK_CLIENT_TLS_KEY_SHARES=002300250029

 TLS 1.3

GSK_PROTOCOL_TLSV1_3=ON

LDAP_SSL_CIPHER_FORMAT=CHAR4

GSK_V3_CIPHER_SPECS_EXPANDED=13021303003500380039002F00320033

GSK_CLIENT_TLS_KEY_SHARES=002300250029

1.Check and make sure the LDAP server can support TLS 1.3

For example, for IBM LDAP server, IBM Security Verify Directory 10.0.1 can support TLS 1.3. TLS

1.3 can be enabled by checking “SSL and TLS” secure communication with proper protocol,

which is for SSL and TLS. This will use the secure port for communication. “TLS” only option is

used to enable TLS communication through non-secure port, which is not support by Content

manager.

IBM Content Manager Configuring Transport Layer Security

Then you need to create a certificate and add it to LDAP server key database. Please refer to

this document to how to create the certificate with the gskit tool or refer to this link

https://www.ibm.com/docs/en/content-manager/8.7.0?topic=communication-creating-key-databa

se-file

The following is an example for those commands in order.

gsk8capicmd_64 -keydb -create -db clientkey_v10_T13.kdb -pw myPassword

gsk8capicmd_64 -cert -add -db clientkey_v10_T13.kdb -pw myPassword -label serverlabel –file

server_v10_T13.der -format binary

gsk8capicmd_64 -keydb -create -db serverkey_v10_T13.kdb -pw myPassword –stash

gsk8capicmd_64 -cert -create -db serverkey_v10_T13.kdb -pw myPassword -label

serverlabel -dn "cn=cmappqvw06.xxxxxx.software,o=ibm.com" -expire 7300 -ca true

-sigalg SHA256_WITH_RSA -size 2048

gsk8capicmd_64 -cert -extract -db serverkey_v10_T13.kdb -pw myPassword -label serverlabel

-target server_v10_T13.der -format binary

gsk8capicmd_64 -keydb -create -db clientkey_v10_T13.kdb -pw myPassword

gsk8capicmd_64 -cert -add -db clientkey_v10_T13.kdb -pw myPassword -label serverlabel -file

server_v10_T13.der -format binary

For IBM Security Verify Directory, you may add the kdb file as following. LDAP server needs

to be restarted after these configuration changes.

IBM Content Manager Configuring Transport Layer Security

For other LDAP servers and Active Directory, you can do similar things to make sure to enable

LDAP server side for TLS 1.3 communication.

2.LDAP server configuration for TLS1.3

The way to configure for TLS1.3 is the same as the configuration to support SSL.

IBM Content Manager Configuring Transport Layer Security

Using secure port for TLS1.3, the default port is 636.

Also check the “SSL” option, this option is also for “TLS” enablement. For the “SSL

Keyring file”, add the kdb file created with TLS1.3 before.

3, System administrator client and LDAP user import scheduler to communicate LDAP

server with TLS 1.3.

Both of these applications use the content manager embedded java/jre, which enables

TLS1.3 by default. All you need to do is to import the certificate to the keystore file: cacerts.

https://www.ibm.com/docs/en/content-manager/8.7.0?topic=communication-configuring-sys

tem-administration-client-ssl

keytool is in this folder: IBMCMROOT\java\jre\bin

cacaerts file is in this folder: IBMCMROOT\java\jre\lib\security\

For example: keytool -importcert -alias CM87KeySSL –keystore

C:\IBM\db2cmv8\java\jre\lib\security\cacerts -storepass changeit -file

c:\temp\server_v10_T13.der

Then you can run system administrator client to manually import LDAP users to the library

server. If you have a lot of LDAP users to manage, it is recommended to use LDAP user

import scheduler to import all needed LDAP users to the library server and synchronize

them.

IBM Content Manager Configuring Transport Layer Security

4, Configure Library Server to communicate with LDAP server with TLS 1.3

After all LDAP users are imported to the library server, configuration is needed to make sure

LDAP users can be authenticated by LDAP server with TLS1.3 protocol. The most

important part is to install "IBM Security Verify Directory” client package 10.0.1 or later on

the library server and also use the content manager user exit (ICMXLSLG.DLL) from 8.7 fix

pack 3 release.

Here are the steps:

4-1 Install pre-req for LDAP user authentication.

The client package from IBM Security Verify Directory must be installed on the library

server machine. Release 10.0.1 and after fully support TLS1.3 protocol. If you have the

client package from “IBM Security Directory server v6.4” installed on the machine, you

need to upgrade it to 10.0.1 or later. Also, GSKit 8.0.55.31 was packaged with this release, it

must be upgraded on the library server machine as well.

https://www.ibm.com/docs/en/content-manager/8.7.0?topic=edition-installing-prerequisite-s

oftware-ldap-user-authentication

download location:

https://www.ibm.com/support/pages/ibm-security-verify-directory-version-1001-download-d

ocument

Client package includes the ldapsearch tool. This tool can be used to verify the

communication from the library server machine to LDAP Server with the certificate.

4-2 Update user exit (ICMXLSLG.DLL)

LDAP user exit (ICMXLSLG.DLL) is responsible for LDAP user authentication, this file in

located at PATHICMDLL/DBNAME/ directory, it needs to be updated with the one from 8.7

fix pack 3, which include the function to support TLS 1.3 communication.

4-3 Other basic configuration steps which are for SSL communications

Copy the cmbcmenv.properties file that was updated with the SSL/TLS information from the

system administration client to the library server system. Also, need to make sure to copy

certificate file (for example clientkey_v10_T13.kdb) to the directory IBMCMROOT/cmgmt

on the library server machine.

https://www.ibm.com/docs/en/content-manager/8.7.0?topic=communication-configuring-libr

ary-server-ssl-ldap-server

Then LDAP users should be able to log on to content manger system.

IBM Content Manager Configuring Transport Layer Security

3 Examples of applying transport layer security

How you apply transport layer security depends on many factors, including: the system software;

the level of security you want; and your network environment.

3.1 Scenario 1: Configuring the IBM Content Manager

system administration client and API on Windows to

recognize resource manager security certificates

This scenario shows how to set up an IBM Content Manager system on clients running Windows

and WebSphere Application Server.

Planning

Assume that you want to configure your computers for IBM Content Manager components and

the following software:

 Windows 2019

 IBM Content Manager System Administration Client and IBM Content Manager API

 64-bit JRE

 WebSphere Application Server V9.0.5.

Extract root certificate from WebSphere using WebSphere Integrated

Solutions Console

1 Install WebSphere Application Server, and then create the resource manager application

server.

2 Create a directory in which to save the your root truststore certificate, for example:

c:\mycert

3 Extract the Node default root certificate to an ASCII .arm file for distribution. Login to the

WebSphere administrative console, and then select Security > SSL certificate and key

management > Key stores and certificates > NodeDefaultTrustStore >Signer certificates

4 Select the default certificate option; specify the certificate file name (for example,

c:\mycert\myRMSigner.arm); select Base64-encoded ASCII data; and then click OK.

This default certificate file, myRMSigner.arm, must be distributed to all clients.

5 Add the myRMSigner.arm file to the JRE that is used by the system administration client

and the API.

IBM Content Manager Configuring Transport Layer Security

6 Change to the directory where the myRMSigner.arm file is, and then run the following

command:

System Administration client

"C:\IBM\db2cmv8\java\jre\bin\keytool -import -v -noprompt -trustcacerts -alias rmroot1 -file

myRMSigner.arm -storepass changeit -keystore C:\IBM\db2cmv8\java\jre\lib\security\cacerts"

The security certificate is added to this keystore:

C:\IBM\db2cmv8\java\jre\lib\security\cacerts

API

"C:\jdk-11.0.18+10\bin\keytool -import -v -noprompt -trustcacerts -alias rmroot1 -file

myRMSigner.arm -storepass changeit -keystore C:\jdk-11.0.18+10\lib\security\cacerts"

The security certificate is added to this keystore:

C:\jdk-11.0.18+10\lib\security\cacerts

Configuring communications between the IBM Content Manager API

and the resource manager

The following options configure the communications between the connector and the resource

manager using https communication.

 To use the added certificates in the example above, set the following options for the library

server in the cmbicmsrvs.ini file:

ICMRMCOMMTYPE=HTTPS_AVAILABLE

ICMRMSSLCERTIFICATEAUTH=TRUE

ICMRMCOMMTYPE=HTTPS_ONLY

ICMRMSSLCERTIFICATEAUTH=TRUE

 If you do not want use certificate authentication, set the following options for the library

server that you are using in the cmbicmsrvs.ini file:

ICMRMCOMMTYPE=HTTPS_AVAILABLE

ICMRMSSLCERTIFICATEAUTH=FALSE

ICMRMCOMMTYPE=HTTPS_ONLY

ICMRMSSLCERTIFICATEAUTH=FALSE

IBM Content Manager Configuring Transport Layer Security

Note: If you update or upgrade IBM Content Manager, you must restore any certificates that

are in the cacerts to the IBM Content Manager Java JRE. This is because the IBM Content

Manager Java JRE is overwritten when you update or upgrade IBM Content Manager.

3.2 Scenario 2: Configuring the library server to

recognize resource manager security certificates in

an environment that contains Windows

This scenario shows how to set up an IBM Content Manager library server running Windows,

using WebSphere Application Server.

Planning

Assume that you want to:

 configure the lsecm1 computer for IBM Content Manager components (specifically, the

library server) and the prerequisite software

 secure the library server’s HTTPS connection to the resource manager.

To establish the security certificates for IBM Content Manager

1 Create an empty keystore:

gsk8capicmd_64 -keydb -create -db lsecm1.p12 -pw password –stash -populate

This procedure creates the following files:

File

Description

lsecm1.p12

keystore

lsecm1.sth

password stash file

 You must protect the STH stash files by using operating system permissions, because

they contain sensitive information.

 Make sure that the passwords to the keystores are both unique and strong.

2 Add the default signer certificate from Scenario 1: Configuring the IBM Content Manager

system administration client and API on Windows to recognize resource manager security

certificates to the keystore for lsecm1:

gsk8capicmd_64 -cert -add -db lsecm1.p12 -stashed -label "RMRootCA" -file "myRMSigner.arm" -format

ascii

IBM Content Manager Configuring Transport Layer Security

3 Create a directory for the library server keystore, for example: c:\LSsecurity.

4 Copy the following files to the new directory:

lsecm1.p12

lsecm1.sth

5 In the system administration client, go to the library server configuration security tab, and

then:

 Specify the keystore and stash file.

 Select Require secure communication with resource managers.

IBM Content Manager Configuring Transport Layer Security

3.3 Scenario 3: Securing network communications in an

environment that contains Windows and Db2 for

Linux, UNIX, and Windows

This scenario shows how to set up an IBM Content Manager system on servers and clients

running Windows, and uses Db2 databases and WebSphere Application Server.

Planning

Assume that you want to configure your network computers for IBM Content Manager

components and the following software:

 Windows 2019

 64-bit JRE

 64-bit GSKit

 Db2 v11.5.8 databases

 WebSphere Application Server V9.0.5.

Updating environment variables and creating certificate directories

1 Set your PATH environment variable for GSKit, and then create directories for security

certificates.

2 Update the environment variable on the servers by setting the following path statement,

which points to the GSKit libraries.

PATH=C:\ibm\gsk8\bin;C:\ibm\gsk8\lib64;%PATH%

3 Create the c:\security64 directory on your servers to store security certificates, keystore

files, and stash files.

Setting up transport layer security for IBM Db2 for Linux, UNIX, and

Windows

This configuration uses the 64-bit version of JRE, so you must also use the 64-bit version of

GSKit:

1 Create the root key database:

C:\security64>gsk8capicmd_64 -keydb -create -db CMrootRSCA.p12 -pw passw0rd -stash -populate

2 Create a self-signed root certificate with public and private keys by running the following

command:

IBM Content Manager Configuring Transport Layer Security

C:\security64>gsk8capicmd_64 -cert -create -db CMrootRSCA.p12 -stashed -label CMrootRSCA -dn

"CN=vmcmi149.svl.ibm.com,OU=CM,O=ibm" -expire 7300 -ca true -sigalg SHA256_WITH_RSA -size 2048

Note: If you wish to create a certificate to be used for TLS 1.3 make sure the –sigalg and

–size parameters are set with values supported for TLS 1.3 like in the example above.

3 Extract the root IBM Content Manager certificate for distribution by running the following

command:

C:\security64>gsk8capicmd_64 -cert -extract -db CMrootRSCA.p12 -stashed -label CMrootRSCA -target

CMrootRSCA.arm

The following files are created in the c:\security64 directory:

CMrootRSCA.arm

CMrootRSCA.p12

CMrootRSCA.sth

4 Update the database manager configuration for the instance to use the keydb file:

C:\security64>db2 update dbm cfg using SSL_SVR_KEYDB C:\security64\CMrootRSCA.p12

The following message appears:

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

5 Update the database manager configuration for the instance to use the stash file:

C:\security64>db2 update dbm cfg using SSL_SVR_STASH C:\security64\CMrootRSCA.sth

The following message appears:

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

6 Update the database manager configuration for the instance to use a certificate label. Make

sure that your label matches the one in step 2.

C:\security64>db2 update dbm cfg using SSL_SVR_LABEL CMrootRSCA

The following message appears:

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

7 Update the database manager configuration for the SSL version (optional). Note: To specify

TLS13 the user must install a version of DB2 that supports this version.

C:\security64>db2 update dbm cfg using SSL_VERSIONS TLSV12,TLSV13

The following message appears:

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

IBM Content Manager Configuring Transport Layer Security

8 Create a new service name and specify an unused port to use for Db2 SSL connections in the

services file for each server. For example, apply the following entry under Services:

db2c_TLS 50020/tcp # SSL port

9 Update the database manager configuration for the instance with SSL service name.

C:\security64>db2 update dbm cfg using SSL_SVCENAME db2c_TLS

The following message appears:

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

10 Configure the Db2 instance to use both SSL and TCPIP as communication protocols by

running the following command:

C:\security64>db2set -i db2 DB2COMM=SSL,TCPIP

11 Stop Db2, and then restart it, by using these commands:

C:\security64>db2stop

C:\security64>db2start

Db2 now listens on two ports, one for TCPIP and one for SSL.

12 Verify that the changes have been applied by running the following command:

C:\security64>db2 get dbm cfg

The changes are shown in the configuration settings:

Max number of coordinating agents (MAX_COORDAGENTS) = AUTOMATIC(200)

Max number of client connections (MAX_CONNECTIONS) =

AUTOMATIC(MAX_COORDAGENTS)

…

TCP/IP Service name (SVCENAME) = db2c_DB2

SSL server keydb file (SSL_SVR_KEYDB) = C:\security64\CMrootRSCA.p12

SSL server stash file (SSL_SVR_STASH) = C:\security64\CMrootRSCA.sth

…

SSL server certificate label (SSL_SVR_LABEL) = CMrootRSCA

SSL service name (SSL_SVCENAME) = db2c_TLS

SSL versions (SSL_VERSIONS) = TLSV12,TLSV13

Configuring the JRE to use transport layer security

From the C:\security64 directory, run the following commands:

For JREs installed outside of IBM Content Manager

IBM Content Manager Configuring Transport Layer Security

"C:\jdk-11.0.18+10\bin\keytool" -import -v -noprompt -trustcacerts -alias CMrootRSCA -file

CMrootRSCA.arm -storepass changeit -keystore "C:\jdk-11.0.18+10\lib\security\cacerts"

The security certificate is added to this keystore:

C:\jdk-11.0.18+10\lib\security\cacerts

For the JRE installed by IBM Content Manager

"C:\IBM\db2cmv8\java\jre\bin\keytool" -import -v -noprompt -trustcacerts -alias CMrootRSCA -file

CMrootRSCA.arm -storepass changeit -keystore "C:\IBM\db2cmv8\java\jre\lib\security\cacerts"

The security certificate is added to this keystore:

C:\IBM\db2cmv8\java\jre\lib\security\cacerts

For the JRE installed with WebSphere for Content Manager resource manager and/or

WebSphere applications using the IBM Content Manager API.

"C:\WebSphere90\AppServer\java\8.0\jre\bin\keytool" -import -v -noprompt -trustcacerts -alias

CMrootRSCA -file CMrootRSCA.arm -storepass changeit -keystore

"C:\WebSphere90\AppServer\java\8.0\jre\lib\security\cacerts"

The security certificate is added to this keystore:

C:\WebSphere90\AppServer\java\8.0\jre\lib\security\cacerts

Note: If you update or upgrade IBM Content Manager, you must restore any certificates that

are in the cacerts to the IBM Content Manager Java JRE. This is because the IBM Content

Manager Java JRE is overwritten when you update or upgrade IBM Content Manager.

Adding the signer certificate

In this scenario, self-signed certificates are used so they do not have to be signed again. To add

the signer certificate, follow these steps:

1 Open the WebSphere Application Server administrative console.

2 Add the signer certificate, CMrootRSCA.arm, that was created in the NodeDefaultTrustStore.

To do this, go to SSL certificates and key management > Key stores and certificates >

NodeDefaultTrustStore > Signer certificates.

3 Add the C:\security64\CMrootRSCA.arm certificate into NodeDefaultTrustStore.

IBM Content Manager Configuring Transport Layer Security

4 Click OK.

Configuring communications between the IBM Content Manager API

and the library server

To connect to the library server Db2 database by using SSL, set the following options for the

library server you are using in the cmbicmsrvs.ini file.

ICMDBSSL=TRUE

ICMDBSSLPORT=50020

Optional:

ICMDBSSLVERSION=TLSv1.2

If you are using an Oracle database, set the following options:

ICMDBSSL=TRUE

For information about other options that can be specified for an Oracle database, see “IBM

Content Manager Java API JDBC to library server” on page 29.

Updating the data sources

Configure the resource manager data sources in WebSphere Application Server. Repeat this step

for both the library server and resource manager data sources.

1 Navigate to Resources > JDBC > Data sources, and then find the data source names that

start with the resource manager application name, for example: icmrm_database and

icmrm_LS_database.

2 For each of these data sources, complete the following steps.

Change the port to use the Db2 SSL port.

Add the sslConnection = true property to the data source custom properties.

IBM Content Manager Configuring Transport Layer Security

Add the sslVersion = TLSv1.2 property to the data source custom properties (optional).

Save the configuration.

3.4 Scenario 4: Securing network communications for

TLS 1.3 in an environment that contains Windows

and Db2 for Linux, UNIX, and Windows

This scenario shows how to set up an IBM Content Manager system on servers and clients

running Windows, and uses Db2 databases and WebSphere Application Server.

Planning

Assume that you want to configure your network computers for IBM Content Manager

components and the following software:

 Windows 2019

 64-bit JRE

 64-bit GSKit

 Db2 v11.5.8 databases (or later)

 WebSphere Application Server V9.0.5.13 and later.

 Use TLS 1.3 cipher suites for example TLS_AES_128_GCM_SHA256 and

TLS_AES_256_GCM_SHA384

Updating environment variables and creating certificate directories

3 Set your PATH environment variable for GSKit, and then create directories for security

certificates.

4 Update the environment variable on the servers by setting the following path statement,

which points to the GSKit libraries.

PATH=C:\ibm\gsk8\bin;C:\ibm\gsk8\lib64;%PATH%

5 Create the c:\security64 directory on your servers to store security certificates, keystore

files, and stash files.

Setting up transport layer security for IBM Db2 for Linux, UNIX, and

Windows

This configuration uses the 64-bit version of JRE, so you must also use the 64-bit version of

GSKit:

IBM Content Manager Configuring Transport Layer Security

6 Create the root key database:

C:\security64>gsk8capicmd_64 -keydb -create -db CMrootRSCA.p12 -pw passw0rd -stash -populate

7 Create a self-signed root certificate with public and private keys by running the following

command:

C:\security64>gsk8capicmd_64 -cert -create -db CMrootRSCA.p12 -stashed -label CMrootRSCA -dn

"CN=vmcmi149.svl.ibm.com,OU=CM,O=ibm" -expire 7300 -ca true -sigalg SHA256_WITH_RSA -size 2048

Note: If you wish to create a certificate to be used for TLS 1.3 make sure the –sigalg and

–size parameters are set with values supported for TLS 1.3 like in the example above.

8 Extract the root IBM Content Manager certificate for distribution by running the following

command:

C:\security64>gsk8capicmd_64 -cert -extract -db CMrootRSCA.p12 -stashed -label CMrootRSCA -target

CMrootRSCA.arm

The following files are created in the c:\security64 directory:

CMrootRSCA.arm

CMrootRSCA.p12

CMrootRSCA.sth

9 Update the database manager configuration for the instance to use the keydb file:

C:\security64>db2 update dbm cfg using SSL_SVR_KEYDB C:\security64\CMrootRSCA.p12

The following message appears:

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

10 Update the database manager configuration for the instance to use the stash file:

C:\security64>db2 update dbm cfg using SSL_SVR_STASH C:\security64\CMrootRSCA.sth

The following message appears:

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

11 Update the database manager configuration for the instance to use a certificate label. Make

sure that your label matches the one in step 2.

C:\security64>db2 update dbm cfg using SSL_SVR_LABEL CMrootRSCA

The following message appears:

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

IBM Content Manager Configuring Transport Layer Security

12 Update the database manager configuration for the SSL version (optional). Note: To specify

TLS13 the user must install a version of DB2 that supports this version.

C:\security64>db2 update dbm cfg using SSL_VERSIONS TLSV12,TLSV13

The following message appears:

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

13 Create a new service name and specify an unused port to use for Db2 SSL connections in the

services file for each server. For example, apply the following entry under Services:

db2c_TLS 50020/tcp # SSL port

14 Update the database manager configuration for the instance with SSL service name.

C:\security64>db2 update dbm cfg using SSL_SVCENAME db2c_TLS

The following message appears:

DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

15 Configure the Db2 instance to use both SSL and TCPIP as communication protocols by

running the following command:

C:\security64>db2set -i db2 DB2COMM=SSL,TCPIP

16 Stop Db2, and then restart it, by using these commands:

C:\security64>db2stop

C:\security64>db2start

Db2 now listens on two ports, one for TCPIP and one for SSL.

17 Verify that the changes have been applied by running the following command:

C:\security64>db2 get dbm cfg

The changes are shown in the configuration settings:

Max number of coordinating agents (MAX_COORDAGENTS) = AUTOMATIC(200)

Max number of client connections (MAX_CONNECTIONS) =

AUTOMATIC(MAX_COORDAGENTS)

…

TCP/IP Service name (SVCENAME) = db2c_DB2

SSL server keydb file (SSL_SVR_KEYDB) = C:\security64\CMrootRSCA.p12

SSL server stash file (SSL_SVR_STASH) = C:\security64\CMrootRSCA.sth

…

SSL server certificate label (SSL_SVR_LABEL) = CMrootRSCA

SSL service name (SSL_SVCENAME) = db2c_TLS

SSL versions (SSL_VERSIONS) = TLSV12,TLSV13

IBM Content Manager Configuring Transport Layer Security

Configuring the JRE to use transport layer security

From the C:\security64 directory, run the following commands:

For JREs installed outside of IBM Content Manager

"C:\jdk-11.0.18+10\bin\keytool" -import -v -noprompt -trustcacerts -alias CMrootRSCA -file

CMrootRSCA.arm -storepass changeit -keystore "C:\jdk-11.0.18+10\lib\security\cacerts"

The security certificate is added to this keystore:

C:\jdk-11.0.18+10\lib\security\cacerts

For the JRE installed by IBM Content Manager

"C:\IBM\db2cmv8\java\jre\bin\keytool" -import -v -noprompt -trustcacerts -alias CMrootRSCA -file

CMrootRSCA.arm -storepass changeit -keystore "C:\IBM\db2cmv8\java\jre\lib\security\cacerts"

The security certificate is added to this keystore:

C:\IBM\db2cmv8\java\jre\lib\security\cacerts

For the JRE installed with WebSphere for Content Manager resource manager and/or

WebSphere applications using the IBM Content Manager API.

"C:\WebSphere90\AppServer\java\8.0\jre\bin\keytool" -import -v -noprompt -trustcacerts -alias

CMrootRSCA -file CMrootRSCA.arm -storepass changeit -keystore

"C:\WebSphere90\AppServer\java\8.0\jre\lib\security\cacerts"

The security certificate is added to this keystore:

C:\WebSphere90\AppServer\java\8.0\jre\lib\security\cacerts

Note: If you update or upgrade IBM Content Manager, you must restore any certificates that

are in the cacerts to the IBM Content Manager Java JRE. This is because the IBM Content

Manager Java JRE is overwritten when you update or upgrade IBM Content Manager.

Adding the signer certificate

In this scenario, self-signed certificates are used so they do not have to be signed again. To add

the signer certificate, follow these steps:

18 Open the WebSphere Application Server administrative console.

IBM Content Manager Configuring Transport Layer Security

19 Add the signer certificate, CMrootRSCA.arm, that was created in the NodeDefaultTrustStore.

To do this, go to SSL certificates and key management > Key stores and certificates >

NodeDefaultTrustStore > Signer certificates.

20 Add the C:\security64\CMrootRSCA.arm certificate into NodeDefaultTrustStore.

21 Click OK.

Set WAS Quality of protection (QoP) settings for TLSv1.3

22 Set WAS QoP settings for both TLSv1.3 & TLSv1.2.

IBM Content Manager Configuring Transport Layer Security

Note: This step is also needed for applications that use the CM API from a WAS application.

Configuring communications between the IBM Content Manager API

and the library server

To connect to the library server Db2 database by using SSL, set the following options for the

library server you are using in the cmbicmsrvs.ini file.

ICMDBSSL=TRUE

ICMDBSSLPORT=50020

ICMDBSSLVERSION=TLSv1.3

Examples of cmbicmsrvs.ini setup for TLSv1.3

cmbicmsrvs.ini example specifying TLS 1.3 for DB2 and RM SSL

ICMSERVER=icmnlsdb1

ICMSERVERREPTYPE=DB2

ICMSCHEMA=ICMADMIN

ICMSSO=FALSE

ICMDBAUTH=SERVER

ICMREMOTE=FALSE

IBM Content Manager Configuring Transport Layer Security

ICMHOSTNAME=mufasa.com

ICMPORT=50000

ICMREMOTEDB=icmnlsdb1

ICMNODENAME=

ICMOSTYPE=

ICMJDBCDRIVER=

ICMJDBCURL=

ICMJNDIREF=

ICMDBVER=

ICMGMTSYSATTRTS=FALSE

ICMGMTDOCROUTINGATTRTS=FALSE

ICMRMCOMMTYPE=HTTPS_ONLY

ICMRMSSLTRUSTSTORE=

ICMRMSSLTRUSTSTORETYPE=

ICMRMSSLTRUSTSTOREPROVIDERNAME=

ICMRMSSLTRUSTMGRALGORITHM=

ICMRMSSLTRUSTMGRPROVIDERNAME=

ICMRMSSLKEYSTORE=

ICMRMSSLKEYSTORETYPE=

ICMRMSSLKEYSTOREPROVIDERNAME=

ICMRMSSLKEYMGRALGORITHM=

ICMRMSSLKEYMGRPROVIDERNAME=

ICMRMSSLPROTOCOLMINTLS12=

ICMRMSSLCIPHERSUITEFILTERING=TRUE

ICMRMSSLCERTIFICATEAUTH=TRUE

ICMRMSSLCBCPROTECTION=TRUE

ICMRMSSLCONTEXTPROTOCOL=TLSv1.3

ICMRMSSLRNGALGORITHM=

ICMRMSSLCIPHERSUITES=TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384

IBM Content Manager Configuring Transport Layer Security

ICMRMSSLALLOWABLEPROTOCOLS=TLSv1.3

ICMRMUSESSLFORURLBASEDRETRIEVES=

ICMRMCONNTIMEOUT=

ICMRMCONNPOLLINTERVAL=

ICMRMCONNREADTIMEOUT=

ICMDBSSL=TRUE

ICMDBSSLPORT=50020

ICMDBSSLTRUSTSTORE=

ICMDBSSLTRUSTSTORETYPE=

ICMDBSSLKEYSTORE=

ICMDBSSLKEYSTORETYPE=

ICMDBSSLVERSION=TLSv1.3

ICMDBSSLCIPHERSUITES=

ICMDBSSLDISTINGUISHEDNAMEMATCH=FALSE

cmbicmsrvs.ini example specifying TLS 1.3 for DB2 and min TLS 1.2 or higher RM SSL option

(This will work if WAS is setup for TLS1.3)

ICMSERVER=icmnlsdb2

ICMSERVERREPTYPE=DB2

ICMSCHEMA=ICMADMIN

ICMSSO=FALSE

ICMDBAUTH=SERVER

ICMREMOTE=FALSE

ICMHOSTNAME=simba.com

ICMPORT=50000

ICMREMOTEDB=icmnlsdb2

ICMNODENAME=

IBM Content Manager Configuring Transport Layer Security

ICMOSTYPE=

ICMJDBCDRIVER=

ICMJDBCURL=

ICMJNDIREF=

ICMDBVER=

ICMGMTSYSATTRTS=FALSE

ICMGMTDOCROUTINGATTRTS=FALSE

ICMRMCOMMTYPE=HTTPS_ONLY

#ICMRMCOMMTYPE=HTTPS_AVAILABLE

ICMRMSSLTRUSTSTORE=

ICMRMSSLTRUSTSTORETYPE=

ICMRMSSLTRUSTSTOREPROVIDERNAME=

ICMRMSSLTRUSTMGRALGORITHM=

ICMRMSSLTRUSTMGRPROVIDERNAME=

ICMRMSSLKEYSTORE=

ICMRMSSLKEYSTORETYPE=

ICMRMSSLKEYSTOREPROVIDERNAME=

ICMRMSSLKEYMGRALGORITHM=

ICMRMSSLKEYMGRPROVIDERNAME=

ICMRMSSLPROTOCOLMINTLS12=TRUE

ICMRMSSLCIPHERSUITEFILTERING=TRUE

ICMRMSSLCERTIFICATEAUTH=TRUE

ICMRMSSLCBCPROTECTION=TRUE

ICMRMSSLCONTEXTPROTOCOL=

ICMRMSSLRNGALGORITHM=

ICMRMSSLCIPHERSUITES=

ICMRMSSLALLOWABLEPROTOCOLS=

ICMRMUSESSLFORURLBASEDRETRIEVES=

ICMRMCONNTIMEOUT=

IBM Content Manager Configuring Transport Layer Security

ICMRMCONNPOLLINTERVAL=

ICMRMCONNREADTIMEOUT=

ICMDBSSL=TRUE

ICMDBSSLPORT=50020

ICMDBSSLTRUSTSTORE=

ICMDBSSLTRUSTSTORETYPE=

ICMDBSSLKEYSTORE=

ICMDBSSLKEYSTORETYPE=

ICMDBSSLVERSION=TLSv1.3

ICMDBSSLCIPHERSUITES=

ICMDBSSLDISTINGUISHEDNAMEMATCH=FALSE

Updating the data sources

Configure the resource manager data sources in WebSphere Application Server. Repeat this step

for both the library server and resource manager data sources.

23 Navigate to Resources > JDBC > Data sources, and then find the data source names that

start with the resource manager application name, for example: icmrm_database and

icmrm_LS_database.

24 For each of these data sources, complete the following steps.

Change the port to use the Db2 SSL port.

IBM Content Manager Configuring Transport Layer Security

Add the sslConnection = true property to the data source custom properties.

Add the sslVersion = TLSv1.3 property to the data source custom properties.

Save the configuration.

IBM Content Manager Configuring Transport Layer Security

3.5 Scenario 5: Securing network communications in a

Db2 z/OS database and z/OS resource manager

environment

Assume that you want to set up transport layer security for an IBM Content Manager system that

is running in a Db2 for z/OS database environment. You must set up z/OS AT TLS, create and

export the associated security certificates, and then configure the Db2 database environment.

Setting up z/OS AT-TLS

In an IBM z/OS environment, you must enable TTLS in the TCP/IP Communication Server,

which you can do either by modifying the PROFILE.TCPIP dataset or issuing direct commands.

To enable TTLS in TCP/IP Communication Server by using the PROFILE.TCPIP dataset

25 Access the PROFILE.TCPIP dataset (‘SYS1.TCPPARMS(your_member_name)’).

26 Add the TCPCONFIG TTLS parameter.

To enable TTLS without changing the PROFILE.TCPIP dataset

27 Create member TTLSON in the SYS1.TCPPARMS dataset.

28 Make sure the TTLSON dataset contains the following line:

TCPCONFIG TTLS

29 On the MVS console, issue:

VARY TCPIP,,O,DSN=SYS1.TCPPARMS(TTLSON)

To disable TTLS without modifying the PROFILE.TCPIP dataset

30 Create member TTLSON in the SYS1.TCPPARMS dataset.

31 Make sure that the TTLSON dataset contains the following line:

TCPCONFIG NOTTLS

32 On the MVS console, issue:

VARY TCPIP,,O,DSN=SYS1.TCPPARMS(TTLSOFF)

Setting up PAGENT

Setting up PAGENT entails configuring the PAGENT JCL and associated configuration files.

Configuring PAGENT JCL

Ensure that PAGENT JCL has the following settings:

//PAGENT PROC

IBM Content Manager Configuring Transport Layer Security

//*

//* IBM Communications Server for z/OS

//* SMP/E distribution name: EZAPAGSP

//* Licensed Materials - Property of IBM

//* "Restricted Materials of IBM"

//* Status = CSV1R9

//*

//PAGENT EXEC PGM=PAGENT,REGION=0K,TIME=NOLIMIT,

// PARM='ENVAR("_CEE_ENVFILE=/etc/pagent.env")/ˉ

//SYSPRINT DD SYSOUT=*

//*SYSLOGD DD SYSOUT=*

//SYSOUT DD SYSOUT=*

//CEEDUMP DD SYSOUT=*,DCB=(RECFM=FB,LRECL=132,BLKSIZE=132)

Configuring PAGENT Configuration Files

Set up the following configuration files to contain the noted parameters and values.

# cat /etc/pagent.env

TZ=PST8PDT7

PAGENT_CONFIG_FILE=/etc/pagent.conf

PAGENT_LOG_FILE=/tmp/pagent.log

# cat /etc/pagent.conf

TcpImage TCPIP FLUSH PURGE

TTLSConfig /etc/TTLS.conf FLUSH PURGE

# cat /etc/TTLS.conf

TTLSRule DB1GSecureServer

{

LocalPortRange 8150

JobName DB1GDIST

Direction Inbound

TTLSGroupActionRef DB1GSecureGrpAct

TTLSEnvironmentActionRef DB1GSecureEnvAct

}

TTLSGroupAction DB1GSecureGrpAct

{

TTLSEnabled On

Trace 15

}

TTLSEnvironmentAction DB1GSecureEnvAct

{

IBM Content Manager Configuring Transport Layer Security

TTLSKeyRingParms

{

Keyring DB1GKEYRING

}

HandShakeRole Server

TTLSEnvironmentAdvancedParms DB1GEnvAdvParms

{

TLSv1.3 On

TLSv1.2 On

TLSv1.1 Off

TLSv1 Off

SSLv3 Off

SSLv2 Off

}

TTLSCipherParms DB21GCipherParms

{

# TLSv1.2: ECDSA or RSA peer auth with ephemeral DH, AES-GCM, and SHA-2

V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

V3CipherSuites TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

V3CipherSuites TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

V3CipherSuites TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

# TLSv1.3: Ephemeral DH, AES-GCM, or ChaCha-Poly1305 and SHA-2

V3CipherSuites TLS_AES_256_GCM_SHA384

V3CipherSuites TLS_AES_128_GCM_SHA256

V3CipherSuites TLS_CHACHA20_POLY1305_SHA256

}

TTLSSignatureParms DB21GSigParms

{

# Allow digital signatures with hashes of 256 bits or more

SignaturePairs TLS_SIGALG_SHA512_WITH_RSASSA_PSS

SignaturePairs TLS_SIGALG_SHA512_WITH_ECDSA

SignaturePairs TLS_SIGALG_SHA512_WITH_RSA

SignaturePairs TLS_SIGALG_SHA384_WITH_RSASSA_PSS

SignaturePairs TLS_SIGALG_SHA384_WITH_ECDSA

SignaturePairs TLS_SIGALG_SHA384_WITH_RSA

SignaturePairs TLS_SIGALG_SHA256_WITH_RSASSA_PSS

SignaturePairs TLS_SIGALG_SHA256_WITH_ECDSA

SignaturePairs TLS_SIGALG_SHA256_WITH_RSA

}

IBM Content Manager Configuring Transport Layer Security

}

Checking PAGENT Status

To check the configured status of PAGENT, use the pasearch –t command, for example:

# pasearch -t

TCP/IP pasearch CS V1R10 Image Name: TCPIP

Date: 03/27/2011 Time: 18:42:36

TTLS Instance Id: 1299479967

policyRule: DB1GSecureServer

Rule Type: TTLS

Version: 3 Status: Active

Weight: 1ForLoadDist: False

Priority: 1 Sequence Actions: Don't Care

No. Policy Action: 2

policyAction: DB1GSecureGrpAct

ActionType: TTLS Group Action Sequence: 0

policyAction: DB1GSecureEnvAct

ActionType: TTLS Environment

Action Sequence: 0

LocalPortFrom: 8150 LocalPortTo: 8150 RemotePortFrom: 0 RemotePortTo: 0 JobName: DB1GDIST

UserId:

ServiceDirection: Inbound

HandshakeRole: Server

TTLSKeyringParms:

Keyring: DB1GKEYRING

IBM Content Manager Configuring Transport Layer Security

Creating a digital certificate in RACF

Use the following sample steps to create a digital certificate in RACF, replacing IBM, SVL,

STLAB49, and other variables with your own entries:

33 Give the sample DB1BDIST started task user ID sufficient authority to use RACDCERT

command:

//RACDCERT EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=*

//SYSUADS DD DSN=SYS1.UADS,DISP=SHR

//SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR

//SYSTSIN DD *

SETROPTS CLASSACT(DIGTCERT DIGTRING)

RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)

RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)

PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(DB2PROD) ACCESS(CONTROL)

PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(DB2PROD) ACCESS(READ)

SETR RACLIST (DIGTRING) REFRESH SETR RACLIST (DIGTCERT) REFRESH

SETR RACLIST (FACILITY) REFRESH

34 Generate a Certificate-authority (CA) certificate:

RACDCERT CERTAUTH -

GENCERT -

SUBJECTSDN(OU('STLAB49 Server CA') -

O('IBM') L('SVL') SP('CA') C('USA')) -

NOTAFTER(DATE(2030-12-31)) -

WITHLABEL('STLAB49 Server CA') -

KEYUSAGE(CERTSIGN)

35 Generate a site certificate:

RACDCERT ID(SYSDSP) -

GENCERT -

SUBJECTSDN(CN('stlab49.svl.ibm.com') -

OU('STLAB49') O('STLAB49') C('USA')) -

NOTAFTER(DATE(2030-12-31)) -

WITHLABEL(STLAB49 Server Certificate') -

SIGNWITH(CERTAUTH LABEL(STLAB49 Server CA'))

Create the DB1BKEYRING and store the digital certificate:

RACDCERT ID(DB2PROD) ADDRING(DB1BKEYRING)

RACDCERT ID(DB2PROD) CONNECT(CERTAUTH LABEL(' STLAB49 Server CA')

RING(DB1BKEYRING))

RACDCERT ID(DB2PROD) CONNECT(ID(DB2PROD) LABEL(' STLAB49 Server Certificate') - RING(DB1BKEYRING)

DEFAULT)

IBM Content Manager Configuring Transport Layer Security

36 Export the CA certificate file, which is to be used by the client systems:

RACDCERT CERTAUTH EXPORT(LABEL('STLAB49 Server CA')) -

DSN('USRT001.STLAB49.CACERT')

37 Check the status of the KEYRING:

PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(taoy) ACCESS(CONTROL)

PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(taoy) ACCESS(CONTROL)

SETR RACLIST (FACILITY) REFRESH

RACDCERT LISTRING(*) ID(db2prod) Digital ring information for user DB2PROD:

Ring:

>DB1BKEYRING<

Certificate Label Name Cert Owner USAGE DEFAULT

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

SVL224 Server CA CERTAUTH CERTAUTH NO

SVL224 Server Certificate ID(DB2PROD) PERSONAL YES

Setting up the Db2 Server

The next step is to configure Db2 under z/OS to support transport layer security:

38 Set up Db2 SECURE PORT from the DSNTIP5 panel. For this example, set:

SECURE PORT=8150

39 Restart the Db2 subsystem.

Now the Db2 subsystem listens on the configured SSL port.

Setting up a Key file database in z/OS with a self-signed certificate

After you configure the SSL port to establish transport layer security in Db2, you must set up a

key file database in z/OS. For this example, assume the Key file database file is

/etc/key.kdb.

40 To set up the key file database, in a z/OS UNIX System Services shell (for example, TSO

OMVS), run the gskkyman program.

41 Select option 1, Create new database.

42 For the key database name, specify /etc/key.kdb.

43 Enter a password, and then verify it.

44 Accept all the other default settings.

45 For FIPS, select 0.

This message appears:

IBM Content Manager Configuring Transport Layer Security

Key database /etc/key.kdb created.

46 Select option 10, Store database password.

This message appears:

Database password stored in /etc/key.sth.

47 Select option 6, Create a self-signed certificate.

48 Select option 5, User or server certificate with 2048-bit RSA key. Otherwise, select option 6

or 7 for higher levels of encryption.

49 Select option 3, SHA-256.

50 Enter a label, for example, Cert for IBM RM on z/OS.

51 Enter a common name or domain, for example, icmweb.raleigh.ibm.com.

52 Enter appropriate answers for the rest of the questions.

This message appears:

Certificate created.

53 Select option 1, Manage keys and certificates, and then select the certificate number you just

created.

54 Select option 3, Set key as default, and then look for this message: Default key set.

55 Select option 6, Export certificate to a file. For this option, select 2, Base64 ASN.1 DER, and

input a file name for it.

You now have these files: /etc/key.kdb and /etc/key.sth. Use these values in both the

KeyFile directive of the IBM HTTP Server httpd.conf file, and in the KEYFILE option.

Confirming resource manager HTTP servers use secure transport

Change the resource manager’s http.conf file to configure the SSL option. For more

information, see the IBM HTTP Server configuration documentation Securing with SSL

communications.

Configuring resource manager on z/OS

After you configure the resource manager HTTP servers to use security transport, you can

configure the resource manager itself on z/OS.

To configure resource manager on z/OS:

Use the IBM Content Manager system administration client to update the protocol to use https

and an SSL port (443 in this example scenario).

IBM Content Manager Configuring Transport Layer Security

Confirm that each resource manager HTTP server now uses transport layer security for

communication.

IBM Content Manager Java API on z/OS USS communicating to library

server on z/OS

Settings of the cmbicmsrvs.ini is same as settings on unix platforms see “IBM Content Manager

Java API JDBC to library server” on page 28 for more information.

IBM Content Manager Java API on z/OS USS communicating to

resource manager on z/OS

Settings of the cmbicmsrvs.ini is same as settings on unix platforms see ”IBM Content Manager

Java API to the resource manager” on page 25 for more information.

3.6 Scenario 6: Securing network communications for

REST or Web Services

This scenario shows how to set up an IBM Content Manager REST or Web Services to

communicate with IBM Content Manager servers securely and provide secure communications

to access their services.

Planning

Assume that you want to configure REST or Web Services running in the following

environment:

 Windows 2019

 REST or Web Service install on WebSphere Application Server V9.0.5.13 or later, but not

configured for TLS.

 CM Library Server already configured for TLS and using Db2 v11.5.8 databases (or later)

 CM Resource Manager already configured for TLS on WebSphere Application Server

V9.0.5.13 (or later)

Configuring communications to the library server

To configured REST or Web Services to communicate with CM servers securely, you need to

configure the CM API that is used by these services. The INI files that configure the API may

be found in the WebSphere Application Server deployment directory. In this case, the files

may be found in the follow directory:

C:\IBM\WebSphere\AppServer\profiles\AppSrv02\installedApps\utp02-cm8tx-w01Node02Cell\cmwebsvc.e

ar\cmgmt\connectors

IBM Content Manager Configuring Transport Layer Security

To connect to the library server Db2 database by using SSL, set the following options for the

library server you are using in the cmbicmsrvs.ini file.

ICMDBSSL=TRUE

ICMDBSSLPORT=50020

ICMDBSSLVERSION=TLSv1.3, TLSv1.2

This example specifies that either TLS 1.2 or 1.3 will be used.

NOTE: If the Content Manager Configuration is used to upgrade or reconfigure REST or Web

Services, all changes to the API INI files will be overwritten. These files should be backed up

so that they can be restored after an upgrade or reconfiguration.

Import the certificate used to access the database into the JVM that is used by WebSphere

Applications server. This can be done with the following command, assuming the certificate is

contained in the file C:\certs\CMserverRR.arm:

SET CERT_FILE=C:\certs\CMserverRR.arm

SET CERT_ALIAS=utp02-cm8tx-w01.development.unicom.software

SET CERT_JAVA=C:\ibm\WebSphere\AppServer\java\8.0\jre

keytool -import -v -noprompt -trustcacerts -alias %CERT_ALIAS% -file %CERT_FILE% -storepass changeit

-keystore %CERT_JAVA%\lib\security\cacerts

Import the certificate used by the database into WebSphere. In this scenario, self-signed

certificates are used so they do not have to be signed again. To add the signer certificate, follow

these steps:

1. Open the WebSphere Application Server administrative console.

2. Add the signer certificate, CMserverRR.arm, into the NodeDefaultTrustStore. To do

this, go to SSL certificates and key management > Key stores and certificates >

NodeDefaultTrustStore > Signer certificates.

3. Add the C:\certs\CMserverRR.arm certificate into NodeDefaultTrustStore.

IBM Content Manager Configuring Transport Layer Security

4. Click OK.

If JDBC pooling is to be used to talk to the library server as described here: Connection pooling

for the traditional WebSphere Application Server, you must make sure to update the data source

used for pooling to use the secure port of the database.

Configuring communications to the resource manger

To configured REST or Web Services to communicate with CM servers securely, you need to

configure the CM API that is used by these services. The INI files that configure the API may

be found in the WebSphere Application Server deployment directory. In this case, the files

may be found in the follow directory:

IBM Content Manager Configuring Transport Layer Security

C:\IBM\WebSphere\AppServer\profiles\AppSrv02\installedApps\utp02-cm8tx-w01Node02Cell\cmwebsvc.e

ar\cmgmt\connectors

To connect to the resource manager using SSL, set the following options for the resource

manager you are using in the cmbicmsrvs.ini file.

ICMRMCOMMTYPE=HTTPS_ONLY

ICMRMSSLCIPHERSUITEFILTERING=TRUE

ICMRMSSLCERTIFICATEAUTH=TRUE

ICMRMSSLCBCPROTECTION=TRUE

ICMRMSSLCONTEXTPROTOCOL=TLSv1.3

ICMRMSSLRNGALGORITHM=

ICMRMSSLCIPHERSUITES=TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384

ICMRMSSLALLOWABLEPROTOCOLS=TLSv1.3

In this case, the communication to the RM will use TLS 1.3.

If the resource manager uses a separate certificate from what is used by the library server, you

must also import this certificate into the WebSphere application server used to run REST or Web

Services.

If TLS 1.3 is used, you must set the Quality of protection (QoP) protocols in WebSphere

application server to include TLS 1.3.

Configuring communications to REST or Web Services

When REST or Web Services is deployed to WebSphere Application server by the CM

configuration manager, both a TLS and a non-TLS port are configured for access. For example,

IBM Content Manager Configuring Transport Layer Security

the non-secure port might be 9081 and the secure port 9444. This will accept HTTPS requests by

default. By default this will have a self-signed certificate.

To allow communications to REST or Web Services to use TLS 1.3, you must set the Quality of

protection (QoP) protocols in WebSphere application server to include TLS 1.3.

Limiting REST or Web Services to only TLS

To limit REST or Web services to only TLS, you must disable the HTTP port associated with

the application. To do this, go into the WebSphere Application Server console and go to

Virtual Hosts->default host ->Host Aliases. Here select the insecure port (9081) and click

delete.

IBM Content Manager Configuring Transport Layer Security

Note: Each time REST or Web Services is reconfigured or upgraded by CM, the insecure port

may be added back into the application. You may need to remove this again after running

configuration.

Configuring your applications to access REST or Web Services via TLS

Now that REST or Web Services is configured for TLS, your applications may access them via

the secure port (9444). To do this, you must import the certificate from the REST or Web

Services server into the Java that is being used to run your application.

IBM Content Manager Configuring Transport Layer Security

4 Key and certificate tools and examples

To manage security keys, keystores, and certificates you can use the GSKit command-line

interface; the keytool.exe utility; and the z/OS gskkyman program.

4.1 Using the GSKit gsk8capicmd_64.exe command in

64-bit environments

To create a root certificate and keystore and a signed server certificate in a keystore for use in a

library server and resource manager Db2 database, follow these steps. GSKit is also used when

configuring a library server security files for library server TLS communication to resource

manager. Once the keystore is created for the library server security files add the certificate from

the associated resource manager.

1 Create a new keystore with a stash file by typing the following command:

gsk8capicmd_64 -keydb -create -db CMrootRSCA.p12 -pw password –stash -populate

This command does not populate the keystore with the default signer certificates. It creates

the following files:

CMrootRSCA.p12

CMrootRSCA.sth

2 Create a self-signed root certificate, with public and private keys:

gsk8capicmd_64 -cert -create -db CMrootRSCA.p12 -stashed -label CMrootRSCA -dn

"CN=myco.com,OU=IT,O=MYCO" -expire 7300 -ca true -sigalg SHA256_WITH_RSA -size 2048

3 Extract the root IBM Content Manager certificate for distribution by running the following

command:

gsk8capicmd_64 -cert -extract -db CMrootRSCA.p12 -stashed -label CMrootRSCA -target CMrootRSCA.arm

4.2 Using the keytool.exe tool to import certificates in

java cacerts keystore

To add a signed server certificate to java cacerts keystore (JKS), follow these steps.

These steps use the example root certificate that is described in “Using the GSKit

gsk8capicmd_64.exe command in 64-bit environments” on page 60. The keystore tool would be

IBM Content Manager Configuring Transport Layer Security

used add certificates from library server databases and from resource managers to java cacerts

that are used for the CM API and system administration.

1 Import a self-signed certificate into java cacerts keystore by typing the following command

for JRE installed by Content Manager:

keytool -import -v –noprompt –trustcacerts -alias CMrootRSCA -file CMrootRSCA.arm –storepass

changeit –keystore "C:\IBM\db2cmv8\java\jre\lib\security\cacerts"

2 Import a self-signed certificate into java cacerts keystore by typing the following command

for JRE installed outside of Content Manager:

keytool -import -v –noprompt –trustcacerts -alias CMrootRSCA -file CMrootRSCA.arm –storepass

changeit –keystore "C:\jdk-11.0.18+10\lib\security\cacerts"

3 Import a self-signed certificate into java cacerts keystore by typing the following command

for JRE installed by WebSphere:

keytool -import -v –noprompt –trustcacerts -alias CMrootRSCA -file CMrootRSCA.arm –storepass

changeit –keystore "C:\WebSphere90\AppServer\java\8.0\jre\lib\security\cacerts"

4.3 Using the gskkyman program to manage security

keys and certificates in a z/OS environment for

resource manager

On z/OS, z/OS Security Server RACF, gskkyman and z/OS Cryptographic Services PKI

Services are used to create and manage digital certificates and their related key. We used the

z/OS shell-based program gskkyman as an example to manage private keys, certificates and

tokens in an IBM Content Manager z/OS environment.

For more information, see z/OS documentation on certificate and key management.