Generating and using self-signed certificates

• IBM Data Replication for Availability doesn’t work.

  WORKAROUND:

  To refresh the Db2 ssl certificate for IBM Data Replication for Availability:

  1. On the source system, in the Db2 container, as su-dsadm:

       a) Ensure that BLUDR_SHARED_DIR is set:

           - On IAS or Db2 Warehouse on Cloud:

  BLUDR_SHARED_DIR=/head/bludr

           - On Db2 Warehouse:

  BLUDR_SHARED_DIR=/mnt/blumeta0/bludr

      b) Import local Db2 ssl certificate to the IBM Data Replication for Availability truststore:

  /opt/ibm/java/jre/bin/keytool -delete -keystore ${BLUDR_SHARED_DIR}/certificates/cacerts -storepass "$(base64 -d ${BLUDR_SHARED_DIR}/certificates/truststore_pwd)" -alias db2_ssl -noprompt

  /opt/ibm/java/jre/bin/keytool -import -trustcacerts -keystore ${BLUDR_SHARED_DIR}/certificates/cacerts -storepass "$(base64 -d ${BLUDR_SHARED_DIR}/certificates/truststore_pwd)" -alias db2_ssl -noprompt -import -file /mnt/blumeta0/db2/ssl_keystore/rootCA.pem

     c) Import the target Db2 ssl certificate to the IBM Data Replication for Availability truststore.

         The certificate is available at /mnt/blumeta0/db2/ssl_keystore/rootCA.pem inside the database container. You can extract the self-signed root CA certificate to your system. For more information, see the Procedure section.

  /opt/ibm/java/jre/bin/keytool -delete -keystore ${BLUDR_SHARED_DIR}/certificates/cacerts -storepass "$(base64 -d ${BLUDR_SHARED_DIR}/certificates/truststore_pwd)" -alias db2_ssl_<target_hostname> -noprompt

  /opt/ibm/java/jre/bin/keytool -import -trustcacerts -keystore ${BLUDR_SHARED_DIR}/certificates/cacerts -storepass "$(base64 -d ${BLUDR_SHARED_DIR}/certificates/truststore_pwd)" -alias db2_ssl_<target_hostname> -noprompt -import -file ${BLUDR_SHARED_DIR}/certificates/<target_hostname>_rootCA.pem

      d) As the root or db2inst1 user, import the remote target Db2 root certificate to the local Db2 ssl keystore for Db2CLP:

  opt/ibm/db2/V11.5.0.0/gskit/bin/gsk8capicmd_64 -cert -add -db /mnt/blumeta0/db2/ssl_keystore/bludb_ssl.kdb -stashed -label db2_ssl_rootCA_<target_hostname> -file ${BLUDR_SHARED_DIR}/certificates/<target_hostname>_rootCA.pem -format ascii -trust enable -fips

      e) Verify the Db2 certificate aliases in the IBM Data Replication for Availability truststore:

  keytool -v -list -keystore ${BLUDR_SHARED_DIR}/certificates/cacerts  -storepass "$(base64 -d ${BLUDR_SHARED_DIR}/certificates/truststore_pwd)"  | grep Alias -A10 | grep db2 -A10

      f) Restart the IBM Data Replication for Availability server and web console.

         Run the restart commands as the dsadm user:

         i. The IBM Data Replication for Availability server:

  /opt/ibm/bludr/scripts/bin/bludr-restart.sh

        ii. The web console:

           - On Db2 Warehouse:

  /opt/ibm/dsserver/bin/restart.sh 

          - On IAS:

            > Restart the API server:

  systemctl restart apiserver

           > From the IAS console, on the platform:

  ap apps disable webconsole
  ap apps enable webconsole 

  2. On the target system, do the same steps as for the source system. Import the source Db2 ssl certificate and local Db2 ssl certificate to the IBM Data Replication for Availability truststore, and import the remote source Db2 root certificate for Db2CLP.
• Lift to cloud doesn’t work.

  WORKAROUND:

       1. Restart the web console container:

ap apps restart WEBCONSOLE

WebConsole will be restarted. Are you sure you want to proceed? [y/N]:
y
Restart request sent successfully

• The db_migrate_iias command doesn’t work with ssl.

  WORKAROUND:

  Run the commands from the source or target system from which you want to invoke db_migrate_iias.

           For more information, see the Procedure section.

[db2inst1@ma-bhpwr5-8 - Db2wh ~]$ /opt/ibm/db2/V11.5.0.0/gskit/bin/gsk8capicmd_64 -cert -add -db /mnt/blumeta0/db2/ssl_keystore/bludb_ssl.kdb -stashed -label ss_bluhel21 -file <fully_qualified_path_to_the_CA_cert_copied>  -format ascii -trust enable -fips

• After a head node failover, the web console can’t access the database.

  WORKAROUND:

  You must run the installation script again in the web_console container on the new head node after head node failover:

docker cp install-self-signed-cert.sh web_console:/scratch
docker exec -it web_console bash /scratch/install-self-signed-cert.sh -p IIASweb

• The dbload and dbsql commands don’t work with ssl.

  WORKAROUND:

  Set up the client to trust the certificate as described in Step 3 and Step 4 of the Procedure section. There's no need to catalog the database.
• While you're running the db_restore command from web_console, a 'Database restore failed on the web console' error appears. The restore succeeds in backend.

  WORKAROUND:

  To validate the progress of the restore operation, as bluadmin, run the db2 list utilities show detail command to establish if a restore is running.

  If a restore operation is in progress, the example output for each MLN is:

  Restore percentage output:
  ID = 1
  Type = RESTORE
  Database Name = BLUDB
  Member Number = 1
  Description = db
  Start Time = 09/02/2020 09:57:33.923808
  State = Executing
  Invocation Type = User
  Progress Monitoring:
  Completed Work = 922976256 bytes
  Start Time = 09/02/2020 09:57:33.923813

  ID = 1
  Type = RESTORE
  Database Name = BLUDB
  Member Number = 2
  Description = db
  Start Time = 09/02/2020 09:57:33.904257
  State = Executing
  Invocation Type = User
  Progress Monitoring:
  Completed Work = 922976256 bytes
  Start Time = 09/02/2020 09:57:33.904264

  You can find a log file associated with this restore operation in the /opt/ibm/appliance/storage/scratch/bluadmin_BNR/logs directory directory. Review the logs in the most recent restore log and tracelog for progress details.