4. ■ Secure Sockets Layer (SSL) is the standard technology for creating encrypted sessions between servers
and clients. Using SSL you can ensure that your data is encrypted during communication.
■ Transport Layer Security (TLS) is the successor protocol to SSL. It works in much the same way as the
SSL, using encryption to protect the transfer of data and information. We can say TLS is an improved
version of SSL.
■ IBM Global Security Kit (GSKit) is a common component that is used by a number of IBM products. It is a
set of command-line tools that provides SSL implementation.
What is SSL?
4
5. Spectrum Protect servers
Spectrum Protect clients
Spectrum Protect storage agent
Spectrum Protect Operation center
LDAP server
5
Secure Communication
6. Types of Certificates
6
■ Self Signed SSL
A self-signed certificate consists of a public/private key pair and a certificate for the public key that is signed
by the private key. It is also known as a "root" certificate because it can be used to create a Certificate
Authority.
■ Third-party Certificate Authority (CA)
Instead of setting up its own certificate authority, a company may use a third-party certificate authority to
sign its server certificates. The client and server must have access to the third-party CA's root certificate to
verify the server certificates that are signed by the third-party CA.
7. 7
Cert.arm and cert256.arm
■ IBM Spectrum Protect server generates its own certificate. The certificate has a fixed file name of either
cert.arm or cert256.arm.
■ Use the ‘cert.arm’ certificate file when the server is not setup to use Transport Layer Security (TLS) 1.2;
otherwise, use the cert256.arm file.
■ Default Label in the TSM key database (cert.kdb) are shown below:
cert.arm ---------"TSM Server SelfSigned Key“
cert256.arm-----"TSM Server SelfSigned SHA Key“
For standard installation these files can be found in below directory:
For example:
Unix: /home/tsminst1/tsminst1
Windows: c:program filesTivoliTSMserver1
8. 8
Server key database files
■ Certificates are placed into the trust store automatically with an identifiable label.
Server: cert.kdb
Admin/client: dsmcert.kdb
OC: gui-truststore.jkm
Spectrum Protect server cert files:
The cert.* files in the server instance directory contain the server’s private key and certificate.
# ls -lr | grep cert
-rw------- 1 tsminst1 tsmsrvrs 193 Dec 9 17:13 cert.sth
-rw------- 1 tsminst1 tsmsrvrs 80 Dec 9 17:13 cert.rdb
-rw------- 1 tsminst1 tsmsrvrs 5080 Dec 9 17:13 cert.kdb
-rw------- 1 tsminst1 tsmsrvrs 80 Dec 9 17:13 cert.crl
-rw-r--r-- 1 tsminst1 tsmsrvrs 1257 Dec 9 17:13 cert256.arm
9. 9
Client key database files
■ Spectrum Protect client/API dsmcert files:
dsmcert.kdb – Keystore containing the server’s public certificate
dsmcert.sth – Stash file that contains the dsmcert.kdb file’s password
dsmcert.idx – Index file - maps the server’s ip to the certificate label in the .kdb
Files stored in the bin directory of the client installation (varies by platform/component)
■ API
Windows – C:Program FilesCommon FilesTivoliTSMapi64
Linux - /opt/tivoli/tsm/client/api/bin64
AIX - /usr/tivoli/tsm/client/api/bin64
■ B/A client
Windows – C:Program FilesTivoliTSMbaclient
Linux - /opt/tivoli/tsm/client/ba/bin
AIX - /usr/tivoli/tsm/client/ba/bin64
10. 10
GSKIT levels
■ GSKit Version can be identified:
Windows:
C:Program FilesIBMgsk8bin
gsk8capicmd_64 ==> properties
regedit /e gskitinfo.txt "HKEY_LOCAL_MACHINEsoftwareibmgsk8" notepad gskitinfo.txt
UNIX:
/usr/opt/ibm/gsk8_64/bin/gsk8ver_64
■ 7.1.8 / 8.1.2 / 8.1.4 upgrades GSKIT to level 8.0.50.78
Previous level was 8.0.50.66
Level shipped with DB2 11.1 is 8.0.50.57
7.1.8 upgrades GSKit to level 8.0.50.78
7.1.8.2 upgrades GSKit to level 8.0.50.86
8.1.2 upgrades GSKit to level 8.0.50.78
8.1.5 upgrades GSKit to level 8.0.50.86
12. 12
Security Enhancements starting with version 7.1.8+ /8.1.2+
■ Starting from IBM Spectrum Protect 7.1.8/8.1.2 server are by default configured for SSL and TLS 1.2.
Previously, SSL was optional, certificates manually installed and server must be restarted.
■ From 7.1.8/8.1.2+, Improved security protocol encrypts all communication between Server, Admin, OC,
Clients and Storage agents.
■ Certificates are automatically exchanged.
At session start, server checks for copy of certificate in the server's data base.
Certificate are communicated via server-server SSL and protected via password.
Certificates are placed into the trust store automatically with an identifiable label.
Certificates can also be manually exchanged.
■ Certificates are placed into the trust store automatically with an identifiable label.
Server: cert.kdb
Admin/client: dsmcert.kdb
OC: gui-truststore.jkm
13. 13
Security Enhancements starting with version 7.1.8+ /8.1.2+
■ A new SESSIONSECURITY parameter determines whether an administrator, node, or server must
use the most secure settings to communicate with an IBM Spectrum Protect server.
STRICT: Enforces all session security features the server is capable of enforcing at the given level
(currently TLS 1.2)
TRANSITIONAL: TLS 1.2 is not enforced. Intended to be used temporarily while updating clients, servers,
OC, admins … for strict compliance.
Commands used to set the SESSIONSECURITY parameter:
REGISTER NODE, REGISTER ADMIN, DEFINE SERVER, UPDATE NODE, UPDATE ADMIN, and
UPDATE SERVER
■ Increases encryption strength to 256-bit AES encryption (AES256) for stored node and admin
passwords.
■ The IBM Global Security Kit (GSKit) keystores are used to store all IBM Spectrum Protect passwords.
14. 14
Security Enhancements starting with version 8.1.3+ /8.1.4+
■ In V8.1.2, storage agents had to be manually configured to use SSL. Beginning in V8.1.3, storage agents
are automatically configured to use SSL.
■ Default minimum password length has been changed from zero to eight.
After you upgrade an IBM Spectrum Protect server to Version 8.1.4, the default minimum length for server
passwords changes from 0 to 8 characters.
■ To specify a different minimum password length, use the SET MINPWLENGTH command.
Note: This change in the default password length does not apply to node and administrator
passwords that are managed by a Lightweight Directory Access Protocol (LDAP) server.
16. 16
Configure the server to accept SSL
1) Beginning with IBM Spectrum Protect 7.1.8 and 8.1.2, the SSL is enabled automatically. Normally, there
is no additional steps required.
2) Verify the default label of key.
# gsk8capicmd_64 -cert -list -db cert.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
*- "TSM Server SelfSigned SHA Key"
3) If the default key is not “TSM Server SelfSigned SHA Key”, please run below command to set default:
gsk8capicmd_64 -cert -setdefault -db cert.kdb -stashed -label "TSM Server SelfSigned SHA Key“
17. 17
Configure the server to accept SSL contd..
4) Verify the selfsigned certificate by running below command:
# gsk8capicmd_64 -cert -list -db cert.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
*- "TSM Server SelfSigned SHA Key"
5) Restart Spectrum Protect server and verify the selfsigned certificate as shown below:
ANR2741I Alter monitor has started
ANR3339I Default Label in key data base is TSM Server SelfSigned SHA key.
ANR4726I The NAS-NDMP support module has been loaded.
18. 18
Configure the client and server with SSL
Beginning with IBM Spectrum Protect v7.1.8 and 8.1.2, the SSL enabled automatically. There is no additional
action needed.
Manual steps to configure IBM Spectrum Protect client and server with SSL.
1) Obtain the IBM Spectrum Protect server self-signed certificate (cert256.arm). Use the cert.arm certificate
file when the server is not setup to use Transport Layer Security (TLS) 1.2; otherwise, use the
cert256.arm file.
2) For standard installation the certificate 'cert256.arm' file can be stored in the below directory.
Unix: /home/tsminst1/tsminst1/cert256.arm
Windows: C:Program Filestivolitsmserver1cert256.arm.
19. 19
Configure the client and server with SSL contd..
3) Add the cert256.arm file into the client key database by using dsmcert utility
dsmcert -add -server <servername> -file <path_to_cert256.arm>
# dsmcert -add -server SERVER1 -file /home/tsminst1/tsminst1/cert256.arm
IBM Spectrum Protect
dsmcert utility
dsmcert Version 8, Release 1, Level 4.0
dsmcert date/time: 03/18/2019 19:18:03
(c) Copyright by IBM Corporation and other(s) 1990, 2017. All Rights Reserved.
Result: Success
4) After importing verify the key in dsmcert.kdb with following command:
# gsk8capicmd_64 -cert -list -db dsmcert.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! 127.0.0.1:1500
! "TSM server self-signed key"
! "TSM server SERVER1 self-signed key"
20. 20
Configure the client and server with SSL contd..
5) Verify the node session secruity option
Protect: SERVER1>q node LINUXTEST f=d
Node Name: LINUXTEST
Platform: Linux x86-64
Client OS Level: 3.10.0-229.el7.x86_
Client Version: Version 8, release 1, level 4.0
Application Version: Version 0, release 0, level 0.0
Policy Domain Name: AFSDOM
Last Access Date/Time: 03/18/2019 19:14:51
Last Communication Method Used: SSL
Bytes Received Last Session: 3,896
Bytes Sent Last Session: 2,684
Client Target Version: (?)
Authentication: Local
SSL Required: Default
Session Security: Strict
Transport Method: SSLTLS12
21. 21
Configure the server to connect to another server using SSL
If both servers are using IBM Spectrum Protect V8.1.2 or later software, SSL is automatically configured
between the servers and manual configuration is not required.
1) To exchange the certificates automatically first define the server - server definitions on the both severs
using below commands:
SET SERVERHLA
SET SERVERLLA
SET SERVERPASSWORD
SET CROSSDEFINE ON
2) Then run define server command on both the server with crossdefine=ON parameter.
DEFINE SERVER xxx CROSSDEFINE=YES SSL=YES allows for bi-directional exchange
22. 22
Configure the server to connect to another server using SSL contd..
Note: If either server is using IBM Spectrum Protect software earlier than V8.1.2 or Tivoli Storage Manager
software earlier than V7.1.8, you must manually configure SSL.
1) Create the server key database by starting the server. The server key database file, cert.kdb, is stored in the server
instance directory. Note: ‘TSM812’ and ‘TSM813’ are two different Spectrum Protect servers.
2) Copy the 'cert256.arm' file for both server ‘TSM812’ to ‘TSM813’ and vice versa. Also ensure you copy the cert256.arm
files in different path not the same path where cert256.arm already exist or you can rename the cert256.arm with
server name.
3) Add the cert256.arm of ‘TSM812’ into cert.kdb file on ‘TSM813’ server by following command:
gsk8capicmd_64 -cert -add -label -db cert.kdb -stashed -file <cert256.arm_path>
E.g.: gsk8capicmd_64 -cert -add -label TSM812(or ip) -db cert.kdb -stashed –file
/home/tsminst1/tsm812_cert256.arm
23. 23
Configure the server to connect to another server using SSL contd..
4) Add cert256.arm of ‘TSM813’ into cert.kdb file on ‘TSM812’ server by following command:
gsk8capicmd_64 -cert -add -label -db cert.kdb -stashed -file <cert256.arm_path>
E.g.: gsk8capicmd_64 -cert -add -label TSM813(or ip) -db cert.kdb -stashed –file /home/tsminst1/tsm813_cert256.arm
5) For both the servers, you can view the certificates in the key database by issuing the following command:
# gsk8capicmd_64 -cert -list -db cert.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! xxxx:1500:0
*- "TSM Server SelfSigned SHA Key“
6) Restart the servers.
7) Issue the DEFINE SERVER command.
For ‘TSM812’ server run the following command:
DEFINE SERVER TSM813 hla=TSM813_IP lla=1500 serverpa=passwordforTSM813 SSL=YES
For ‘TSM813’ server, run the following command:
DEFINE SERVER TSM812 hla=TSM812_IP lla=1500 serverpa=passwordforTSM812 SSL=YES
24. 24
Configure the server to connect to another server using SSL contd..
8) Verify the connection by running ping server from both servers ‘TSM812’ and ‘TSM813’
9) Check the SSL options by running query server f=d command
>q server TSM812 f=d
Server Name: TSM812
Comm. Method: TCPIP
Transfer Method: TCPIP
High-level Address: xx.xxx.xxx.x
Low-level Address: 1500
Description:
Allow Replacement: No
Node Name:
……….
Invalid Sign-on Count for Virtual Volume Node: 0
Validate Protocol: No
Version: 8
Release: 1
Level: 2.0
Role(s):
SSL: YES
Session Security: Strict
Transport Method: SSLTLS12
Object Agent: No
25. 25
Configure the storage agent and server to use SSL (7.1.8/8.1.2)
1) Initialize the storage agent using DSMSTA SETSTORAGESERVER command:
dsmsta setstorageserver myname=storage_agent_name mypa=sta_password myhla=ip_address
servername=server_name serverpa=server_password hla=ip_address lla=ssl_port ssl=yes
Note: You must specify the SSL=YES parameter to create the key database file in dsmsta.opt
2) Copy the 'cert256.arm' file from Spectrum Protect server to Storage agent.
3) Import the cert256.arm of Spectrum Protect server into cert.kdb file on storage agent by following
command:
gsk8capicmd_64 -cert -add -label SP_server_IP -db cert.kdb -stashed -file cert256.arm
26. 26
Configure the storage agent and server to use SSL contd..
4) Copy the 'cert256.arm' file from Storage agent to Spectrum Protect server
5) Import the cert256.arm of Storage agent into cert.kdb on Spectrum Protect server by following
command:
gsk8capicmd_64 -cert -add -label STA_IP -db cert.kdb -stashed -file cert256.arm
6) View the certificates in the key database by issuing the following command:
gsk8capicmd_64 -cert -list -db cert.kdb –stashed
7) Restart the storage agent and the server.
8) Establish communication between the server and the storage agent by issuing the following command:
define server sta hla=ip_address lla=port serverpa=password ssl=yes
27. 27
Configure the Operations center to connect to the hub server using SSL
1) Add the Transport Layer Security (TLS) certificate of the hub server to the truststore file of the Operations
Center to secure communications with the hub server.
2) Issue the following command to specify the cert256.arm certificate as the default certificate in the key
database file of the hub server.
gsk8capicmd_64 -cert -setdefault -db cert.kdb -stashed -label “TSM Server SelfSigned SHA Key”
3) Restart the hub server so that it can receive the changes to the key database file.
4) Verify that the cert256.arm certificate by the following command.
# gsk8capicmd_64 -cert -list -db cert.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
*- "TSM Server SelfSigned SHA Key"
28. 28
Configure the Operations center to connect to the hub server using SSL
5) Stop the Operations Center web server.
6) Go to Operations Center is installed directory.
AIX: installation_dir/ui/jre/bin
Windows: installation_diruijrebin
7) You can either use 'iKeycmd' command or IBM Key Management window (gui) 'ikeyman' to add the
cert256.arm' certificate as the default certificate in the key database file of the hub server.
> ikeycmd -cert -add -db /installation_dir/Liberty/usr/servers/guiServer/gui-truststore.jks
-file /fvt/comfrey/srv/cert256.arm -label 'label description' -pw 'password' -type jks -format
ascii -trust enable
Note: password is that you created when you installed the Operations Center.
8) Start the Operations Center web server.
https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.3/srv.install/t_oc_inst_ssl_configure_ochub.htm
l
30. 30
Troubleshooting: Scenario 1
Symptom: Importing server .arm file on client may fail with "Error -482 storing certificate" error.
■ Import the cert256.arm file into the client key database by using dsmcert utility.
[root@fazlu-linux-rhel71 bin]# dsmcert -add -server SERVER1 -file /home/cert256.arm
IBM Spectrum Protect
dsmcert utility
dsmcert Version 8, Release 1, Level 4.0
dsmcert date/time: 03/15/2019 16:37:39
(c) Copyright by IBM Corporation and other(s) 1990, 2017. All Rights Reserved.
Error -482 storing certificate
Result: Failed
■ Here Error -482 means --> RC_KM_DATABASE_DUPLICATE_KEY_SIGNATURE.
The 'certarm.256' file was obtained from the SERVER2 server and was stored in the same directory as the
dsmcert.exe command but here we are trying to import SERVER1 certificate due to that it failed with error 482 error.
31. 31
Troubleshooting: Scenario 1 contd..
Resolution:
■ In such cases ensure you are using the correct cert256.arm server file and copy to client machine then
import the file.
[root@fazlu-linux-rhel71 bin]# dsmcert -add -server SERVER1 -file /home/cert256.arm
IBM Spectrum Protect
dsmcert utility
dsmcert Version 8, Release 1, Level 4.0
dsmcert date/time: 03/18/2019 19:18:03
(c) Copyright by IBM Corporation and other(s) 1990, 2017. All Rights Reserved.
Result: Success
■ After importing, verify the key in dsmcert.kdb with following command.
[root@fazlu-linux-rhel71 bin]# gsk8capicmd_64 -cert -list all -db dsmcert.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! 127.0.0.1:1500
! "TSM server self-signed key"
! "TSM server SERVER1 self-signed key"
32. 32
Troubleshooting: Scenario 2
After a Spectrum Protect server is upgraded to V7.1.8, you may receive following errors during server to
server communication.
ANR8583E An SSL socket-initialization error occurred on session xxxx. The GSKit return code is 414
GSK_ERROR_BAD_CERT.
ANR8583E An SSL socket-initialization error occurred on session xxxx. The GSKit return code is 447
GSK_ERROR_CERTIFICATE_INVALIDSIGALG
Cause: Incorrect key on source server
Symptom:
■ Try to run the following command from Spectrum Protect server to force synchronization between
source and target servers.
Source server: UPDATE SERVER server_targetL forcesync=yes sessionsecurity=transitional
Target server: UPDATE SERVER server_sourceL forcesync=yes sessionsecurity=transitional
■ If above does not fix the issue, then run the following command to list the key from both the source
and target server:
> gsk8capicmd_64 -cert -list all -db cert.kdb -stashed
33. 33
Troubleshooting: Scenario 2 contd..
It shows source server key is incorrect.
Source server:
*- "TSM Server SelfSigned Key"
Target server:
*- "TSM Server SelfSigned SHA Key"
Resolution:
1) Rename the cert.kdb file in the server instance directory
2) Halt and restart the server instance. This will recreate the cert.kdb file.
3) Then run the following commands on Spectrum Protect server to force synchronization between source
and target servers.
Source server: UPDATE SERVER server_target forcesync=yes sessionsecurity=transitional
Target server: UPDATE SERVER server_source forcesync=yes sessionsecurity=transitional
4) Rerun the 'gsk8capicmd_64' command to check the key on source server, it should correct key "TSM
Server SelfSigned SHA Key"
34. 34
Troubleshooting: Scenario 3
After upgrading the server and Db2 API client to 7.1.8 or 8.1.2 or later versions you may face below error while
running db2adult query command:
#db2/db2_user==> db2adutl query full
Error Initialize sessions failed with TSM return code -471
dsmerror.log shows following errors:
ANS1579E GSKit function GSKKM_ImportKeys failed with 16: GSKKM_ERR_DATABASE_INVALID_PASSWORD
ANS9020E A session could not be established with a TSM server or client agent. The return code
is -471.
Symptom:
1) Running 'gsk8ver_64' command from both root and db2 user shows there is mismatch gskit version.
2) IBM Spectrum Protect client versions 7.1.8 /8.1.2 it requires a minimum GSKit level (currently 8.0.50.78).
3) In this scenario db2 level is v9.7.0.11, db2 user shows gskit version as 8.0.50.47 and root shows
8.0.50.78.
4) db2 use a local GSKit for their own security requirements and force the IBM Spectrum Protect client to use
that same local GSKit which might not be at the minimum level for IBM Spectrum Protect operations.
35. 35
Troubleshooting: Scenario 3 contd..
Resolution:
To fix these errors create a symbolic link to access the latest GSKit library as shown below:
ln - n /db2/db2_user/sqllib/gskit to /usr/opt/ibm/gsk8_64/lib64
In case above does not fix the issue then follow below steps:
1) Delete all the 'dsmcert*' files from the baclient directory.
2) Copy the cert256.arm to the baclient directory from the server directory.
3) Run the following command on the client node to Import the cert256.arm file to the client key database file
dsmcert.kdb.
dsmcert -add -server <servername> -file <path_to_cert256.arm>
4) Verify the key in dsmcert.kdb with following command.
gsk8capicmd_64 -cert -list -db dsmcert.kdb –stashed
5) Then restart db2.
6) Rerun db2adutl query and it works.
36. 36
Troubleshooting: Additional information for DB2 database
If a DB2 is configured on the Client which is upgraded to 7.1.8+ / 8.1.2+ you need to follow these
instructions.
■ DB2 API backup fail with RC 927 after Client upgrade to 7.1.8 or 8.1.2 and higher
https://www-01.ibm.com/support/docview.wss?uid=swg22010129
■ GSKit Versions Shipped with DB2
https://www-01.ibm.com/support/docview.wss?uid=swg21617892
■ Configuring DB2 and IBM Spectrum Protect in Unix / Linux
http://www-01.ibm.com/support/docview.wss?uid=swg22004184
■ Creating a symbolic link to access the latest GSKit library
https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.4/client/t_cfg_ssl_symb_lnk_gski
t.html
37. 37
Troubleshooting: dsmadmc - Restriction
After an administrator successfully authenticates with the server by using IBM Spectrum Protect V8.1.2 or
later software or Tivoli Storage Manager V7.1.8 or later software, the administrator can no longer
authenticate with that server using client or server versions earlier than V8.1.2 or V7.1.8.
Symptom: An administrator account cannot log in to a system that is using software earlier than V8.1.2.
Resolution:
■ Identify all systems from which administrators log in and which use the administrative ID to log in.
Upgrade the IBM Spectrum Protect client to v8.1.2 or later, and ensure that the server's certificate is
installed on each system.
■ Set the administrator’s SESSIONSECURITY parameter value to TRANSITIONAL by issuing the command
update admin admin_name sessionsecurity=transitional
Tip:
If necessary, create a separate administrator account to use only with clients and servers that are using
V8.1.1 or earlier software.
38. ■ In the release 7.1.8 and 8.1.2 of Spectrum Protect for VE, the automatic certificate exchange with
Trust on first use (TOFU) is not available.
■ SSL Certificate from the Spectrum Protect Server need to be imported manually before switching to
SSL enabled communication:
1. Copy the server certificate (cert256.arm) to the Spectrum Protect for VE GUI Server
2. Import the certificate:
cd "C:Program Files (x86)Common FilesTivoliTDPVMwareVMwarePluginscripts"
C:IBMtivolitsmtdpvmwarewebserverjrejrebinkeytool.exe -importcert -alias "TSM Server"
-file C:tempcert256.arm -keystore tsm-ve-truststore.jks -storepass PASSWORD
Note: The tsm-ve-truststore password is defined with the above command, remember the password,
maybe use the same as for the OC truststore
38
Troubleshooting: Spectrum Protect for VE - Restriction
39. ■ IBM Global Security Kit GSKit version
https://www.ibm.com/support/knowledgecenter/SSAL2T_8.2.0/com.ibm.cics.tx.doc/pdf/GSK_CapiC
md_UserGuide.pdf
■ IBM Spectrum Protect security updates in V7.1.8, V8.1.2, V8.1.3, and V8.1.4
http://www-01.ibm.com/support/docview.wss?uid=swg22004844
■ GSKit levels distributed by IBM Spectrum Protect
https://www-01.ibm.com/support/docview.wss?uid=ibm10870512
■ GSKit Versions Shipped with DB2
https://www-01.ibm.com/support/docview.wss?uid=swg21617892
39
References: