TCP/IP for z/VM
SSL Server - Migration and Backup of a BFS-based Certificate (Key) Database

The instructions that follow can be used to migrate an existing z/VM SSL server key database from one z/VM system to another such system.

The technique described here can also be adapted (by omission of the file transfer step, below) to create a backup copy of the BFS file space in which z/VM SSL server key database (and other) files are maintained for use. The backup can then of course be used to restore the content of the file space to its state when the backup was created.

Notes:

  • The information that follows is applicable to z/VM CMS-based SSL server implementations only (those provided with TCP/IP for z/VM level 540 and later).
  • The z/VM level 540 or later key database is maintained using the CMS Byte File System (BFS), and resides (by default) in the IBM-supplied and defined VMSYS file pool. While various means can be used to migrate such data, any method chosen must ensure that file permissions for all pertinent files are maintained.
  • For supplementary information about the commands and procedures that follow, consult z/VM: CMS File Pool Planning, Administration, and Operation.

Key Database Migration Steps

The suggested method for moving the SSL key database and related data is to use the CMS FILEPOOL UNLOAD and FILEPOOL RELOAD commands on the pertinent systems. The steps below summarize the necessary commands. For complete details and additional command considerations, see the topic on managing users and file spaces in z/VM: CMS File Pool Planning, Administration, and Operation.

Follow these steps to move a BFS file space from one system to another, maintaining use of the same storage group:

  1. Log on a user ID that is an administrator for the subject file pool (VMSYS, by default) on the system where the BFS data of interest currently exists.

    To identify file pool administator user IDs, use the command: query enroll admin filepoolid
    For example: query enroll admin vmsys

  2. Issue a FILEDEF command to identify the file that is to contain the unloaded data. Here, the name of the file space (file_space) is used as part of the file identifier for a disk-resident file. 

      filedef unload disk file_space dbasexfr a
    By default, SSL key database data is maintained in the GSKSSLDB file space.

  3. Issue a FILEPOOL UNLOAD command for the file space that is being moved: 

      filepool unload filespace file_space vmsys: ( all
  4. Transfer the file_space DBASEXFR file to the new system, using appropriate means (for a second level system, perhaps by copying the file to a system-acccesible minidisk, or by using FTP).

    Note:
    If FTP is used to transfer the unloaded data, you must use the CMS COPYFILE command (with its PACK option) to first pack the subject file. This allows the file to then be properly handled as a binary file, until it resides on the new system (at which time the file will need to be unpacked, to allow for FILEPOOL RELOAD processing).

  5. On the new system, issue a FILEDEF command to identify the file that contains the reload data. Here, the name of the file used to contain the previously unloaded data is specified: 

      filedef reload disk file_space dbasexfr a
  6. Issue a FILEPOOL RELOAD command for the file space that is being moved: 

      filepool reload filespace file_space vmsys:

Note:
If a reload is performed while SSl pool servers are active, and you want the servers to make use of restored key database data, the servers must be instructed to remount the (GSKSSLDB) file space, and then update their internally-maintained key database information. This can be done using the SSLADMIN commands shown here: 

  ssladmin system exec openvm unmount /etc/gskadm (sslserv all
  ssladmin system exec openvm mount /../VMBFS:VMSYS:GSKSSLDB/ /etc/gskadm (sslserv all
  ssladmin refresh