Command Line Tools Guide
Red Hat Certificate System                                                            

Previous
Contents
Index
Next

Chapter 2

CS Migration Utility


If you have a previous installation of Red Hat Certificate System (CS), Netscape Certificate Management System (CMS), or iPlanet Certificate Management System (iCMS, also known as SunTM ONE Certificate Server), you can use the CS Migration Utility for migrating its data to CMS 6.0 or later versions.

Note: This chapter was "incorrectly" entitled "CMS Upgrade Utility" in previous releases of the software.

This chapter has fifteen sections. The first two sections provide some background and an overview of the current version of the CS Migration Utility, respectively. The third section provides general, as well as version/subsystem specific, caveats related to migration. The next eleven sections explain the steps involved in migration. The final section provides a detailed example of migrating a previous CMS 6.1 (SP 4) installation running on a Solaris 8 machine to a CS 7.1 installation running on a Red Hat Enterprise Linux (RHEL) 4 machine.

To go to a specific section, click one of the options below:

History

This table summarizes all CS/CMS/iCMS releases through CS 7.1:

Table 2-1 Summary of CS releases
Release date
Product Name
Service Packs
1/24/1997
Netscape Certificate Server 1.0
1.01, 1.02, 1.03,
and 1.0 (SP 1)
06/24/1999
Netscape Certificate Management System 4.1
4.1 (SP 1)
08/02/2000
Netscape Certificate Management System 4.2
4.1 (SP 1) and 4.1 (SP 1a)
03/29/2001
NetscapeCertificate Management System 4.2 (SP 2)
 
10/10/2001
NetscapeCertificate Management System 4.5
 
03/28/2002
NetscapeCertificate Management System 6.0
Netscape CMS 6.01
06/03/2002
iPlanet Certificate Management System 4.7
4.7 (SP 1)
03/12/2003
Netscape Certificate Management System 6.1
6.1 (SP 1), 6.1 (SP 2),
6.1 (SP 3), 6.1 (SP 3.1),
and 6.1 (SP 4)
06/17/2003
Netscape Certificate Management System 6.2
6.2 (SP 1)
11/30/2004
Netscape Certificate Management System 7.0
 
05/27/2005
Red Hat Certificate System 7.1
 

Every version of CS/CMS/iCMS has been built with some capability to extract data from a previous version and migrate this data to the newest version:

Overview

While the CS Migration Utility consists of numerous standalone platform-independent programs, only two are actually required for any one version of CS/CMS/iCMS: one program to convert an LDIF data file exported from an existing previous version into a "normalized" LDIF text file, and another program to convert this "normalized" LDIF text file into an LDIF data file that can be imported into CMS 6.0 or later versions.

CS Migration export utilities consist of 41ToTxt, 42ToTxt, 42SP2ToTxt, 45ToTxt, 47ToTxt, 60ToTxt, 61ToTxt, 62ToTxt, 70ToTxt, and 71ToTxt.. Each CS Migration export utility contains the following files:

Note: Each compilation shell script is dependent on a specific version of the Java software development kit as defined in the comments.
Note: Each compilation batch script is dependent on a specific version of the Java software development kit as defined in the comments.

CS Migration import utilities consist of TxtTo60, TxtTo61, TxtTo62, TxtTo70, and TxtTo71. Each CS Migration import utility contains the following files:

Note: Each compilation shell script is dependent upon a specific version of the Java software development kit as defined in the comments.
Note: Each compilation batch script is dependent upon a specific version of the Java software development kit as defined in the comments.

The following table defines the CS Migration export programs and corresponding import programs. An X indicates compatibility between the export and import programs.

Table 2-2 CS Migration Compatibility Matrix
 
         CS Migration import Package
 
CS Migration export Package
TxtTo60
TxtTo61
TxtTo62
TxtTo70
TxtTo71
41ToTxt
X
X
X
X
X
42ToTxt
X
X
X
X
X
42SP2ToTxt
X
X
X
X
X
45ToTxt
X
X
X
X
X
47ToTxt
X
X
X
X
X
60ToTxt
X
X
X
X
X
61ToTxt
 
X
X
X
X
62ToTxt
 
 
X
X
X
70ToTxt
 
 
 
X
X
71ToTxt
 
 
 
 
X

In every case, with the exception of CMS 4.2 (SP 2) since it was actually its own stand-alone major version, the major version number of the CS Migration export/import package may be applied to all service packs (SP) of that version (this also applies to installations which may contain individual "hot-fixes", which are individual bug fixes that were made after a service pack had been released). For example, the 42ToTxt export package should be utilized for CMS 4.2, 4.2 (SP 1), and 4.2 (SP 1a) (regardless whether or not any of these versions contained any individual "hot-fixes"). In the case of CMS 6.01, the 60ToTxt program should be used to export data, and the TxtTo60 program should be used to import data.

Additionally, each CS/CMS/iCMS installation has existed on various platforms and may contain more than one type of subsystem, or even more than one instance of a particular type of subsystem. The various types of subsystems have consisted of a Certificate Authority (CA), a Data Recovery Manager (DRM), an Online Certificate Status Protocol (OCSP) Manager, a Registration Authority (RA), a Token Key Service (TKS), and a Token Processing System (TPS). The following table defines the various platforms, and types of subsystems, supported by various versions of CS/CMS/iCMS:

Table 2-3 CS/CMS/iCMS Subsystem Types and Platforms
Product (including service packs & "hot-fixes")
Subsystems
Platforms
Netscape Certificate Server 1.0
CA
Digital UNIX 3.2C/4.0B,
HP-UX 10.10,
IBM AIX 4.1.4/4.2,
IRIX 5.3/6.2,
Solaris 2.4/2.5.1,
Windows NT 3.51/4.0 [Intel],
Windows NT 4.0 [Alpha]
Netscape Certificate Management System 4.1
CA,
RA
Solaris 2.5.1/2.6,
Windows NT 4.0 (SP 4)
[with NTFS]
Netscape Certificate Management System 4.2
CA,
DRM,
RA
HP-UX B.11.00,
IBM AIX 4.3.2,
OSF/1 4.0D,
Solaris 2.6/2.7/8,
Windows NT 4.0 (SP 4/5/6),
Windows 2000
Netscape Certificate Management System 4.2 (SP 2)
CA,
DRM,
OCSP,
RA
Compaq Tru64 4.0D,
HP-UX B.11.00,
IBM AIX 4.3.3,
Solaris 2.6/2.7/8,
Windows NT 4.0 (SP 5/6)
Netscape Certificate Management System 4.5
CA,
DRM,
OCSP,
RA
Solaris 2.6/8,
Windows NT 4.0 (SP 6a),
Windows 2000 (SP 2)
iPlanet Certificate Management System 4.7
CA,
DRM,
OCSP,
RA
Solaris 8,
Windows NT 4.0 (SP 6a),
Windows 2000
Netscape Certificate Management System 6.0
CA,
DRM,
OCSP,
RA
Solaris 8,
Windows 2000 (SP 2)
Netscape Certificate Management System 6.01*
CA,
DRM,
OCSP,
RA
Red Hat Linux 7.2,
Red Hat Linux
Advanced Server 2.1,
Solaris 8
Netscape Certificate Management System 6.1
CA,
DRM,
OCSP,
RA
Solaris 8
Netscape Certificate Management System 6.2
CA,
DRM,
OCSP,
RA
Red Hat Linux
Advanced Server 2.1,
Solaris 8
Netscape Certificate Management System 7.0
CA,
DRM,
OCSP,
TKS,
TPS
Red Hat Linux
Advanced Server 2.1,
Solaris 8
Red Hat Certificate System 7.1
CA,
DRM,
OCSP,
TKS,
TPS
Red Hat Enterprise
Linux 3 (AS/ES),
Red Hat Enterprise
Linux 4 (AS/ES),
Solaris 9 [32-bit/64-bit]

* Although considered a service pack of CMS 6.0, CMS 6.01 is specified independently in this table due to its change of supported platforms.

Caveats regarding Migration

When migrating any subsystem from any platform, the following caveats apply:

Additionally, the following caveats apply to specific subsystems of specific versions of CS/CMS/iCMS:

Step 1: Before Migration

Before migrating from a CS 7.1/CMS 4.1, 4.2, 4.2 (SP 2), 4.5, 6.0, 6.1, 6.2, 7.0/iCMS 4.7 instance to the latest CS instance, you must back up your previous CS/CMS/iCMS instance.

If you are using a commercial backup program:

  1. Stop all server instances running in the old CS/CMS/iCMS installation - this includes all CS/CMS/iCMS, DS (including all internal DBs), and Admin Server instances of the old server that exist on this machine.
  2. Run the commercial backup facility to back up all data associated with this old CS/CMS/iCMS installation.

Otherwise, if you are using the backup facilities included with the old CS/CMS/iCMS installation:

  1. Run the CS/CMS/iCMS backup facility to back up all data associated with this old installation based upon the version specified below:
CMS 4.1, 4.2, 4.2 (SP 2), or 4.5:
For instructions to back up a CMS 4.1, 4.2, 4.2 (SP 2), or 4.5 instance, check the CMS Command-Line Tools Guide that was provided with the product; open the <server_root>/manual/en/cert/tools/backup.htm file.
iCMS 4.7:
For instructions to back up a iCMS 4.7 instance, check the documentation that was provided with the product.
CS 7.1/CMS 6.0, 6.1, 6.2, or 7.0:
For instructions to back up a CS 7.1/CMS 6.0, 6.1, 6.2, or 7.0 instance, see Chapter 7 "Backing Up and Restoring Data."
  1. Stop all server instances running in the old CS/CMS/iCMS installation - this includes all CS/CMS/iCMS, DS (including all internal DBs), and Admin Server instances of the old server that exist on this machine.

Step 2: Creation of a New CS Installation

  1. Create a new CS installation on your machine based upon your operating system (e. g. - CS 7.1):
RHEL 3, or RHEL 4:
 
  1. Download and install the <CS>.rpm as "root". For example:

    rpm -ivh <CS>.rpm
     
  2. As required for your particular installation, use operating system facilities to create any necessary user/groups, and change any file permissions necessary for the deployment of your new CS installation. If the CS installation is not to be run as "root", login as the non-"root" user.
     
  3. Go to the following directory:

    cd <new_server_root>
     
  4. Execute the following command:

    <new_server_root>/setup/setup

    Note:
    For simplicity's sake, this document assumes that the names of all new server instances match the names of the corresponding old server instances exactly (<old_CA_instance> = <new_CA_instance>, <old_DRM_instance>=<new_DRM_instance>, etc.). Although it is possible to change the names of migrated CS subsystem instances, greater care must be taken when extracting and renaming certain portions of the data. Fortunately, port numbers do not fall under this constraint, since they are only stored in the Configuration Directory Server and the "server.xml", neither of which present any difficulties during a migration.
     
Solaris 9 [64-bit], or Solaris 9 [32-bit]:
 
  1. As required for your particular installation, login as "root", and use operating system facilities to create any necessary user/groups, and change any file permissions necessary for the deployment of your new CS installation. If the CS installation is not to be run as "root", login as the non-"root" user.
     
  2. Download and decompress the compressed tarball. For example:

    gunzip <CS>.tar.gz
     
  3. Unpack the tarball. For example:

    tar -xvf <CS>.tar
     
  4. Execute the following command:

    ./setup

    Note:
    For simplicity's sake, this document assumes that the names of all new server instances match the names of the corresponding old server instances exactly (<old_CA_instance> = <new_CA_instance>, <old_DRM_instance>=<new_DRM_instance>, etc.). Although it is possible to change the names of migrated CS subsystem instances, greater care must be taken when extracting and renaming certain portions of the data. Fortunately, port numbers do not fall under this constraint, since they are only stored in the Configuration Directory Server and the "server.xml", neither of which present any difficulties during a migration.
  1. Configure the new CS instance.
If the instance to be configured is a DRM, perform steps a.) and b.), else proceed with step c.) below:
 
  1. Go to the following directory:

    cd <new_server_root>/cert-<new_DRM_instance>/config
     
  2. Edit the file called "CertSetup.cfg" and append the following line to the end of this file:

    kra.keySplitting=true

     
  3. Go to the following directory:

    cd <new_server_root>

     
  4. Execute the following command:

    startconsole

     
  5. Configure your desired subsystem.
     
  1. Optionally, if any additional CS instances need to be created:
     
    1. Use the console to create the new CS instance.

      Note:
      For simplicity's sake, this document assumes that the names of all new server instances match the names of the corresponding old server instances exactly (<old_CA_instance> = <new_CA_instance>, <old_DRM_instance>=<new_DRM_instance>, etc.). Although it is possible to change the names of migrated CS subsystem instances, greater care must be taken when extracting and renaming certain portions of the data. Fortunately, port numbers do not fall under this constraint, since they are only stored in the Configuration Directory Server and the "server.xml", neither of which present any difficulties during a migration.

      If the instance to be configured is a DRM, perform steps b.) and c.) in a separate window, else proceed with step d.):
       
    2. Go to the following directory:

      cd <new_server_root>/cert-<new-instance>/config
       
    3. Edit the file called "CertSetup.cfg" and append the following line to the end of this file:

      kra.keySplitting=true

       
    4. Configure this new subsystem
       
    5. Repeat this procedure for each CS subsystem desired

Step 3: Stopping all new CS instances

Prior to performing any migration, stop all new CS instances:

  1. For each new CS subsystem that resides on this machine, execute the specified commands:
cd <new_server_root>/cert-<new_instance>
stop-cert
  1. Execute the specified commands to stop the Administration Server:
cd <new_server_root>
stop-admin
  1. For each internal DB that resides on this machine, execute the specified commands:
cd <new_server_root>/slapd-<new_instance>-db
stop-slapd
  1. If a configuration directory resides on this machine, execute the specified commands:
cd <new_server_root>/slapd-<new_config_directory_instance>
stop-slapd

Step 4: Migration of Security Databases

Extract data from the old server's certificate (cert7.db/cert8.db) and key (key3.db) security databases and copy it into the new server's alias directory; perform this task for each CS/CMS/iCMS subsystem instance to be migrated.

First, select the section below that corresponds to the CS/CMS/iCMS version to be migrated. To go to the section of interest, click one of the options below:

CMS 4.1

CMS 4.1 [CA]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 4.1 [CA] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_CA_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    cp <old_server_root>/cert-<old_CA_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
Note: Since <old_CA_instance>=<new_CA_instance>, no further references will be made to <old_CA_instance>.
  1. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  2. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  3. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
        Server-Cert cert-<new_CA_instance> cu,cu,cu
     
        caSigningCert cert-<new_CA_instance> cu,cu,cu
     
    
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Remove the "cert7.db" by executing the specified command:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    
  2. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
Duplicate the ca.signing.cacertnickname line and add it to the end of the file, replacing ca.signing.cacertnickname with ca.ocsp_signing.cacertnickname:
ca.ocsp_signing.cacertnickname=caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case II: CMS 4.1 [CA] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_CA_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    cp <old_server_root>/cert-<old_CA_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
Logout as "root" so that you are the <new_user> again.
chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert7.db
 
chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
 

 
  1. List the contents of the old software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
        Server-Cert cert-<old_CA_instance> cu,cu,cu
     
        caSigningCert cert-<old_CA_instance> cu,cu,cu
     
    
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_CA_instance>" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
     
     
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    caSigningCert.p12 -n "caSigningCert cert-<old_CA_instance>" -d . 
    -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  2. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  3. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  4. Identify the new HSM slot name by executing the following command:
    <new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb 
    -list
     
    
  5. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  9. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
Duplicate the ca.signing.cacertnickname line and add it to the end of the file, replacing ca.signing.cacertnickname with ca.ocsp_signing.cacertnickname:
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    
Case III: CMS 4.1 [CA] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/caSigningCert.p1
    2 <new_server_root>/alias/caSigningCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    
  5. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  6. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    
  7. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_CA_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "caSigningCert cert-<new_CA_instance>" -t "CTu,CTu,CTu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  8. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
Duplicate the ca.signing.cacertnickname line and add it to the end of the file, replacing ca.signing.cacertnickname with ca.ocsp_signing.cacertnickname:
ca.ocsp_signing.cacertnickname=caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case IV: CMS 4.1 [CA] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/caSigningCert.p1
    2 <new_server_root>/alias/caSigningCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    
  5. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  6. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
Duplicate the ca.signing.cacertnickname line and add it to the end of the file, replacing ca.signing.cacertnickname with ca.ocsp_signing.cacertnickname:
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    

CMS 4.2

Click below to choose the subsystem to migrate:

CMS 4.2 [CA]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 4.2 [CA] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_CA_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    cp <old_server_root>/cert-<old_CA_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    Note: Since <old_CA_instance>=<new_CA_instance>, no further 
    references will be made to <old_CA_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_CA_instance> cu,cu,cu
    caSigningCert cert-<new_CA_instance> cu,cu,cu
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Remove the "cert7.db" by executing the specified command:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    
  2. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
Duplicate the ca.signing.cacertnickname line and add it to the end of the file, replacing ca.signing.cacertnickname with ca.ocsp_signing.cacertnickname:
ca.ocsp_signing.cacertnickname=caSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=caSigningCert cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case II: CMS 4.2 [CA] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_CA_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    cp <old_server_root>/cert-<old_CA_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_CA_instance> cu,cu,cu
    caSigningCert cert-<old_CA_instance> cu,cu,cu
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_CA_instance>" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    caSigningCert.p12 -n "caSigningCert cert-<old_CA_instance>" -d . 
    -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  2. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  3. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  4. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
Duplicate the ca.signing.cacertnickname line and add it to the end of the file, replacing ca.signing.cacertnickname with ca.ocsp_signing.cacertnickname:
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    
Case III: CMS 4.2 [CA] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/caSigningCert.p1
    2 <new_server_root>/alias/caSigningCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    
  5. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  6. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    
  7. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_CA_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "caSigningCert cert-<new_CA_instance>" -t "CTu,CTu,CTu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  8. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
Duplicate the ca.signing.cacertnickname line and add it to the end of the file, replacing ca.signing.cacertnickname with ca.ocsp_signing.cacertnickname:
ca.ocsp_signing.cacertnickname=caSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=caSigningCert cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case IV: CMS 4.2 [CA] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/caSigningCert.p1
    2 <new_server_root>/alias/caSigningCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    
  5. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  6. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
Duplicate the ca.signing.cacertnickname line and add it to the end of the file, replacing ca.signing.cacertnickname with ca.ocsp_signing.cacertnickname:
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    

CMS 4.2 [DRM]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 4.2 [DRM] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_DRM_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    cp <old_server_root>/cert-<old_DRM_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    Note: Since <old_DRM_instance>=<new_DRM_instance>, no further 
    references will be made to <old_DRM_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_DRM_instance> cu,cu,cu
    caSigningCert cert-<new_DRM_instance> CT,c,
    kraStorageCert cert-<new_DRM_instance> u,u,u
    kraTransportCert cert-<new_DRM_instance> u,u,u
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Remove the "cert7.db" by executing the specified command:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    
  2. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=kraStorageCert cert-<new_DRM_instance>
 
kra.transportUnit.nickName=kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    
Case II: CMS 4.2 [DRM] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_DRM_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    cp <old_server_root>/cert-<old_DRM_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_DRM_instance> cu,cu,cu
    caSigningCert cert-<old_DRM_instance> cT,c,
    kraStorageCert cert-<old_DRM_instance> u,u,u
    kraTransportCert cert-<old_DRM_instance> u,u,u
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    kraStorageCert.p12 -n "kraStorageCert cert-<old_DRM_instance>" 
    -d . -P cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    kraTransportCert.p12 -n "kraTransportCert 
    cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  2. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "caSigningCert cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -a > caSigningCert.b64
     
    Note: The old software security databases may contain additional public keys that also 
    need to be extracted using this command.
     
    
  3. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  4. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  5. Identify the new HSM slot name by executing the following command:
    <new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb 
    -list
     
    
  6. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
  7. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  8. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  9. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_DRM_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraStorageCert cert-<new_DRM_instance>" -t 
    "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraTransportCert cert-<new_DRM_instance>" 
    -t "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  10. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_DRM_instance>" -t 
    "CT,c," -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  11. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  12. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=<new_HSM_slot_name>:kraStorageCert 
cert-<new_DRM_instance>
 
kra.transportUnit.nickName=<new_HSM_slot_name>:kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    
Case III: CMS 4.2 [DRM] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/kraStorageCert.
    p12 <new_server_root>/alias/kraStorageCert.p12
     
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/kraTransportCer
    t.p12 <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/cert-<old_DRM_instance>/config
    2. Use the old standalone certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    3. Use the old standalone certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    4. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp 
      <old_server_root>/cert-<old_DRM_instance>/config/caSigningCert.b
      64 <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> kraStorageCert.p12
     
    chown <new_user>:<new_group> kraTransportCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 kraStorageCert.p12
     
    chmod 00600 kraTransportCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_DRM_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "kraStorageCert cert-<new_DRM_instance>" -t "u,u,u" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "kraTransportCert cert-<new_DRM_instance>" -t "u,u,u" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
  9. Import the public key of the entry from the base-64 file, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "caSigningCert cert-<new_DRM_instance>" -t "CT,c," -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -i caSigningCert.b64
     
    
  10. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  11. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=kraStorageCert cert-<new_DRM_instance>
 
kra.transportUnit.nickName=kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    
Case IV: CMS 4.2 [DRM] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
    
     
    
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/kraStorageCert.
    p12 <new_server_root>/alias/kraStorageCert.p12
     
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/kraTransportCer
    t.p12 <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/cert-<old_DRM_instance>/config
    2. Use the old standalone certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    3. Use the old standalone certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    4. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp 
      <old_server_root>/cert-<old_DRM_instance>/config/caSigningCert.b
      64 <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> kraStorageCert.p12
     
    chown <new_user>:<new_group> kraTransportCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 kraStorageCert.p12
     
    chmod 00600 kraTransportCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  7. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_DRM_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraStorageCert cert-<new_DRM_instance>" -t 
    "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraTransportCert cert-<new_DRM_instance>" 
    -t "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_DRM_instance>" -t 
    "CT,c," -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  5. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=<new_HSM_slot_name>:kraStorageCert 
cert-<new_DRM_instance>
 
kra.transportUnit.nickName=<new_HSM_slot_name>:kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    

CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7

Click below to choose the subsystem to migrate:

CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [CA]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 - [CA] Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_CA_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    cp <old_server_root>/cert-<old_CA_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    Note: Since <old_CA_instance>=<new_CA_instance>, no further 
    references will be made to <old_CA_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_CA_instance> cu,cu,cu
    caSigningCert cert-<new_CA_instance> cu,cu,cu
    ocspSigningCert cert-<new_CA_instance> CTu,Cu,Cu
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Remove the "cert7.db" by executing the specified command:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    
  2. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=ocspSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=caSigningCert cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case II: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [CA] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_CA_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    cp <old_server_root>/cert-<old_CA_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_CA_instance> cu,cu,cu
    caSigningCert cert-<old_CA_instance> cu,cu,cu
    ocspSigningCert cert-<old_CA_instance> CTu,Cu,Cu
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_CA_instance>" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    caSigningCert.p12 -n "caSigningCert cert-<old_CA_instance>" -d . 
    -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    ocspSigningCert.p12 -n "ocspSigningCert cert-<old_CA_instance>" 
    -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  2. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  3. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  4. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_CA_instance>" -t 
    "CTu,Cu,Cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:ocspSigningCe
rt cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    
Case III: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [CA] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/caSigningCert.p1
    2 <new_server_root>/alias/caSigningCert.p12
     
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/ocspSigningCert.
    p12 <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    
  5. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  6. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  7. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_CA_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "caSigningCert cert-<new_CA_instance>" -t "CTu,CTu,CTu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "ocspSigningCert cert-<new_CA_instance>" -t "CTu,Cu,Cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  8. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=ocspSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=caSigningCert cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case IV: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [CA] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/caSigningCert.p1
    2 <new_server_root>/alias/caSigningCert.p12
     
    cp 
    <old_server_root>/cert-<old_CA_instance>/config/ocspSigningCert.
    p12 <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    
  5. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  6. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_CA_instance>" -t 
    "CTu,Cu,Cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:ocspSigningCe
rt cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 

 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    

CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [DRM]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [DRM] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_DRM_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    cp <old_server_root>/cert-<old_DRM_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    Note: Since <old_DRM_instance>=<new_DRM_instance>, no further 
    references will be made to <old_DRM_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_DRM_instance> cu,cu,cu
    caSigningCert cert-<new_DRM_instance> CT,c,
    kraStorageCert cert-<new_DRM_instance> u,u,u
    kraTransportCert cert-<new_DRM_instance> u,u,u
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Remove the "cert7.db" by executing the specified command:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    
  2. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=kraStorageCert cert-<new_DRM_instance>
 
kra.transportUnit.nickName=kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    
Case II: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [DRM] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_DRM_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    cp <old_server_root>/cert-<old_DRM_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_DRM_instance> cu,cu,cu
    caSigningCert cert-<old_DRM_instance> cT,c,
    kraStorageCert cert-<old_DRM_instance> u,u,u
    kraTransportCert cert-<old_DRM_instance> u,u,u
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    kraStorageCert.p12 -n "kraStorageCert cert-<old_DRM_instance>" 
    -d . -P cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    kraTransportCert.p12 -n "kraTransportCert 
    cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  2. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "caSigningCert cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -a > caSigningCert.b64
     
    Note: The old software security databases may contain additional public keys that also 
    need to be extracted using this command.
     
    
  3. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  4. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  5. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_DRM_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraStorageCert cert-<new_DRM_instance>" -t 
    "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraTransportCert cert-<new_DRM_instance>" 
    -t "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_DRM_instance>" -t 
    "CT,c," -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  6. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  7. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=<new_HSM_slot_name>:kraStorageCert 
cert-<new_DRM_instance>
 
kra.transportUnit.nickName=<new_HSM_slot_name>:kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    
Case III: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [DRM] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/kraStorageCert.
    p12 <new_server_root>/alias/kraStorageCert.p12
     
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/kraTransportCer
    t.p12 <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/cert-<old_DRM_instance>/config
    2. Use the old standalone certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    3. Use the old standalone certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    4. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp 
      <old_server_root>/cert-<old_DRM_instance>/config/caSigningCert.b
      64 <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> kraStorageCert.p12
     
    chown <new_user>:<new_group> kraTransportCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 kraStorageCert.p12
     
    chmod 00600 kraTransportCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_DRM_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "kraStorageCert cert-<new_DRM_instance>" -t "u,u,u" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "kraTransportCert cert-<new_DRM_instance>" -t "u,u,u" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
  9. Import the public key of the entry from the base-64 file, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "caSigningCert cert-<new_DRM_instance>" -t "CT,c," -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -i caSigningCert.b64
     
    
  10. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
     
    
  11. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=kraStorageCert cert-<new_DRM_instance>
 
kra.transportUnit.nickName=kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    
Case IV: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [DRM] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/kraStorageCert.
    p12 <new_server_root>/alias/kraStorageCert.p12
     
    cp 
    <old_server_root>/cert-<old_DRM_instance>/config/kraTransportCer
    t.p12 <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/cert-<old_DRM_instance>/config
    2. Use the old standalone certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    3. Use the old standalone certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    4. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp 
      <old_server_root>/cert-<old_DRM_instance>/config/caSigningCert.b
      64 <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> kraStorageCert.p12
     
    chown <new_user>:<new_group> kraTransportCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 kraStorageCert.p12
     
    chmod 00600 kraTransportCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  7. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_DRM_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraStorageCert cert-<new_DRM_instance>" -t 
    "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraTransportCert cert-<new_DRM_instance>" 
    -t "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_DRM_instance>" -t 
    "CT,c," -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  5. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=<new_HSM_slot_name>:kraStorageCert 
cert-<new_DRM_instance>
 
kra.transportUnit.nickName=<new_HSM_slot_name>:kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    

CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [OCSP]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [OCSP] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_OCSP_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert7.db
     
    cp <old_server_root>/cert-<old_OCSP_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    Note: Since <old_OCSP_instance>=<new_OCSP_instance>, no further 
    references will be made to <old_OCSP_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_OCSP_instance> cu,cu,cu
    caSigningCert cert-<new_OCSP_instance> CT,c,
    ocspSigningCert cert-<new_OCSP_instance> cu,cu,cu
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Remove the "cert7.db" by executing the specified command:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert7.db
     
    
  2. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    
Case II: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [OCSP] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_OCSP_instance>/config/cert7.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert7.db
     
    cp <old_server_root>/cert-<old_OCSP_instance>/config/key3.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_OCSP_instance> cu,cu,cu
    caSigningCert cert-<old_OCSP_instance> CT,c,
    ocspSigningCert cert-<old_OCSP_instance> cu,cu,cu
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    ocspSigningCert.p12 -n "ocspSigningCert 
    cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  2. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "caSigningCert cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -a > caSigningCert.b64
     
    Note: The old software security databases may contain additional public keys that also 
    need to be extracted using this command.
     
    
  3. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert7.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  4. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  5. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_OCSP_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_OCSP_instance>" 
    -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_OCSP_instance>" -t 
    "CT,c," -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  6. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  7. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=<new_HSM_slot_name>:ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    
Case III: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [OCSP] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_OCSP_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_OCSP_instance>/config/ocspSigningCer
    t.p12 <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/cert-<old_OCSP_instance>/config
    2. Use the old standalone certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    3. Use the old standalone certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" -d 
      . -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    4. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp 
      <old_server_root>/cert-<old_OCSP_instance>/config/caSigningCert.
      b64 <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_OCSP_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "ocspSigningCert cert-<new_OCSP_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
  9. Import the public key of the entry from the base-64 file, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "caSigningCert cert-<new_OCSP_instance>" -t "CT,c," -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -i caSigningCert.b64
     
    
  10. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  11. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    
Case IV: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [OCSP] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/cert-<old_OCSP_instance>/config/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp 
    <old_server_root>/cert-<old_OCSP_instance>/config/ocspSigningCer
    t.p12 <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/cert-<old_OCSP_instance>/config
    2. Use the old standalone certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    3. Use the old standalone certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" -d 
      . -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    4. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp 
      <old_server_root>/cert-<old_OCSP_instance>/config/caSigningCert.
      b64 <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  7. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_OCSP_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_OCSP_instance>" 
    -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_OCSP_instance>" -t 
    "CT,c," -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  5. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=<new_HSM_slot_name>:ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    

CMS 6.0

Click below to choose the subsystem to migrate:

CMS 6.0 [CA]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 6.0 [CA] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ce
    rt7.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ke
    y3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    Note: Since <old_CA_instance>=<new_CA_instance>, no further 
    references will be made to <old_CA_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_CA_instance> cu,cu,cu
    caSigningCert cert-<new_CA_instance> cu,cu,cu
    ocspSigningCert cert-<new_CA_instance> CTu,Cu,Cu
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Remove the "cert7.db" by executing the specified command:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    
  2. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=ocspSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=caSigningCert cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case II: CMS 6.0 [CA] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ce
    rt7.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ke
    y3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_CA_instance> cu,cu,cu
    caSigningCert cert-<old_CA_instance> cu,cu,cu
    ocspSigningCert cert-<old_CA_instance> CTu,Cu,Cu
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_CA_instance>" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    caSigningCert.p12 -n "caSigningCert cert-<old_CA_instance>" -d . 
    -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    ocspSigningCert.p12 -n "ocspSigningCert cert-<old_CA_instance>" 
    -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  2. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt7.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  3. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  4. Identify the new HSM slot name by executing the following command:
    <new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb 
    -list
     
    
  5. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_CA_instance>" -t 
    "CTu,Cu,Cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  9. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:ocspSigningCe
rt cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    
Case III: CMS 6.0 [CA] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/caSigningCert.p12 
    <new_server_root>/alias/caSigningCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    
  5. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  6. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  7. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_CA_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "caSigningCert cert-<new_CA_instance>" -t "CTu,CTu,CTu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "ocspSigningCert cert-<new_CA_instance>" -t "CTu,Cu,Cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  8. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=ocspSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=caSigningCert cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case IV: CMS 6.0 [CA] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/caSigningCert.p12 
    <new_server_root>/alias/caSigningCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    
  5. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  6. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_CA_instance>" -t 
    "CTu,Cu,Cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:ocspSigningCe
rt cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    

CMS 6.0 [DRM]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 6.0 [DRM] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-c
    ert7.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-k
    ey3.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    Note: Since <old_DRM_instance>=<new_DRM_instance>, no further 
    references will be made to <old_DRM_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_DRM_instance> cu,cu,cu
    caSigningCert cert-<new_DRM_instance> CT,c,
    kraStorageCert cert-<new_DRM_instance> u,u,u
    kraTransportCert cert-<new_DRM_instance> u,u,u
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Remove the "cert7.db" by executing the specified command:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    
  2. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=kraStorageCert cert-<new_DRM_instance>
 
kra.transportUnit.nickName=kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    
Case II: CMS 6.0 [DRM] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-c
    ert7.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-k
    ey3.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_DRM_instance> cu,cu,cu
    caSigningCert cert-<old_DRM_instance> cT,c,
    kraStorageCert cert-<old_DRM_instance> u,u,u
    kraTransportCert cert-<old_DRM_instance> u,u,u
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    kraStorageCert.p12 -n "kraStorageCert cert-<old_DRM_instance>" 
    -d . -P cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    kraTransportCert.p12 -n "kraTransportCert 
    cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  2. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "caSigningCert cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -a > caSigningCert.b64
     
    Note: The old software security databases may contain additional public keys that also 
    need to be extracted using this command.
     
    
  3. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert7.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  4. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  5. Identify the new HSM slot name by executing the following command:
    <new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb 
    -list
     
    
  6. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
  7. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  8. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  9. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_DRM_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraStorageCert cert-<new_DRM_instance>" -t 
    "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraTransportCert cert-<new_DRM_instance>" 
    -t "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  10. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_DRM_instance>" -t 
    "CT,c," -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  11. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  12. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=<new_HSM_slot_name>:kraStorageCert 
cert-<new_DRM_instance>
 
kra.transportUnit.nickName=<new_HSM_slot_name>:kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    
Case III: CMS 6.0 [DRM] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/kraStorageCert.p12 
    <new_server_root>/alias/kraStorageCert.p12
     
    cp <old_server_root>/alias/kraTransportCert.p12 
    <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> kraStorageCert.p12
     
    chown <new_user>:<new_group> kraTransportCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 kraStorageCert.p12
     
    chmod 00600 kraTransportCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_DRM_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "kraStorageCert cert-<new_DRM_instance>" -t "u,u,u" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "kraTransportCert cert-<new_DRM_instance>" -t "u,u,u" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
  9. Import the public key of the entry from the base-64 file, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "caSigningCert cert-<new_DRM_instance>" -t "CT,c," -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -i caSigningCert.b64
     
    
  10. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  11. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=kraStorageCert cert-<new_DRM_instance>
 
kra.transportUnit.nickName=kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    
Case IV: CMS 6.0 [DRM] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/kraStorageCert.p12 
    <new_server_root>/alias/kraStorageCert.p12
     
    cp <old_server_root>/alias/kraTransportCert.p12 
    <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> kraStorageCert.p12
     
    chown <new_user>:<new_group> kraTransportCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 kraStorageCert.p12
     
    chmod 00600 kraTransportCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  7. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_DRM_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraStorageCert cert-<new_DRM_instance>" -t 
    "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraTransportCert cert-<new_DRM_instance>" 
    -t "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_DRM_instance>" -t 
    "CT,c," -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  5. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=<new_HSM_slot_name>:kraStorageCert 
cert-<new_DRM_instance>
 
kra.transportUnit.nickName=<new_HSM_slot_name>:kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    

CMS 6.0 [OCSP]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 6.0 [OCSP] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    cert7.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert7.db
     
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    key3.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    Note: Since <old_OCSP_instance>=<new_OCSP_instance>, no further 
    references will be made to <old_OCSP_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_OCSP_instance> cu,cu,cu
    caSigningCert cert-<new_OCSP_instance> CT,c,
    ocspSigningCert cert-<new_OCSP_instance> cu,cu,cu
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Remove the "cert7.db" by executing the specified command:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert7.db
     
    
  2. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    
Case II: CMS 6.0 [OCSP] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    cert7.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert7.db
     
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    key3.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-cert7.db
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-cert7.db
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    
     
    
  5. Convert the "cert7.db" to "cert8.db" by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -X -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_OCSP_instance> cu,cu,cu
    caSigningCert cert-<old_OCSP_instance> CT,c,
    ocspSigningCert cert-<old_OCSP_instance> cu,cu,cu
Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
  1. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    ocspSigningCert.p12 -n "ocspSigningCert 
    cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  2. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "caSigningCert cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -a > caSigningCert.b64
     
    Note: The old software security databases may contain additional public keys that also 
    need to be extracted using this command.
     
    
  3. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert7.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  4. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  5. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_OCSP_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_OCSP_instance>" 
    -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_OCSP_instance>" -t 
    "CT,c," -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  6. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  7. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=<new_HSM_slot_name>:ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    
Case III: CMS 6.0 [OCSP] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" -d 
      . -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_OCSP_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "ocspSigningCert cert-<new_OCSP_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
  9. Import the public key of the entry from the base-64 file, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "caSigningCert cert-<new_OCSP_instance>" -t "CT,c," -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -i caSigningCert.b64
     
    
  10. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  11. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    
Case IV: CMS 6.0 [OCSP] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" -d 
      . -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  7. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_OCSP_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_OCSP_instance>" 
    -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_OCSP_instance>" -t 
    "CT,c," -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  5. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=<new_HSM_slot_name>:ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.

 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    

CMS 6.1, or CMS 6.2

Click below to choose the subsystem to migrate:

CMS 6.1, or CMS 6.2 [CA]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 6.1, or CMS 6.2 [CA] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ce
    rt8.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ke
    y3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    Note: Since <old_CA_instance>=<new_CA_instance>, no further 
    references will be made to <old_CA_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the certificate database by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
        Server-Cert cert-<new_CA_instance> cu,cu,cu
     
        caSigningCert cert-<new_CA_instance> cu,cu,cu
     
        ocspSigningCert cert-<new_CA_instance> CTu,Cu,Cu
     
    
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=ocspSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=caSigningCert cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case II: CMS 6.1, or CMS 6.2 [CA] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ce
    rt8.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ke
    y3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
        Server-Cert cert-<old_CA_instance> cu,cu,cu
     
        caSigningCert cert-<old_CA_instance> cu,cu,cu
     
        ocspSigningCert cert-<old_CA_instance> CTu,Cu,Cu
     
    
  6. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_CA_instance>" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    caSigningCert.p12 -n "caSigningCert cert-<old_CA_instance>" -d . 
    -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    ocspSigningCert.p12 -n "ocspSigningCert cert-<old_CA_instance>" 
    -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  7. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  8. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  9. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_CA_instance>" -t 
    "CTu,Cu,Cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:ocspSigningCe
rt cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    
Case III: CMS 6.1, or CMS 6.2 [CA] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/caSigningCert.p12 
    <new_server_root>/alias/caSigningCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    
  5. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  6. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  7. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_CA_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "caSigningCert cert-<new_CA_instance>" -t "CTu,CTu,CTu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "ocspSigningCert cert-<new_CA_instance>" -t "CTu,Cu,Cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  8. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=ocspSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=caSigningCert cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case IV: CMS 6.1, or CMS 6.2 [CA] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/caSigningCert.p12 
    <new_server_root>/alias/caSigningCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    
  5. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  6. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_CA_instance>" -t 
    "CTu,Cu,Cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:ocspSigningCe
rt cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    

CMS 6.1, or CMS 6.2 [DRM]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 6.1, or CMS 6.2 [DRM] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-c
    ert8.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-k
    ey3.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    Note: Since <old_DRM_instance>=<new_DRM_instance>, no further 
    references will be made to <old_DRM_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_DRM_instance> cu,cu,cu
    caSigningCert cert-<new_DRM_instance> CT,c,
    kraStorageCert cert-<new_DRM_instance> u,u,u
    kraTransportCert cert-<new_DRM_instance> u,u,u
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=kraStorageCert cert-<new_DRM_instance>
 
kra.transportUnit.nickName=kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    
Case II: CMS 6.1, or CMS 6.2 [DRM] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-c
    ert8.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-k
    ey3.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_DRM_instance> cu,cu,cu
    caSigningCert cert-<old_DRM_instance> cT,c,
    kraStorageCert cert-<old_DRM_instance> u,u,u
    kraTransportCert cert-<old_DRM_instance> u,u,u
  6. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    kraStorageCert.p12 -n "kraStorageCert cert-<old_DRM_instance>" 
    -d . -P cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    kraTransportCert.p12 -n "kraTransportCert 
    cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  7. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "caSigningCert cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -a > caSigningCert.b64
     
    Note: The old software security databases may contain additional public keys that also 
    need to be extracted using this command.
     
    
  8. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  9. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  10. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_DRM_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraStorageCert cert-<new_DRM_instance>" -t 
    "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraTransportCert cert-<new_DRM_instance>" 
    -t "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_DRM_instance>" -t 
    "CT,c," -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  6. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  7. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=<new_HSM_slot_name>:kraStorageCert 
cert-<new_DRM_instance>
 
kra.transportUnit.nickName=<new_HSM_slot_name>:kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    
Case III: CMS 6.1, or CMS 6.2 [DRM] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/kraStorageCert.p12 
    <new_server_root>/alias/kraStorageCert.p12
     
    cp <old_server_root>/alias/kraTransportCert.p12 
    <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> kraStorageCert.p12
     
    chown <new_user>:<new_group> kraTransportCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 kraStorageCert.p12
     
    chmod 00600 kraTransportCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_DRM_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "kraStorageCert cert-<new_DRM_instance>" -t "u,u,u" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "kraTransportCert cert-<new_DRM_instance>" -t "u,u,u" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
  9. Import the public key of the entry from the base-64 file, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "caSigningCert cert-<new_DRM_instance>" -t "CT,c," -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -i caSigningCert.b64
     
    
  10. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  11. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=kraStorageCert cert-<new_DRM_instance>
 
kra.transportUnit.nickName=kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    
Case IV: CMS 6.1, or CMS 6.2 [DRM] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/kraStorageCert.p12 
    <new_server_root>/alias/kraStorageCert.p12
     
    cp <old_server_root>/alias/kraTransportCert.p12 
    <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> kraStorageCert.p12
     
    chown <new_user>:<new_group> kraTransportCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 kraStorageCert.p12
     
    chmod 00600 kraTransportCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  7. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_DRM_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraStorageCert cert-<new_DRM_instance>" -t 
    "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraTransportCert cert-<new_DRM_instance>" 
    -t "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_DRM_instance>" -t 
    "CT,c," -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  5. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=<new_HSM_slot_name>:kraStorageCert 
cert-<new_DRM_instance>
 
kra.transportUnit.nickName=<new_HSM_slot_name>:kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    

CMS 6.1, or CMS 6.2 [OCSP]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 6.1, or CMS 6.2 [OCSP] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    cert8.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    key3.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    Note: Since <old_OCSP_instance>=<new_OCSP_instance>, no further 
    references will be made to <old_OCSP_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_OCSP_instance> cu,cu,cu
    caSigningCert cert-<new_OCSP_instance> CT,c,
    ocspSigningCert cert-<new_OCSP_instance> cu,cu,cu
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    
Case II: CMS 6.1, or CMS 6.2 [OCSP] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    cert8.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    key3.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the old software software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
        Server-Cert cert-<old_OCSP_instance> cu,cu,cu
     
        caSigningCert cert-<old_OCSP_instance> CT,c,
     
        ocspSigningCert cert-<old_OCSP_instance> cu,cu,cu
     
    
  6. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    ocspSigningCert.p12 -n "ocspSigningCert 
    cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  7. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "caSigningCert cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -a > caSigningCert.b64
     
    Note: The old software security databases may contain additional public keys that also 
    need to be extracted using this command.
     
    
  8. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  9. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  10. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_OCSP_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_OCSP_instance>" 
    -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_OCSP_instance>" -t 
    "CT,c," -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  6. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  7. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=<new_HSM_slot_name>:ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    
Case III: CMS 6.1, or CMS 6.2 [OCSP] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" -d 
      . -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_OCSP_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "ocspSigningCert cert-<new_OCSP_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
  9. Import the public key of the entry from the base-64 file, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "caSigningCert cert-<new_OCSP_instance>" -t "CT,c," -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -i caSigningCert.b64
     
    
  10. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  11. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    
Case IV: CMS 6.1, or CMS 6.2 [OCSP] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" -d 
      . -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  7. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_OCSP_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_OCSP_instance>" 
    -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_OCSP_instance>" -t 
    "CT,c," -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  5. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=<new_HSM_slot_name>:ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    

CMS 7.0, or CS 7.1

Click below to choose the subsystem to migrate:

CMS 7.0, or CS 7.1 [CA]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 7.0, or CS 7.1 - [CA] Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ce
    rt8.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ke
    y3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    Note: Since <old_CA_instance>=<new_CA_instance>, no further 
    references will be made to <old_CA_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the certificate database by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_CA_instance> cu,cu,cu
    caSigningCert cert-<new_CA_instance> cu,cu,cu
    ocspSigningCert cert-<new_CA_instance> CTu,Cu,Cu
    subsystemCert cert-<new_CA_instance> cu,cu,cu
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=ocspSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=caSigningCert cert-<new_CA_instance>
 
Note: The subsystemCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case II: CMS 7.0, or CS 7.1 [CA] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ce
    rt8.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    cp 
    <old_server_root>/alias/cert-<old_CA_instance>-<old_hostname>-ke
    y3.db 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_CA_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_CA_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_CA_instance> cu,cu,cu
    caSigningCert cert-<old_CA_instance> cu,cu,cu
    ocspSigningCert cert-<old_CA_instance> CTu,Cu,Cu
    subsystemCert cert-<old_CA_instance> cu,cu,cu
  6. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_CA_instance>" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    caSigningCert.p12 -n "caSigningCert cert-<old_CA_instance>" -d . 
    -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    ocspSigningCert.p12 -n "ocspSigningCert cert-<old_CA_instance>" 
    -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    subsystemCert.p12 -n "subsystemCert cert-<old_CA_instance>" -d . 
    -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  7. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce
    rt8.db
     
    rm 
    <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ke
    y3.db
     
    
  8. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  9. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    subsystemCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    rm <new_server_root>/alias/subsystemCert.p12
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_CA_instance>" -t 
    "CTu,Cu,Cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:subsystemCert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:ocspSigningCe
rt cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
Note: The subsystemCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    
Case III: CMS 7.0, or CS 7.1 [CA] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/caSigningCert.p12 
    <new_server_root>/alias/caSigningCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    cp <old_server_root>/alias/subsystemCert.p12 
    <new_server_root>/alias/subsystemCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    chown <new_user>:<new_group> subsystemCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    chmod 00600 subsystemCert.p12
     
    
  5. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    subsystemCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  6. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    rm <new_server_root>/alias/subsystemCert.p12
     
    
  7. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_CA_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "caSigningCert cert-<new_CA_instance>" -t "CTu,CTu,CTu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "ocspSigningCert cert-<new_CA_instance>" -t "CTu,Cu,Cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "subsystemCert cert-<new_CA_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_CA_instance>-<new_hostname>-
     
    
  8. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=caSigningCert cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=ocspSigningCert 
cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=caSigningCert cert-<new_CA_instance>
 
Note: The subsystemCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    servercertnickname="Server-Cert cert-<new_CA_instance>"
     
    
Case IV: CMS 7.0, or CS 7.1 [CA] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/caSigningCert.p12 
    <new_server_root>/alias/caSigningCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    cp <old_server_root>/alias/subsystemCert.p12 
    <new_server_root>/alias/subsystemCert.p12
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    chown <new_user>:<new_group> subsystemCert.p12
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    chmod 00600 subsystemCert.p12
     
    
  5. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  6. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    caSigningCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_CA_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    subsystemCert.p12 -d . -P cert-<new_CA_instance>-<new_hostname>- 
    -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/caSigningCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    rm <new_server_root>/alias/subsystemCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_CA_instance>" -t 
    "CTu,CTu,CTu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_CA_instance>" -t 
    "CTu,Cu,Cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:subsystemCert cert-<new_CA_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_CA_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_CA_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
ca.ocsp_signing.cacertnickname=<new_HSM_slot_name>:ocspSigningCe
rt cert-<new_CA_instance>
 
If, there is CA-DRM connectivity, then modify the following 
name/value pair:
 
ca.connector.KRA.nickName=<new_HSM_slot_name>:caSigningCert 
cert-<new_CA_instance>
 
Note: The subsystemCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_CA_instance>"
     
    

CMS 7.0, or CS 7.1 [DRM]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 7.0, or CS 7.1 [DRM] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-c
    ert8.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-k
    ey3.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    Note: Since <old_DRM_instance>=<new_DRM_instance>, no further 
    references will be made to <old_DRM_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_DRM_instance> cu,cu,cu
    caSigningCert cert-<new_DRM_instance> CT,c,
    kraStorageCert cert-<new_DRM_instance> u,u,u
    kraTransportCert cert-<new_DRM_instance> u,u,u
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=kraStorageCert cert-<new_DRM_instance>
 
kra.transportUnit.nickName=kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    
Case II: CMS 7.0, or CS 7.1 [DRM] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-c
    ert8.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    cp 
    <old_server_root>/alias/cert-<old_DRM_instance>-<old_hostname>-k
    ey3.db 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_DRM_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_DRM_instance> cu,cu,cu
    caSigningCert cert-<old_DRM_instance> cT,c,
    kraStorageCert cert-<old_DRM_instance> u,u,u
    kraTransportCert cert-<old_DRM_instance> u,u,u
  6. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    kraStorageCert.p12 -n "kraStorageCert cert-<old_DRM_instance>" 
    -d . -P cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    kraTransportCert.p12 -n "kraTransportCert 
    cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  7. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "caSigningCert cert-<old_DRM_instance>" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -a > caSigningCert.b64
     
    Note: The old software security databases may contain additional public keys that also 
    need to be extracted using this command.
     
    
  8. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-k
    ey3.db
     
    
  9. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  10. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_DRM_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraStorageCert cert-<new_DRM_instance>" -t 
    "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraTransportCert cert-<new_DRM_instance>" 
    -t "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_DRM_instance>" -t 
    "CT,c," -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  6. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  7. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=<new_HSM_slot_name>:kraStorageCert 
cert-<new_DRM_instance>
 
kra.transportUnit.nickName=<new_HSM_slot_name>:kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    
Case III: CMS 7.0, or CS 7.1 [DRM] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/kraStorageCert.p12 
    <new_server_root>/alias/kraStorageCert.p12
     
    cp <old_server_root>/alias/kraTransportCert.p12 
    <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> kraStorageCert.p12
     
    chown <new_user>:<new_group> kraTransportCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 kraStorageCert.p12
     
    chmod 00600 kraTransportCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_DRM_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "kraStorageCert cert-<new_DRM_instance>" -t "u,u,u" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "kraTransportCert cert-<new_DRM_instance>" -t "u,u,u" -d . -P 
    cert-<new_DRM_instance>-<new_hostname>-
     
    
  9. Import the public key of the entry from the base-64 file, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "caSigningCert cert-<new_DRM_instance>" -t "CT,c," -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -i caSigningCert.b64
     
    
  10. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  11. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=kraStorageCert cert-<new_DRM_instance>
 
kra.transportUnit.nickName=kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    servercertnickname="Server-Cert cert-<new_DRM_instance>"
     
    
Case IV: CMS 7.0, or CS 7.1 [DRM] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/kraStorageCert.p12 
    <new_server_root>/alias/kraStorageCert.p12
     
    cp <old_server_root>/alias/kraTransportCert.p12 
    <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_DRM_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> kraStorageCert.p12
     
    chown <new_user>:<new_group> kraTransportCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 kraStorageCert.p12
     
    chmod 00600 kraTransportCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  7. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraStorageCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P 
    cert-<new_DRM_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/kraStorageCert.p12
     
    rm <new_server_root>/alias/kraTransportCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_DRM_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraStorageCert cert-<new_DRM_instance>" -t 
    "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:kraTransportCert cert-<new_DRM_instance>" 
    -t "u,u,u" -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_DRM_instance>" -t 
    "CT,c," -d . -P cert-<new_DRM_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  5. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_DRM_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=<new_HSM_slot_name>:kraStorageCert 
cert-<new_DRM_instance>
 
kra.transportUnit.nickName=<new_HSM_slot_name>:kraTransportCert 
cert-<new_DRM_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_DRM_instance>"
     
    

CMS 7.0, or CS 7.1 [OCSP]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 7.0, or CS 7.1 [OCSP] - Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    cert8.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    key3.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    Note: Since <old_OCSP_instance>=<new_OCSP_instance>, no further 
    references will be made to <old_OCSP_instance>.
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    Server-Cert cert-<new_OCSP_instance> cu,cu,cu
    caSigningCert cert-<new_OCSP_instance> CT,c,
    ocspSigningCert cert-<new_OCSP_instance> cu,cu,cu
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    
Case II: CMS 7.0, or CS 7.1 [OCSP] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    cert8.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    cp 
    <old_server_root>/alias/cert-<old_OCSP_instance>-<old_hostname>-
    key3.db 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_OCSP_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_OCSP_instance> cu,cu,cu
    caSigningCert cert-<old_OCSP_instance> CT,c,
    ocspSigningCert cert-<old_OCSP_instance> cu,cu,cu
  6. Extract the public/private key pairs of each entry from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -o 
    ocspSigningCert.p12 -n "ocspSigningCert 
    cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: The old software security databases may contain additional public/private key 
    pairs that also need to be extracted using this command.
     
    
  7. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "caSigningCert cert-<old_OCSP_instance>" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -a > caSigningCert.b64
     
    Note: The old software security databases may contain additional public keys that also 
    need to be extracted using this command.
     
    
  8. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    cert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>-
    key3.db
     
    
  9. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  10. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_OCSP_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_OCSP_instance>" 
    -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  5. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_OCSP_instance>" -t 
    "CT,c," -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  6. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  7. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=<new_HSM_slot_name>:ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    
Case III: CMS 7.0, or CS 7.1 [OCSP] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" -d 
      . -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_OCSP_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "ocspSigningCert cert-<new_OCSP_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>-
     
    
  9. Import the public key of the entry from the base-64 file, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "caSigningCert cert-<new_OCSP_instance>" -t "CT,c," -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -i caSigningCert.b64
     
    
  10. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  11. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    servercertnickname="Server-Cert cert-<new_OCSP_instance>"
     
    
Case IV: CMS 7.0, or CS 7.1 [OCSP] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    cp <old_server_root>/alias/ocspSigningCert.p12 
    <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" from the old security databases and save the base-64 encoded output to a file called caSigningCert.b64:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entry from the security databases and save the base-64 output to a file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_OCSP_instance>" -d 
      . -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> ocspSigningCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 ocspSigningCert.p12
     
    chmod 00600 caSigningCert.b64
     
    
  6. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  7. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    <new_server_root>/bin/cert/tools/pk12util.sh -i 
    ocspSigningCert.p12 -d . -P 
    cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 files:
    rm <new_server_root>/alias/ServerCert.p12
     
    rm <new_server_root>/alias/ocspSigningCert.p12
     
    
  3. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_OCSP_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:ocspSigningCert cert-<new_OCSP_instance>" 
    -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_OCSP_instance>" -t 
    "CT,c," -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
  5. Optionally, delete the base-64 file:
    rm <new_server_root>/alias/caSigningCert.b64
     
    
  6. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_OCSP_instance>/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ocsp.signing.certnickname=<new_HSM_slot_name>:ocspSigningCert 
cert-<new_OCSP_instance>
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_OCSP_instance>"
     
    

CMS 7.0, or CS 7.1 [TKS]

Determine if the migration to be performed involves software security databases, an HSM, or both. Click on the appropriate case out of the following four migration techniques that applies to your specific situation:

Case I: CMS 7.0, or CS 7.1 - [TKS] Software (old server) --> Software (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Login as the <old_user> on the machine hosting the old server.
  3. If you wish to migrate a master key from your old TKS instance, perform the following steps:
If the migration is from CMS 7.0, view the file entitled <old_server_root>/cert-<old_TKS_instance>/config/CMS.cfg.
Otherwise, if the migration is from CS 7.1, view the file entitled <old_server_root>/cert-<old_TKS_instance>/config/CS.cfg.
In either case, write down the exact name=value pair for the line that looks like "tks.mk_mappings.#<tks_master_key_version_number>#01=internal:<tks_master_key_version_name>".
An example name/value pair should look something similar to this:
tks.mk_mappings.#02#01=internal:tks_master_key_v2
 
where "02" represents the <tks_master_key_version_ number>, and "tks_master_key_v2" represents the <tks_master_key_version_name>.
  1. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_TKS_instance>-<old_hostname>-c
    ert8.db 
    <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-c
    ert8.db
     
    cp 
    <old_server_root>/alias/cert-<old_TKS_instance>-<old_hostname>-k
    ey3.db 
    <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-k
    ey3.db
     
    Note: Since <old_TKS_instance>=<new_TKS_instance>, no further 
    references will be made to <old_TKS_instance>.
     
    
  2. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  3. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_TKS_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_TKS_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_TKS_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_TKS_instance>-<new_hostname>-key3.db
     
    
  4. List the contents of the software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_TKS_instance>-<new_hostname>-
     
        Server-Cert cert-<new_TKS_instance> cu,cu,cu
     
        caSigningCert cert-<new_TKS_instance> CT,c,
     
        tksTransportCert cert-<new_TKS_instance> CT,C,
     
    
  5. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_TKS_instance>/config
     
    
If you have enabled server-side keygen, edit the new CS.cfg, and modify the following name/value pair:
tks.drm_transport_cert_nickname=tksTransportCert 
cert-<new_TKS_instance>
 
If you have migrated a master key from your old TKS instance, 
edit the new CS.cfg, and modify the following name/value pair:
 
From step 2 above, insert the 
"tks.mk_mappings.#<tks_master_key_version_number>#01=internal:<t
ks_master_key_version_name>" name/value pair as the last line in 
the new CS.cfg filling in the values of 
<tks_master_key_version_number>, and 
<tks_master_key_version_name> appropriately.
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_TKS_instance>"
     
    servercertnickname="Server-Cert cert-<new_TKS_instance>"
     
    servercertnickname="Server-Cert cert-<new_TKS_instance>"
     
    
Case II: CMS 7.0, or CS 7.1 [TKS] - Software (old server) --> HSM (new server)
  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance. For example:
    rm 
    <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-k
    ey3.db
     
    
  2. Login as the <old_user> on the machine hosting the old server.
  3. If you wish to migrate a master key from your old TKS instance, perform the following steps:
If the migration is from CMS 7.0, view the file entitled <old_server_root>/cert-<old_TKS_instance>/config/CMS.cfg.
Otherwise, if the migration is from CS 7.1, view the file entitled <old_server_root>/cert-<old_TKS_instance>/config/CS.cfg.
In either case, write down the exact name=value pair for the line that looks like "tks.mk_mappings.#<tks_master_key_version_number>#01=internal:<tks_master_key_version_name>".
An example name/value pair should look something similar to this:
tks.mk_mappings.#02#01=internal:tks_master_key_v2
 
where "02" represents the <tks_master_key_version_ number>, and "tks_master_key_v2" represents the <tks_master_key_version_name>.
  1. In order to migrate symmetric keys from your old TKS instance, the following will be needed:
    • a written copy of the value of the original three session key shares to reproduce the symmetric transport key on your old TKS instance, and
    • copies of all files (there must be at least one) containing the wrapped master keys residing in the old software security database (e. g. - tks_master_key_v2.txt).
    Note: These files would have been created whenever the user generated a new master key using the "tksTool -W" option.
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp 
    <old_server_root>/alias/cert-<old_TKS_instance>-<old_hostname>-c
    ert8.db 
    <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-c
    ert8.db
     
    cp 
    <old_server_root>/alias/cert-<old_TKS_instance>-<old_hostname>-k
    ey3.db 
    <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-k
    ey3.db
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> 
    cert-<new_TKS_instance>-<new_hostname>-cert8.db
     
    chown <new_user>:<new_group> 
    cert-<new_TKS_instance>-<new_hostname>-key3.db
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 cert-<new_TKS_instance>-<new_hostname>-cert8.db
     
    chmod 00600 cert-<new_TKS_instance>-<new_hostname>-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    <new_server_root>/bin/cert/tools/certutil.sh -L -d . -P 
    cert-<new_TKS_instance>-<new_hostname>-
     
    
    Server-Cert cert-<old_TKS_instance> cu,cu,cu
    caSigningCert cert-<old_TKS_instance> CT,c,
    tksTransportCert cert-<old_TKS_instance> CT,C,C
  6. Extract the public/private key pair from the old software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -o ServerCert.p12 
    -n "Server-Cert cert-<old_TKS_instance>" -d . -P 
    cert-<new_TKS_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
  7. Extract the two public keys of the following entries from the old software security databases and save the base-64 output of each to a file:
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "caSigningCert cert-<old_TKS_instance>" -d . -P 
    cert-<new_TKS_instance>-<new_hostname>- -a > caSigningCert.b64
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -L -n 
    "tksTransportCert cert-<old_TKS_instance>" -d . -P 
    cert-<new_TKS_instance>-<new_hostname>- -a > 
    tksTransportCert.b64
     
    
  8. Delete the old software security databases:
    rm 
    <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-c
    ert8.db
     
    rm 
    <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-k
    ey3.db
     
    
  9. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  10. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Create new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -N -d . -P 
    cert-<new_TKS_instance>-<new_hostname>-
     
    
  2. Import the public/private key pair from the PKCS #12 file into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_TKS_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  3. Optionally, delete the PKCS #12 file:
    rm <new_server_root>/alias/ServerCert.p12
     
    
  4. Set the trust bits on the public/private key pair that were imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_TKS_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_TKS_instance>-<new_hostname>- -h 
    <new_HSM_token_name
     
    
  5. Import the public keys from the base-64 files into the new HSM, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_TKS_instance>" -t 
    "CT,c," -d . -P cert-<new_TKS_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:tksTransportCert cert-<new_TKS_instance>" 
    -t "CT,C,C" -d . -P cert-<new_TKS_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i tksTransportCert.b64
     
    
  6. Optionally, delete the base-64 files:
    rm <new_server_root>/alias/caSigningCert.b64
     
    rm <new_server_root>/alias/tksTransportCert.b64
     
    
  7. Import the original symmetric transport key into the new HSM:
<new_server_root>/bin/cert/tools/tksTool.sh -I -d . -p cert-<new_TKS_instance>-<new_hostname>- -h <new_HSM_token_name> -n <tks_transport_key_name>
From step 3 above, type in the original three key session key shares (as prompted) to recreate the original transport key on the new HSM.
  1. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership) on each <wrapped_tks_master_key_file> copied from step 3 above.
  2. Unwrap and store all original master keys (from step 3 above) into the new HSM:
    <new_server_root>/bin/cert/tools/tksTool.sh -U -d . -p 
    cert-<new_TKS_instance>-<new_hostname>- -h <new_HSM_token_name> 
    -t <tks_transport_key_name> -n <tks_master_key_version_name> -i 
    <wrapped_tks_master_key_file>
     
    
Perform this step for each and every file containing a wrapped TKS master key.
  1. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_TKS_instance>/config
     
    
If you have enabled server-side keygen, edit the new CS.cfg, and modify the following name/value pair:
tks.drm_transport_cert_nickname=<new_HSM_slot_name>:tksTransport
Cert cert-<new_TKS_instance>
 
If you have migrated a master key from your old TKS instance, 
edit the new CS.cfg, and modify the following name/value pair:
 
From step 2 above, insert the 
"tks.mk_mappings.#<tks_master_key_version_number>#01=<new_HSM_sl
ot_name>:<tks_master_key_version_name>" name/value pair as the 
last line in the new CS.cfg filling in the values of 
<tks_master_key_version_number>, <new_HSM_slot_name>, and 
<tks_master_key_version_name> appropriately.
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_TKS_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_TKS_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_TKS_instance>"
     
    
Case III: CMS 7.0, or CS 7.1 [TKS] - HSM (old server) --> Software (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Login as the <old_user> on the machine hosting the old server.
  3. If you wish to migrate a master key from your old TKS instance, perform the following steps:
If the migration is from CMS 7.0, view the file entitled <old_server_root>/cert-<old_TKS_instance>/config/CMS.cfg.
Otherwise, if the migration is from CS 7.1, view the file entitled <old_server_root>/cert-<old_TKS_instance>/config/CS.cfg.
In either case, write down the exact name=value pair for the line that looks like "tks.mk_mappings.#<tks_master_key_version_number>#01=<old_HSM_slot_name>:<tks_master_key_version_name>".
An example name/value pair should look something similar to this:
tks.mk_mappings.#02#01=mu:tks_master_key_v2
 
where "02" represents the <tks_master_key_version_ number>, "mu" represents the <old_HSM_slot_name>, and "tks_master_key_v2" represents the <tks_master_key_version_name>.
  1. In order to migrate symmetric keys from your old TKS instance, the following will be needed:
    • a written copy of the value of the original three session key shares to reproduce the symmetric transport key on your old TKS instance, and
    • copies of all files (there must be at least one) containing the wrapped master keys residing on the old HSM (e. g. - tks_master_key_v2.txt).
    Note: These files would have been created whenever the user generated a new master key using the "tksTool -W" option.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_TKS_instance>" and "<old_HSM_slot_name>:tksTransportCert cert-<old_TKS_instance>" from the old security databases and save the base-64 encoded output to files called caSigningCert.b64 and tksTransportCert.b64 respectively:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entries from the security databases and save each base-64 output to a separate file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_TKS_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:tksTransportCert cert-<old_TKS_instance>" 
      -d . -h <old_HSM_token_name> -a > tksTransportCert.b64
       
      
    5. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      cp <old_server_root>/alias/tksTransportCert.b64 
      <new_server_root>/alias/tksTransportCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    chown <new_user>:<new_group> tksTransportCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.b64
     
    chmod 00600 tksTransportCert.b64
     
    
  6. Import the public/private key pair from the PKCS #12 file into the new software security databases:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_TKS_instance>-<new_hostname>-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 file:
    rm <new_server_root>/alias/ServerCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new software security databases:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n "Server-Cert 
    cert-<new_TKS_instance>" -t "cu,cu,cu" -d . -P 
    cert-<new_TKS_instance>-<new_hostname>-
     
    
  9. Import the public keys from the base-64 files, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "caSigningCert cert-<new_TKS_instance>" -t "CT,c," -d . -P 
    cert-<new_TKS_instance>-<new_hostname>- -i caSigningCert.b64
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "tksTransportCert cert-<new_TKS_instance>" -t "CT,C,C" -d . -P 
    cert-<new_TKS_instance>-<new_hostname>- -i tksTransportCert.b64
     
    
  10. Optionally, delete the base-64 files:
    rm <new_server_root>/alias/caSigningCert.b64
     
    rm <new_server_root>/alias/tksTransportCert.b64
     
    
  11. Import the original symmetric transport key into the new software security databases:
<new_server_root>/bin/cert/tools/tksTool.sh -I -d . -p cert-<new_TKS_instance>-<new_hostname>- -n <tks_transport_key_name>
From step 3 above, type in the original three key session key shares (as prompted) to recreate the original transport key in the new software security databases.
  1. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership) on each <wrapped_tks_master_key_file> copied from step 3 above.
  2. Unwrap and store all original master keys (from step 3 above) into the new software security databases:
    <new_server_root>/bin/cert/tools/tksTool.sh -U -d . -p 
    cert-<new_TKS_instance>-<new_hostname>- -t 
    <tks_transport_key_name> -n <tks_master_key_version_name> -i 
    <wrapped_tks_master_key_file>
     
    
Perform this step for each and every file containing a wrapped TKS master key.
  1. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_TKS_instance>/config
     
    
If you have enabled server-side keygen, edit the new CS.cfg, and modify the following name/value pair:
tks.drm_transport_cert_nickname=tksTransportCert 
cert-<new_TKS_instance>
 
If you have migrated a master key from your old TKS instance, 
edit the new CS.cfg, and modify the following name/value pair:
 
From step 2 above, insert the 
"tks.mk_mappings.#<tks_master_key_version_number>#01=internal:<t
ks_master_key_version_name>" name/value pair as the last line in 
the new CS.cfg filling in the values of 
<tks_master_key_version_number>, and 
<tks_master_key_version_name> appropriately.
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="Server-Cert cert-<new_TKS_instance>"
     
    servercertnickname="Server-Cert cert-<new_TKS_instance>"
     
    servercertnickname="Server-Cert cert-<new_TKS_instance>"
     
    
Case IV: CMS 7.0, or CS 7.1 [TKS] - HSM (old server) --> HSM (new server)
  1. The pk12util.sh tool cannot be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by FIPS 140-1 which protect the private key portion of an entry. Instead, you should attempt to contact your old HSM vendor in order to extract the data from your old HSM. The extracted keys should not have any dependencies upon the old HSM such as nickname prefixes.
  2. Login as the <old_user> on the machine hosting the old server.
  3. If you wish to migrate a master key from your old TKS instance, perform the following steps:
If the migration is from CMS 7.0, view the file entitled <old_server_root>/cert-<old_TKS_instance>/config/CMS.cfg.
Otherwise, if the migration is from CS 7.1, view the file entitled <old_server_root>/cert-<old_TKS_instance>/config/CS.cfg.
In either case, write down the exact name=value pair for the line that looks like "tks.mk_mappings.#<tks_master_key_version_number>#01=<old_HSM_slot_name>:<tks_master_key_version_name>".
An example name/value pair should look something similar to this:
tks.mk_mappings.#02#01=mu:tks_master_key_v2
 
where "02" represents the <tks_master_key_version_ number>, "mu" represents the <old_HSM_slot_name>, and "tks_master_key_v2" represents the <tks_master_key_version_name>.
  1. In order to migrate symmetric keys from your old TKS instance, the following will be needed:
    • a written copy of the value of the original three session key shares to reproduce the symmetric transport key on your old TKS instance, and
    • copies of all files (there must be at least one) containing the wrapped master keys residing on the old HSM (e. g. - tks_master_key_v2.txt).
    Note: These files would have been created whenever the user generated a new master key using the "tksTool -W" option.
  2. Presuming that a method exists to extract the data into something portable such as PKCS #12 files, transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/alias/ServerCert.p12 
    <new_server_root>/alias/ServerCert.p12
     
    
  3. Also, extract the public key of the "<old_HSM_slot_name>:caSigningCert cert-<old_TKS_instance>" and "<old_HSM_slot_name>:tksTransportCert cert-<old_TKS_instance>" from the old security databases and save the base-64 encoded output to files called caSigningCert.b64 and tksTransportCert.b64 respectively:
    1. cd <old_server_root>/alias
    2. Set the appropriate environment variable to search the appropriate libraries. For example, using Bourne shell on a Solaris platform:
      LD_LIBRARY_PATH=<old_server_root>/bin/cert/lib
       
      export LD_LIBRARY_PATH
       
      
    3. Use the old certutil executable to identify the old HSM slot name:
      <old_server_root>/bin/cert/tools/certutil -U -d .
       
      
    4. Use the old certutil executable to extract the public key of the following entries from the security databases and save each base-64 output to a separate file:
      <old_server_root>/bin/cert/tools/certutil -L -n 
      "<old_HSM_slot_name>:caSigningCert cert-<old_TKS_instance>" -d . 
      -h <old_HSM_token_name> -a > caSigningCert.b64
       
      
    <old_server_root>/bin/cert/tools/certutil -L -n 
    "<old_HSM_slot_name>:tksTransportCert cert-<old_TKS_instance>" 
    -d . -h <old_HSM_token_name> -a > tksTransportCert.b64
     
    
    1. Transfer this data from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
      cp <old_server_root>/alias/caSigningCert.b64 
      <new_server_root>/alias/caSigningCert.b64
       
      cp <old_server_root>/alias/tksTransportCert.b64 
      <new_server_root>/alias/tksTransportCert.b64
       
      
  4. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/alias/
     
    
  5. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> ServerCert.p12
     
    chown <new_user>:<new_group> caSigningCert.b64
     
    chown <new_user>:<new_group> tksTransportCert.b64
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 ServerCert.p12
     
    chmod 00600 caSigningCert.b64
     
    chmod 00600 tksTransportCert.b64
     
    
  6. Execute the specified command to register the new HSM in the new token database:
    <new_server_root>/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    <new_HSM_token_name> -libfile 
    <new_HSM_library_path>/<new_HSM_library>
     
    
  7. Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
  1. Import the public/private key pair from the PKCS #12 file into the new HSM:
    <new_server_root>/bin/cert/tools/pk12util.sh -i ServerCert.p12 
    -d . -P cert-<new_TKS_instance>-<new_hostname>- -h 
    <new_HSM_slot_name>
     
    Enter Password or Pin for "<new_HSM_slot_name>":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  2. Optionally, delete the PKCS #12 file:
    rm <new_server_root>/alias/ServerCert.p12
     
    
  3. Set the trust bits on the public/private key pair that was imported into the new HSM:
    <new_server_root>/bin/cert/tools/certutil.sh -M -n 
    "<new_HSM_slot_name>:Server-Cert cert-<new_TKS_instance>" -t 
    "cu,cu,cu" -d . -P cert-<new_TKS_instance>-<new_hostname>- -h 
    <new_HSM_token_name>
     
    
  4. Import the public keys from the base-64 files, and set the trust bits:
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:caSigningCert cert-<new_TKS_instance>" -t 
    "CT,c," -d . -P cert-<new_TKS_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i caSigningCert.b64
     
    
    <new_server_root>/bin/cert/tools/certutil.sh -A -n 
    "<new_HSM_slot_name>:tksTransportCert cert-<new_TKS_instance>" 
    -t "CT,C,C" -d . -P cert-<new_TKS_instance>-<new_hostname>- -h 
    <new_HSM_token_name> -i tksTransportCert.b64
     
    
  5. Optionally, delete the base-64 files:
    rm <new_server_root>/alias/caSigningCert.b64
     
    rm <new_server_root>/alias/tksTransportCert.b64
     
    
  6. Import the original symmetric transport key into the new HSM:
    <new_server_root>/bin/cert/tools/tksTool.sh -I -d . -p 
    cert-<new_TKS_instance>-<new_hostname>- -h <new_HSM_token_name> 
    -n <tks_transport_key_name>
     
    
From step 3 above, type in the original three key session key shares (as prompted) to recreate the original transport key on the new HSM.
  1. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership) on each <wrapped_tks_master_key_file> copied from step 3 above.
     
  2. Unwrap and store all original master keys (from step 3 above) into the new HSM:
    <new_server_root>/bin/cert/tools/tksTool.sh -U -d . -p 
    cert-<new_TKS_instance>-<new_hostname>- -h <new_HSM_token_name> 
    -t <tks_transport_key_name> -n <tks_master_key_version_name> -i 
    <wrapped_tks_master_key_file>
     
    
Perform this step for each and every file containing a wrapped TKS master key.
  1. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd <new_server_root>/cert-<new_TKS_instance>/config
     
    
If you have enabled server-side keygen, edit the new CS.cfg, and modify the following name/value pair:
tks.drm_transport_cert_nickname=<new_HSM_slot_name>:tksTransport
Cert cert-<new_TKS_instance>
 
If you have migrated a master key from your old TKS instance, 
edit the new CS.cfg, and modify the following name/value pair:
 
From step 2 above, insert the 
"tks.mk_mappings.#<tks_master_key_version_number>#01=<new_HSM_sl
ot_name>:<tks_master_key_version_name>" name/value pair as the 
last line in the new CS.cfg filling in the values of 
<tks_master_key_version_number>, <new_HSM_slot_name>, and 
<tks_master_key_version_name> appropriately.
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_TKS_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_TKS_instance>"
     
    servercertnickname="<new_HSM_slot_name>:Server-Cert 
    cert-<new_TKS_instance>"
     
    

Step 5: Migration of Password Cache Data and Password.conf

List the contents of pwcache.p12 (CMS 4.1, CMS 4.2, CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7) or pwcache.db (CMS 6.0, CMS 6.1, CMS 6.2, CMS 7.0, or CS 7.1) in the old instance. Fortunately, the procedures regarding migration of password cache data are identical across all CS/CMS/iCMS subsystem instances, although they must be performed individually for each CS/CMS/iCMS subsystem instance to be migrated. Click on the choice below that applies to the specific CS/CMS/iCMS version from which you are migrating:

CMS 4.1 Password Cache Data

  1. Unfortunately, no PasswordCache tool was shipped with CMS 4.1 on the Solaris and Windows platforms. However, at least on Solaris platforms, it should be possible to install a version of CMS 4.2, CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 on the same platform, and then use the PasswordCache tool from one of these CMS/iCMS servers to extract the password cache data.
     
  2. For the following instructions, assume that a version of CMS 4.2 was installed on the same Solaris machine where the CMS 4.1 instance(s) were installed. Execute the following commands:
    cd <41_server_root>/cert-<41_instance>
     
    <42_server_root>/bin/cert/tools/PasswordCache 
    <41_passwordcache_password> list
     
    ----- Password Cache -----
    
    Internal LDAP Database : <41_internal_DB_password>
    
    Internal Key Storage Token : <41_internal_key_storage_password>
     
    
Write down this information.
  1. Login as the <new_user> on the machine hosting the new server, and recreate the pwcache.db in the latest CS instance:
    1. Go to the following directory:
      cd <new_server_root>/cert-<new_instance>/config
       
      
    2. Remove the new pwcache.db (this is the original password cache file created during the configuration phase documented in Step 2: Creation of a New CS Installation).
       
    3. Generate a new protection key. To do this, execute the following command:
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password> -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      rekey
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<new_instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      generating new key...
      
      PWsdrCache: mToken = internal
      
      PWsdrCache: SDR key generated
      
      key generated successfully with key id = OPHHNSQTY0RUGFJbcaco1g==
      
      Save the VALUE portion of this key id in a local file,
      
      and under variable "pwcKeyid" in CS.cfg!!
      
      If you have not already done so,
      
      remove the old pwcache.db and use this local file to add 
      passwords.
       
      
    4. Save the value portion of the key id into a local file such as key.txt.
    5. Save the value portion of the key id into the CS.cfg file under the variable "pwcKeyid":
    6. Execute the following command to create an empty new password cache file (e. g . - Linux/UNIX):
      touch pwcache.db
       
      
    7. Add old password tags and their associated old/new passwords (from step 2 of CMS 4.1 Password Cache Data) back to the cache. You may need to do this multiple times. For example, execute the following commands:
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password>
      
      -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      -k key.txt
      
      add "Internal LDAP Database" <new_internal_DB_password>
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      adding Internal LDAP Database:<new_internal_DB_password>
      
      PWsdrCache: in addEntry
      
      about to read password cache
      
      PWsdrCache: after readPWcache()
      
      adding new tag: Internal LDAP Database
      
      operation completed for pwcache.db
       
      
       
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password>
      
      -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      -k key.txt
      
      add "Internal Key Storage Token" 
      <41_internal_key_storage_password>
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<new_instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      adding Internal Key Storage 
      Token:<41_internal_key_storage_password>
      
      PWsdrCache: in addEntry
      
      about to read password cache
      
      PWsdrCache: after readPWcache()
      
      adding new tag: Internal Key Storage Token
      
      operation completed for pwcache.db
       
      
    8. Execute the following command to confirm that everything is OK:
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password> -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      list
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<new_instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      about to read password cache
      
      ----- Password Cache Content -----
      
      Internal Key Storage Token : <41_internal_key_storage_password>
      
      Internal LDAP Database : <new_internal_DB_password>
       
      

CMS 4.2, CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 Password Cache Data

  1. Login as the <old_user> on the machine hosting the old server, and execute the following commands:
    cd <old_server_root>/cert-<old_instance>
     
    <old_server_root>/bin/cert/tools/PasswordCache 
    <old_passwordcache_password> list
     
    ----- Password Cache -----
    
    Internal LDAP Database : <old_internal_DB_password>
    
    Internal Key Storage Token : <old_internal_key_storage_password>
     
    
Write down this information.
  1. Login as the <new_user> on the machine hosting the new server, and recreate the pwcache.db in the latest CS instance:
    1. Go to the following directory:
      cd <new_server_root>/cert-<new_instance>/config
       
      
    2. Remove the new pwcache.db (this is the original password cache file created during the configuration phase documented in Step 2: Creation of a New CS Installation).
    3. Generate a new protection key. To do this, execute the following command:
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password> -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      rekey
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<new_instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      generating new key...
      
      PWsdrCache: mToken = internal
      
      PWsdrCache: SDR key generated
      
      key generated successfully with key id = OPHHNSQTY0RUGFJbcaco1g==
      
      Save the VALUE portion of this key id in a local file,
      
      and under variable "pwcKeyid" in CS.cfg!!
      
      If you have not already done so,
      
      remove the old pwcache.db and use this local file to add 
      passwords.
       
      
    4. Save the value portion of the key id into a local file such as key.txt.
    5. Save the value portion of the key id into the CS.cfg file under the variable "pwcKeyid":
    6. Execute the following command to create an empty new password cache file (e. g. - Linux/UNIX):
      touch pwcache.db
       
      
    7. Add old password tags and their associated old/new passwords (from step 1 of CMS 4.2, CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 Password Cache Data) back to the cache. You may need to do this multiple times. For example, execute the following commands:
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password>
      
      -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      -k key.txt
      
      add "Internal LDAP Database" <new_internal_DB_password>
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      adding Internal LDAP Database:<new_internal_DB_password>
      
      PWsdrCache: in addEntry
      
      about to read password cache
      
      PWsdrCache: after readPWcache()
      
      adding new tag: Internal LDAP Database
      
      operation completed for pwcache.db
       
      
       
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password>
      
      -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      -k key.txt
      
      add "Internal Key Storage Token" 
      <old_internal_key_storage_password>
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<new_instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      adding Internal Key Storage 
      Token:<old_internal_key_storage_password>
      
      PWsdrCache: in addEntry
      
      about to read password cache
      
      PWsdrCache: after readPWcache()
      
      adding new tag: Internal Key Storage Token
      
      operation completed for pwcache.db
       
      
    8. Execute the following command to confirm that everything is OK:
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password> -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      list
       
      
    Text similar to the following output should appear on the screen:
    cert/key prefix = cert-<new_instance>-<new_hostname>-
    
    cert/key db path = <new_server_root>/alias
    
    password cache file = pwcache.db
    
    token name = internal
    
    PWsdrCache: mToken = internal
    
    about to read password cache
    
    ----- Password Cache Content -----
    
    Internal Key Storage Token : <old_internal_key_storage_password>
    
    Internal LDAP Database : <new_internal_DB_password>
     
    

CMS 6.0, CMS 6.1, CMS 6.2, CMS 7.0, or CS 7.1 Password Cache Data and Password.conf

  1. Login as the <old_user> on the machine hosting the old server, and execute the following commands:
    cd <old_server_root>/cert-<old_instance>/config
     
    <old_server_root>/bin/cert/tools/PasswordCache 
    <old_passwordcache_password> -d <old_server_root>/alias
    
    -P cert-<old_instance>-<old_hostname>-
    
    list
     
    cert/key prefix = cert-<old_instance>-<old_hostname>-
    
    path = <old_server_root>/alias
    
    about to read password cache
    
    ----- Password Cache Content -----
    
    internal : <old_internal_token_password>
    
    Internal LDAP Database : <old_internal_DB_password>
     
    Write down this information.
     
    
  2. If the old server instance used an <old_server_root>/cert-<old_instance>/config/password.conf file to automatically start the server instance, then this "password.conf" file must also be migrated to the new server instance using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp <old_server_root>/cert-<old_instance>/config/password.conf 
    <new_server_root>/cert-<new_instance>/config/password.conf
     
    
  3. Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
    cd <new_server_root>/cert-<new_instance>/config
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> password.conf
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 password.conf
     
    
  5. Recreate the pwcache.db in the latest CS instance:
     
    1. Remove the new pwcache.db (this is the original password cache file created during the configuration phase documented in Step 2: Creation of a New CS Installation).
       
    2. Generate a new protection key. To do this, execute the following command:
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password> -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      rekey
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<new_instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      generating new key...
      
      PWsdrCache: mToken = internal
      
      PWsdrCache: SDR key generated
      
      key generated successfully with key id = OPHHNSQTY0RUGFJbcaco1g==
      
      Save the VALUE portion of this key id in a local file,
      
      and under variable "pwcKeyid" in CS.cfg!!
      
      If you have not already done so,
      
      remove the old pwcache.db and use this local file to add 
      passwords.
       
      
    3. Save the value portion of the key id into a local file such as key.txt.
       
    4. Save the value portion of the key id into the CS.cfg file under the variable "pwcKeyid":
       
    5. Execute the following command to create an empty new password cache file (e. g. - Linux/UNIX):
      touch pwcache.db
       
      
    6. Add old password tags and their associated old/new passwords (from step 1 of CMS 6.0, CMS 6.1, CMS 6.2, CMS 7.0, or CS 7.1 Password Cache Data and Password.conf) back to the cache. You may need to do this multiple times. For example, execute the following commands:
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password>
      
      -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      -k key.txt
      
      add "Internal LDAP Database" <new_internal_DB_password>
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      adding Internal LDAP Database:<new_internal_DB_password>
      
      PWsdrCache: in addEntry
      
      about to read password cache
      
      PWsdrCache: after readPWcache()
      
      adding new tag: Internal LDAP Database
      
      operation completed for pwcache.db
       
      
       
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password>
      
      -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      -k key.txt
      
      add "internal" <old_internal_token_password>
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<new_instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      adding internal:<old_internal_token_password>
      
      PWsdrCache: in addEntry
      
      about to read password cache
      
      PWsdrCache: after readPWcache()
      
      adding new tag: internal
      
      operation completed for pwcache.db
       
      
    7. Execute the following command to confirm that everything is OK:
      <new_server_root>/bin/cert/tools/PasswordCache 
      <new_passwordcache_password> -d <new_server_root>/alias
      
      -P cert-<new_instance>-<new_hostname>-
      
      -c pwcache.db
      
      list
      
      
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-<new_instance>-<new_hostname>-
      
      cert/key db path = <new_server_root>/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      about to read password cache
      
      ----- Password Cache Content -----
      
      internal : <old_internal_token_password>
      
      Internal LDAP Database : <new_internal_DB_password>
       
      

Step 6: Migration of Internal DB Data

Every old CS/CMS/iCMS subsystem contains LDIF data in an associated internal database which must be migrated to the corresponding new CMS subsystem's internal database. Fortunately, this procedure is subsystem independent. For each old CS/CMS/iCMS server instance to be migrated, click on the old CS/CMS/iCMS version, and follow the procedure to migrate this LDIF data:

CMS 4.1 Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
 
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
      cd <old_server_root>/bin/cert
       
      
    6. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
       
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "old.ldif":
 
cd <old_server_root>/slapd-<old_instance>-db/ldif
 
mv <dated_#_file>.ldif old.ldif 
 
  1. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Delete the first 2 entries in "old.ldif". They look like the following:
    Entry 1: <old machine domain>
     
    Entry 2: cn=ldap://:<old port>,<old machine domain>
     
    For example:
     
    Entry 1: dc=cert,dc=redhat,dc=com
     
    Entry 2: cn=ldap://:38900,dc=cert,dc=redhat,dc=com
     
    
  3. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 4.1 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd <old_server_root>/bin/cert/migrate/41ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

CMS 4.2 Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
      cd <old_server_root>/bin/cert
       
      
    6. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
       
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "old.ldif":
 
cd <old_server_root>/slapd-<old_instance>-db/ldif
 
mv <dated_#_file>.ldif old.ldif 
 
  1. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Delete the first 2 entries in "old.ldif". They look like the following:
    Entry 1: <old machine domain>
     
    Entry 2: cn=ldap://:<old port>,<old machine domain>
    
    
     
    For example:
     
    Entry 1: dc=cert,dc=redhat,dc=com
     
    Entry 2: cn=ldap://:38900,dc=cert,dc=redhat,dc=com
     
    
  3. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 4.2 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd <old_server_root>/bin/cert/migrate/42ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

CMS 4.2 (SP 2) Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
      cd <old_server_root>/bin/cert
       
      
    6. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
      
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "old.ldif":
cd <old_server_root>/slapd-<old_instance>-db/ldif
 
mv <dated_#_file>.ldif old.ldif 
 
  1. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Delete the first 2 entries in "old.ldif". They look like the following:
    Entry 1: <old machine domain>
     
    Entry 2: cn=ldap://:<old port>,<old machine domain>
     
    For example:
     
    Entry 1: dc=cert,dc=redhat,dc=com
     
    Entry 2: cn=ldap://:38900,dc=cert,dc=redhat,dc=com
     
    
  3. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 4.2 (SP 2) Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd <old_server_root>/bin/cert/migrate/42SP2ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

CMS 4.5 Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
      cd <old_server_root>/bin/cert
       
      
    6. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
      
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "old.ldif":
 
cd <old_server_root>/slapd-<old_instance>-db/ldif
 
mv <dated_#_file>.ldif old.ldif 
 
  1. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Delete the first 2 entries in "old.ldif". They look like the following:
    Entry 1: <old machine domain>
     
    Entry 2: cn=ldap://:<old port>,<old machine domain>
     
    For example:
     
    Entry 1: dc=cert,dc=redhat,dc=com
     
    Entry 2: cn=ldap://:38900,dc=cert,dc=redhat,dc=com
     
    
  3. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 4.5 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go the following directory:
      cd <old_server_root>/bin/cert/migrate/45ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

iCMS 4.7 Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
 
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
      cd <old_server_root>/bin/cert
       
      
    6. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
      
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif -n userRoot
     
    Text should be output to the screen detailing the location and 
    name of the LDIF file that was created. For example:
     
    ldiffile: 
    <old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
    if
     
    Go to this location, and rename the LDIF file to "old.ldif":
     
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    mv <dated_#_file>.ldif old.ldif 
     
    
  3. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Replace the following entry with the one in "new.ldif" as created in step 1 of iCMS 4.7 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go the following directory:
      cd <old_server_root>/bin/cert/migrate/47ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

CMS 6.0 Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
     
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
    cd <old_server_root>/bin/cert
    1. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    2. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
      
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "old.ldif":
cd <old_server_root>/slapd-<old_instance>-db/ldif
 
mv <dated_#_file>.ldif old.ldif 
 
  1. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 6.0 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd <old_server_root>/bin/cert/migrate/60ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

CMS 6.01 Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
      cd <old_server_root>/bin/cert
       
      
    6. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Since you will not be using the original CS/CMS/iCMS Migration Utility packaged with the old server, remove the "misnamed" <old_server_root>/bin/cert/upgrade directory. For example, using recursive rm:
      rm -rf <old_server_root>/bin/cert/upgrade
       
      
    8. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
      
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif -n userRoot
     
    Text should be output to the screen detailing the location and 
    name of the LDIF file that was created. For example:
     
    ldiffile: 
    <old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
    if
     
    Go to this location, and rename the LDIF file to "old.ldif":
     
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    mv <dated_#_file>.ldif old.ldif 
     
    
  3. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 6.01 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd <old_server_root>/bin/cert/migrate/60ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

CMS 6.1 Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
      cd <old_server_root>/bin/cert
       
      
    6. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Since you will not be using the original CS/CMS/iCMS Migration Utility packaged with the old server, remove the "misnamed" <old_server_root>/bin/cert/upgrade directory. For example, using recursive rm:
      rm -rf <old_server_root>/bin/cert/upgrade
       
      
    8. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
      
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "old.ldif":
cd <old_server_root>/slapd-<old_instance>-db/ldif
 
mv <dated_#_file>.ldif old.ldif 
 
  1. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 6.1 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd <old_server_root>/bin/cert/migrate/61ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

CMS 6.2 Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
      cd <old_server_root>/bin/cert
       
      
    6. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Since you will not be using the original CS/CMS/iCMS Migration Utility packaged with the old server, remove the "misnamed" <old_server_root>/bin/cert/upgrade directory. For example, using recursive rm:
      rm -rf <old_server_root>/bin/cert/upgrade
       
      
    8. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
      
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "old.ldif":
cd <old_server_root>/slapd-<old_instance>-db/ldif
 
mv <dated_#_file>.ldif old.ldif 
 
  1. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 6.2 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd <old_server_root>/bin/cert/migrate/62ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

CMS 7.0 Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
      cd <old_server_root>/bin/cert
       
      
    6. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Since you will not be using the original CS/CMS/iCMS Migration Utility packaged with the old server, remove the "misnamed" <old_server_root>/bin/cert/upgrade directory. For example, using recursive rm:
      rm -rf <old_server_root>/bin/cert/upgrade
       
      
    8. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
      
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "old.ldif":
cd <old_server_root>/slapd-<old_instance>-db/ldif
 
mv <dated_#_file>.ldif old.ldif 
 
  1. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 7.0 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd <old_server_root>/bin/cert/migrate/70ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

CS 7.1 Internal DB Data

  1. Login as the <new_user> on the machine hosting the new CS server instance(s), and execute the following commands to export the new internal database content into LDIF format:
    cd <new_server_root>/slapd-<new_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<new_server_root>/slapd-<new_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "new.ldif":
cd <new_server_root>/slapd-<new_instance>-db/ldif
 
mv <dated_#_file>.ldif new.ldif 
 
  1. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" <new_server_root>/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd <new_server_root>/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv <new_server_root>/bin/cert/upgrade 
      <new_server_root>/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      <new_server_root>/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the <new_server_root>/bin/cert/tools/unzip utility 
      to the <old_server_root>/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp <new_server_root>/bin/cert/migrate.zip 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp <new_server_root>/bin/cert/migrate.tar 
      <old_server_root>/bin/cert
       
      rm <new_server_root>/bin/cert/migrate.tar
       
      
    5. Login as the <old_user> on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, and change to the following directory:
      cd <old_server_root>/bin/cert
       
      
    6. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown <old_user>:<old_group> migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown <old_user>:<old_group> migrate.tar
       
      Logout as "root" so that you are the <old_user> again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Since you will not be using the original CS/CMS/iCMS Migration Utility packaged with the old server, remove the "misnamed" <old_server_root>/bin/cert/upgrade directory. For example, using recursive rm:
      rm -rf <old_server_root>/bin/cert/upgrade
       
      
    8. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
      
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  2. Execute the following commands to export the old internal database content into LDIF format:
    cd <old_server_root>/slapd-<old_instance>-db
     
    db2ldif -n userRoot
     
    
Text should be output to the screen detailing the location and name of the LDIF file that was created. For example:
ldiffile: 
<old_server_root>/slapd-<old_instance>-db/ldif/<dated_#_file>.ld
if
 
Go to this location, and rename the LDIF file to "old.ldif":
cd <old_server_root>/slapd-<old_instance>-db/ldif
 
mv <dated_#_file>.ldif old.ldif 
 
  1. Adjust the LDIF content of "old.ldif". To do this:
Note: If using an editor to accomplish this procedure (rather than a script which performs substitution), be sure to use an editor that supports file sizes greater than 2-4 gigabytes (e. g. - vim), as the data present in the LDIF files may exceed this limit in some deployments.
  1. Go to the following directory:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    
  2. Replace the following entry with the one in "new.ldif" as created in step 1 of CS 7.1 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd <old_server_root>/bin/cert/migrate/71ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<old_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh <old_server_root>/slapd-<old_instance>-db/ldif/old.ldif > 
      <old_server_root>/slapd-<old_instance>-db/ldif/old.txt
       
      
  2. Go to the old LDIF directory, and transfer the "old.txt" file into the new CS server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd <old_server_root>/slapd-<old_instance>-db/ldif
     
    cp <old_server_root>/slapd-<old_instance>-db/ldif/old.txt 
    <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  3. Login as the <new_user> on the machine hosting the new CS server instance(s), and change to the following directory:
    cd <new_server_root>/slapd-<new_instance>-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown <new_user>:<new_group> old.txt
     
    Logout as "root" so that you are the <new_user> again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance. For example, assuming that the new server instance is CS 7.1:
    1. Go to the following directory:
      cd <new_server_root>/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=<new_instance> and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      <new_server_root>/slapd-<new_instance>-db/ldif/old.txt > 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
    1. Go to the following directory:
      cd <new_server_root>/slapd-<new_instance>-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i 
      <new_server_root>/slapd-<new_instance>-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

Step 7: Customization of User Data (non-Console)

At this point in the migration, the user should copy all of their customized plug-ins, profiles, forms, and apply any hand-edited changes to the CS.cfg file.

For example, if you have changed the profile configuration in your <server_root>/<old_CA_instance> to enable S/MIME support, you would need to make the same changes to your <server_root>/<new_CA_instance>.

Here's how you would enable S/MIME support in your <server_root>/<old_CA_instance> using the caTokenUserEncryptionKeyEnrollment profile and migrate it over to the <server_root>/<new_CA_instance> by simply duplicating the configuration:

  1. Login as the <old_user> on the machine hosting the old server, change directory to <old_server_root>/<old_CA_instance>/profiles/ca/, and edit the caTokenUserEncryptionKeyEnrollment.cfg to change the p1 policy set to look like this:
    policyset.set1.p1.constraint.class_id=noConstraintImpl
     
    policyset.set1.p1.constraint.name=No Constraint
     
    policyset.set1.p1.default.class_id=nsTokenUserKeySubjectNameDefa
    ultImpl
     
    policyset.set1.p1.default.name=nsTokenUserKeySubjectNameDefault
     
    policyset.set1.p1.default.params.dnpattern=UID=$request.uid$,OU=
    Engineering, O=Example
     
    policyset.set1.p1.default.params.ldap.enable=true
     
    policyset.set1.p1.default.params.ldap.searchName=uid
     
    policyset.set1.p1.default.params.ldapStringAttributes=uid,mail
     
    policyset.set1.p1.default.params.ldap.basedn=dc=example,dc=com
     
    policyset.set1.p1.default.params.ldap.maxConns=4
     
    policyset.set1.p1.default.params.ldap.minConns=1
     
    policyset.set1.p1.default.params.ldap.ldapconn.Version=2
     
    policyset.set1.p1.default.params.ldap.ldapconn.host=ldaphostA.ex
    ample.com
     
    policyset.set1.p1.default.params.ldap.ldapconn.port=389
     
    policyset.set1.p1.default.params.ldap.ldapconn.secureConn=false
     
    
The above configuration would enable S/MIME support for services that use this profile for obtaining certificates (e. g. - Token Management System).
  1. After all of the previous migration steps are complete, you need to manually make this configuration change to the <new_server_root>/<new_CA_instance> to mimic what you had in the <old_server_root>/<old_CA_instance>. Login as the <new_user> on the machine hosting the new server, change directory to <new_server_root>/<new_CA_instance>/profiles/ca/, and edit the caTokenUserEncryptionKeyEnrollment.cfg to change the p1 policy set to look like this:
    policyset.set1.p1.constraint.class_id=noConstraintImpl
     
    policyset.set1.p1.constraint.name=No Constraint
     
    policyset.set1.p1.default.class_id=nsTokenUserKeySubjectNameDefa
    ultImpl
     
    policyset.set1.p1.default.name=nsTokenUserKeySubjectNameDefault
     
    policyset.set1.p1.default.params.dnpattern=UID=$request.uid$, 
    OU=Engineering, O=Example
     
    policyset.set1.p1.default.params.ldap.enable=true
     
    policyset.set1.p1.default.params.ldap.searchName=uid
     
    policyset.set1.p1.default.params.ldapStringAttributes=uid,mail
     
    policyset.set1.p1.default.params.ldap.basedn=dc=example,dc=com
     
    policyset.set1.p1.default.params.ldap.maxConns=4
     
    policyset.set1.p1.default.params.ldap.minConns=1
     
    policyset.set1.p1.default.params.ldap.ldapconn.Version=2
     
    policyset.set1.p1.default.params.ldap.ldapconn.host=ldaphostA.ex
    ample.com
     
    policyset.set1.p1.default.params.ldap.ldapconn.port=389
     
    policyset.set1.p1.default.params.ldap.ldapconn.secureConn=false
     
    
Once the above change is done, the altered profile would now be able to serve certificate requests with S/MIME support enabled.

Step 8: Starting all new CS instances

After completing all of the previous migration steps, start all new CS instances:

  1. If a configuration directory resides on this machine, execute the specified commands:
    cd <new_server_root>/slapd-<new_config_directory_instance> 
     
    start-slapd
     
    
  2. For each internal DB that resides on this machine, execute the specified commands:
    cd <new_server_root>/slapd-<new_instance>-db 
     
    start-slapd 
     
    
  3. Execute the specified commands to start the Administration Server:
    cd <new_server_root> 
     
    start-admin 
     
    
  4. For each new CS subsystem that resides on this machine, execute the specified commands:
    cd <new_server_root>/cert-<new_instance>
     
    start-cert 
     
    

Step 9: Generation of New CS Server Certificates

If the migration was to a different machine, you must renew the SSL Server Certificate associated with each newly migrated CS server instance:

Based upon the type of CS subsystem instance for which the SSL Server Certificate is being renewed, and the circumstances dictated by your specific installation, click on one of the following three scenarios:

Renew a [CA] SSL Server Certificate by Signing it with your CA Signing Certificate

  1. Go to the following directory:
    cd <new_server_root>
     
    
  2. Execute the following command:
    startconsole
     
    
  3. Login to the primary Red Hat console.
  4. Highlight your newly imported CS instance, and login to the Red Hat CS console associated with this CS instance.
  5. In the Red Hat CS console, select the tab entitled "Configuration".
  6. Highlight the "System Keys and Certificates" option from the menu on the left-hand side.
  7. Select the tab entitled "Local Certificates" on the right-hand side.
  8. Press the button labeled "Add/Renew" to launch the "Certificate Setup Wizard":
    1. The first panel is entitled "Introduction"; click "Next>".
    2. The next panel is entitled "Type of Operation"; select the "Request a certificate" option (the default), and click "Next>".
    3. The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and choose the option entitled "Sign this SSL Certificate with my CA Signing Certificate" (the default); the SSL Server Certificate will automatically be generated. Click "Next>".
    4. The next panel is entitled "Key-Pair Information for the SSL Server Certificate". Select "Create new key pair", since the renewed SSL Server Certificate will require a change to the "CN" component of its distinguished name. Fill in information in the other fields on this panel as desired (using the other defaults as desired), and click "Next>".
    5. The next panel is entitled "Message Digest Algorithm". Select the desired hashing algorithm (or use the default of SHA-1), and click "Next>".
    6. The next panel is entitled "Subject Name for the SSL Certificate". For the "CN" component, enter the fully qualified domain name (e. g. - zeta.example.com) of the machine that the new CS CA instance resides upon. Fill in information in the other fields on this panel as desired (it is highly recommended that the "O" and "C" components also be filled with useful information), and click "Next>".
    7. Click through the remainder of the panels in the "Certificate Setup Wizard" selecting the desired options (or merely accepting the defaults).
    8. The newly migrated CA's SSL Server Certificate should automatically be renewed containing the correct data.
  9. Dismiss the Red Hat CS console.
  10. Dismiss the primary Red Hat console.
  11. Go to the directory of the newly migrated CS CA instance for which the SSL Server Certificate was just renewed:
    cd <new_server_root>/cert-<new-instance>
     
    
  12. Shutdown this particular new CS CA instance:
    stop-cert
     
    
  13. Restart this particular new CS CA instance:
    start-cert
     
    

Renew a [CA] SSL Server Certificate by Issuing an SSL Server Certificate Request

Note: Please use this section only if you don't want to sign the SSL Server Certificate Request using your existing CA's Signing Certificate. In this case, the request can be submitted to another CA for signing.

  1. Go to the following directory:
    cd <new_server_root>
     
    
  2. Execute the following command:
    startconsole
     
    
  3. Login to the primary Red Hat console.
  4. Highlight your newly imported CS instance, and login to the Red Hat CS console associated with this CS instance.
  5. In the Red Hat CS console, select the tab entitled "Configuration".
  6. Highlight the "System Keys and Certificates" option from the menu on the left-hand side.
  7. Select the tab entitled "Local Certificates" on the right-hand side.
  8. Press the button labeled "Add/Renew" to launch the "Certificate Setup Wizard":
    1. The first panel is entitled "Introduction"; click "Next>".
    2. The next panel is entitled "Type of Operation"; select the "Request a certificate" option (the default), and click "Next>".
    3. The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and choose the option entitled "Create a request for submission to another CA", and click "Next>". An SSL Server Certificate Request will be generated which first needs to be submitted to, and approved by, a CA.
    4. The next panel is entitled "Key-Pair Information for the SSL Server Certificate". Select "Create new key pair", since the renewed SSL Server Certificate will require a change to the "CN" component of its distinguished name. Fill in information in the other fields on this panel as desired, and click "Next>".
    5. The next panel is entitled "Subject Name for the SSL Certificate". For the "CN" component, enter the fully qualified domain name (e. g. - sigma.example.com) of the machine that the new CS CA instance resides upon. Fill in information in the other fields on this panel as desired (it is highly recommended that the "O" and "C" components also be filled with useful information), and click "Next>".
    6. Click through the remainder of the panels in the "Certificate Setup Wizard" selecting the desired options (or merely accepting the defaults).
  9. Obtain the SSL Server Certificate Request, and store it in a file with a base-64 encoded format.
  10. Submit the SSL Server Certificate Request to a CA, and await approval of this request.
  11. Once the SSL Server Certificate has been approved, relaunch the "Certificate Setup Wizard" by once again pressing the button labeled "Add/Renew".
    1. The first panel is entitled "Introduction"; click "Next>".
    2. The next panel is entitled "Type of Operation"; this time, select the "Install a certificate" option, and click "Next>".
    3. The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and click "Next>".
    4. The next panel is entitled "Location of Certificate"; enter in the desired information, and click "Next>".
    5. Click through the remainder of the panels in the "Certificate Setup Wizard" to install the correctly updated renewed SSL Server Certificate for your newly migrated CS CA instance.
  12. Dismiss the Red Hat CS console.
  13. Dismiss the primary Red Hat console.
  14. Go to the directory of the newly migrated CS CA instance for which the SSL Server Certificate was just renewed:
    cd <new_server_root>/cert-<new-instance>
     
    
  15. Shutdown this particular new CS CA instance:
    stop-cert
     
    
  16. Restart this particular new CS CA instance:
    start-cert
     
    

Renew a [DRM], [OCSP], or [TKS] SSL Server Certificate

  1. Go to the following directory:
    cd <new_server_root>
     
    
  2. Execute the following command:
    startconsole
     
    
  3. Login to the primary Red Hat console.
  4. Highlight your newly imported CS instance, and login to the Red Hat CS console associated with this CS instance.
  5. In the Red Hat CS console, select the tab entitled "Configuration".
  6. Highlight the "System Keys and Certificates" option from the menu on the left-hand side.
  7. Select the tab entitled "Local Certificates" on the right-hand side.
  8. Press the button labeled "Add/Renew" to launch the "Certificate Setup Wizard":
    1. The first panel is entitled "Introduction"; click "Next>".
    2. The next panel is entitled "Type of Operation"; select the "Request a certificate" option (the default), and click "Next>".
    3. The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and click "Next>". An SSL Server Certificate Request will be generated which first needs to be submitted to, and approved by, a CA.
    4. The next panel is entitled "Key-Pair Information for the SSL Server Certificate". Select "Create new key pair", since the renewed SSL Server Certificate will require a change to the "CN" component of its distinguished name. Fill in information in the other fields on this panel as desired, and click "Next>".
    5. The next panel is entitled "Subject Name for the SSL Certificate". For the "CN" component, enter the fully qualified domain name (e. g. - sigma.example.com) of the machine that the new CS subsystem instance resides upon. Fill in information in the other fields on this panel as desired (it is highly recommended that the "O" and "C" components also be filled with useful information), and click "Next>".
    6. Click through the remainder of the panels in the "Certificate Setup Wizard" selecting the desired options (or merely accepting the defaults).
  9. Obtain the SSL Server Certificate Request, and store it in a file with a base-64 encoded format.
  10. Submit the SSL Server Certificate Request to a CA, and await approval of this request.
  11. Once the SSL Server Certificate has been approved, relaunch the "Certificate Setup Wizard" by once again pressing the button labeled "Add/Renew".
    1. The first panel is entitled "Introduction"; click "Next>".
    2. The next panel is entitled "Type of Operation"; this time, select the "Install a certificate" option, and click "Next>".
    3. The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and click "Next>".
    4. The next panel is entitled "Location of Certificate"; enter in the desired information, and click "Next>".
    5. Click through the remainder of the panels in the "Certificate Setup Wizard" to install the correctly updated renewed SSL Server Certificate for your newly migrated CS subsystem instance.
  12. Dismiss the Red Hat CS console.
  13. Dismiss the primary Red Hat console.
  14. Go to the directory of the newly migrated CS subsystem instance for which the SSL Server Certificate was just renewed:
    cd <new_server_root>/cert-<new-instance>
     
    
  15. Shutdown this particular new CS subsystem instance:
    stop-cert
     
    
  16. Restart this particular new CS subsystem instance:
    start-cert
     
    

Step 10: Customization of User Data (Console)

At this point in the migration, the user should use the console to configure any customized behavior of their various subsystem(s) which may consist of pre-existing plug-ins, logging/auditing, customized plug-ins, etc. A given subsystem may have to be restarted once all configuration changes have been applied.

Step 11: After Migration

After migrating all old CS instance(s) to their associated new CS server instance(s), access the End-Entity Services and the Agent Services interfaces of the new CS server instance(s) to ensure that everything is working properly.

You must also log in to the CS Console and verify that you can manage the new server via the console.

The port numbers for all these interfaces can be found in this file:

<new_server_root>/cert-<new_instance>/config/server.xml
 

Detailed Example of a CS Migration

The following detailed example is provided for reference:

Table 2-4 Strategy for Detailed Example Configurations
 
OLD INSTALLATION
NEW INSTALLATION
Version
CMS 6.1 (SP 4) plus assorted "hot-fixes"
CS 7.1
Platform
Solaris 8
Red Hat Enterprise
Linux 4 (AS)
Subsystems
CA,
DRM,
OCSP,
RA
CA,
DRM,
OCSP
Server Instances
admin-serv,
slapd-ds,
cert-ca,
slapd-ca-db,
cert-drm,
slapd-drm-db,
cert-ocsp,
slapd-ocsp-db,
cert-ra,
slapd-ra-db
admin-serv,
slapd-ds,
cert-ca,
slapd-ca-db,
cert-drm,
slapd-drm-db,
cert-ocsp,
slapd-ocsp-db
Machine Name
alpha.example.com
omega.example.com
HSM Vendor
N/A - uses software security databases
Epsilon HSM

Token Name: "epsilon"

Slot Names:
"rho" for [CA],
"tau" for [DRM], and
"phi" for [OCSP]

library path: /usr/lib
library name: libepsilon.so
Server Root
/usr/netscape/servers
/opt/redhat-cs
User Ownership
cmsuser
csuser
Group Ownership
cmsgroup
csgroup
Password Cache
passwords
"diamond" for [CA],
"emerald" for [DRM], and
"sapphire" for [OCSP]
"diamond" for [CA],
"emerald" for [DRM], and
"sapphire" for [OCSP]
Password.conf
used by [CA],
used by [DRM], and
used by [OCSP]
used by [CA],
used by [DRM], and
used by [OCSP]
Backup Facility
Professional Backup Facility
Professional Backup Facility

Note: For the purposes of this particular example, all CMS 6.1 (SP 4) servers are located on a single machine called alpha.example.com, and they are all migrated to CS 7.1 instances that are also located on a single machine called omega.example.com. It is highly recommended that actual deployments separate the various servers across numerous machines. Additionally, each subsystem contains a single simple password; real deployments should use far more robust cryptographically stronger passwords containing uppercase letters, lowercase letters, numbers, etc.

Based upon the configurations presented in Table 2-4, this detailed example will systematically apply the eleven steps needed to migrate the CMS 6.1 (SP 4) installation to the CS 7.1 installation. As per the caveats stated above, this process will be done to completion for each subsystem prior to beginning the migration of the next subsystem:

[CA] Migration

Step 1: Before Migration

Since no upgrade path exists for a CMS 6.1 (SP 4) RA subsystem, you should flush all data located in the CMS 6.1 (SP 4) RA request queues by processing it on the CMS 6.1 (SP 4) CA subsystem. You should then stop the CMS 6.1 (SP 4) RA subsystem so that no further data can be gathered by it:

  1. Stop the CMS 6.1 (SP 4) RA instance:
    cd /usr/netscape/servers/cert-ra
     
    stop-cert
     
    
  2. Stop the associated CMS 6.1 (SP 4) RA internal-DB instance:
    cd /usr/netscape/servers/slapd-ra-db
     
    stop-slapd
     
    

Since you will utilize a professional backup system that works on the entire CMS 6.1 (SP 4) system, the backup utilities included in CMS 6.1 (SP 4) as documented in Chapter 7 Backing Up and Restoring Data, in Version 6.1 of the Netscape Certificate Management System Command-Line Tools Guide, do not need to be utilized. For this particular example, all CMS 6.1 (SP 4) server instances are located on the machine called "alpha.example.com". To use this backup system, you should stop the following CMS 6.1 (SP 4) server instances:

  1. Stop the CMS 6.1 (SP 4) OCSP, DRM, and CA instances:
    cd /usr/netscape/servers/cert-ocsp
     
    stop-cert
     
    cd /usr/netscape/servers/cert-drm
     
    stop-cert
     
    cd /usr/netscape/servers/cert-ca
     
    stop-cert
     
    
  2. Stop the CMS 6.1 (SP 4) Admin Server instance:
    cd /usr/netscape/servers
     
    stop-admin
     
    
  3. Stop the CMS 6.1 (SP 4) OCSP, DRM, and CA internal DB instances:
    cd /usr/netscape/servers/slapd-ocsp-db
     
    stop-slapd
     
    cd /usr/netscape/servers/slapd-drm-db
     
    stop-slapd
     
    cd /usr/netscape/servers/slapd-ca-db
     
    stop-slapd
     
    
  4. Stop the CMS 6.1 (SP 4) Configuration Directory Server instance:
    cd /usr/netscape/servers/slapd-ds
     
    stop-slapd
     
    

Finally, a backup of the entire CMS 6.1 (SP 4) system is performed using this professional backup system.

Step 2: Creation of a New CS Installation

  1. Create a new CS 7.1 installation on the machine called "omega.example.com" running Red Hat Enterprise Linux (RHEL) 4:
    1. Using your appropriate entitlements, download "redhat-cs-7.1-2.RHEL4.i386.rpm" from the Red Hat Network (RHN), and as "root", install the bits to the "/opt/redhat-cs" directory (default location):
      rpm -ivh redhat-cs-7.1-2.RHEL4.i386.rpm
       
      
    2. For this particular example, the "csuser" user and "csgroup" group have already been created and are usable by the machine called "omega.example.com". Perform the following tasks to prepare for CS 7.1 configuration:
      cd /opt
       
      chown -R csuser:csgroup redhat-cs
       
      Logout as "root", and login as "csuser".
       
      
    3. Go to the following directory:
      cd /opt/redhat-cs
       
      
    4. Execute the following command:
      ./setup/setup
       
      
  2. Configure "cert-ca":
    1. Go to the following directory:
      cd /opt/redhat-cs
       
      
    2. Execute the following command to launch the Red Hat console:
      ./startconsole 
       
      
    3. Configure "cert-ca".
    4. Dismiss the Red Hat console.

Step 3: Stopping all new CS instances

  1. Execute the following commands to stop the CS 7.1 CA instance:
    cd /opt/redhat-cs/cert-ca
     
    stop-cert
     
    
  2. Execute the following commands to stop the CS 7.1 Administration Server:
    cd /opt/redhat-cs
     
    stop-admin
     
    
  3. Execute the following commands to stop the CS 7.1 CA internal DB instance:
    cd /opt/redhat-cs/slapd-ca-db
     
    stop-slapd
     
    
  4. Execute the following commands to stop the CS 7.1 Configuration Directory Server instance:
    cd /opt/redhat-cs/slapd-ds
     
    stop-slapd
     
    

Step 4: Migration of Security Databases

Perform the following migration steps for the CA subsystem:

Migrate [CA] data from the CMS 6.1 (SP 4) software security databases to the CS 7.1 HSM

Click on "CMS 6.1, or CMS 6.2", then click on "CMS 6.1, or CMS 6.2 [CA]", and finally click on "Case II: CMS 6.1, or CMS 6.2 [CA] - Software (old server) --> HSM (new server)". Login to "omega.example.com" as "csuser", and execute the following tasks:

  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance:
    rm /opt/redhat-cs/alias/cert-ca-omega-cert8.db
     
    rm /opt/redhat-cs/alias/cert-ca-omega-key3.db
     
    
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp /usr/netscape/servers/alias/cert-ca-alpha-cert8.db 
    /opt/redhat-cs/alias/cert-ca-omega-cert8.db
     
    cp /usr/netscape/servers/alias/cert-ca-alpha-key3.db 
    /opt/redhat-cs/alias/cert-ca-omega-key3.db
     
    
     
    
  3. Login as the new user, "csuser", on the machine hosting the new server, "omega.example.com", and change into the correct directory:
    cd /opt/redhat-cs/alias
     
    
     
    
  4. Since "omega.example.com" is a Linux system, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown csuser:csgroup cert-ca-omega-cert8.db
     
    chown csuser:csgroup cert-ca-omega-key3.db
     
    Logout as "root" so that you are "csuser" again.
     
    chmod 00600 cert-ca-omega-cert8.db
     
    chmod 00600 cert-ca-omega-key3.db
     
    
     
    
  5. List the contents of the old software security databases by executing the specified command:
    /opt/redhat-cs/bin/cert/tools/certutil.sh -L -d . -P 
    cert-ca-omega-
     
    
    Server-Cert cert-ca cu,cu,cu
    caSigningCert cert-ca cu,cu,cu
    ocspSigningCert cert-ca CTu,Cu,Cu
    
     
    
  6. Extract the public/private key pairs of each entry from the old software security databases:
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -o ServerCert.p12 -n 
    "Server-Cert cert-ca" -d . -P cert-ca-omega-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -o caSigningCert.p12 
    -n "caSigningCert cert-ca" -d . -P cert-ca-omega-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -o ocspSigningCert.p12 
    -n "ocspSigningCert cert-ca" -d . -P cert-ca-omega-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    Note: For this example, the old software security databases did not contain any 
    additional public/private key pairs that needed to be extracted using this command.
     
    
     
    
  7. Delete the old software security databases:
    rm /opt/redhat-cs/alias/cert-ca-omega-cert8.db
     
    rm /opt/redhat-cs/alias/cert-ca-omega-key3.db
     
    
     
    
  8. Execute the specified command to register the new HSM in the new token database:
    /opt/redhat-cs/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    "epsilon" -libfile /usr/lib/libepsilon.so
     
    
     
    
  9. Identify the new HSM slot name by executing the following command:
/opt/redhat-cs/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
This reveals slots called "rho", "tau", and "phi". The slot 
called "rho" will be used for the CA.
 

 
  1. Create new software security databases:
    /opt/redhat-cs/bin/cert/tools/certutil.sh -N -d . -P 
    cert-ca-omega-
     
    
     
    
  2. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -i ServerCert.p12 -d . 
    -P cert-ca-omega- -h rho
     
    Enter Password or Pin for "rho":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -i caSigningCert.p12 
    -d . -P cert-ca-omega- -h rho
     
    Enter Password or Pin for "rho":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -i ocspSigningCert.p12 
    -d . -P cert-ca-omega- -h rho
     
    Enter Password or Pin for "rho":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
     
    
  3. Optionally, delete the PKCS #12 files:
    rm /opt/redhat-cs/alias/ServerCert.p12
     
    rm /opt/redhat-cs/alias/caSigningCert.p12
     
    rm /opt/redhat-cs/alias/ocspSigningCert.p12
     
    
     
    
  4. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    /opt/redhat-cs/bin/cert/tools/certutil.sh -M -n "rho:Server-Cert 
    cert-ca" -t "cu,cu,cu" -d . -P cert-ca-omega- -h epsilon
     
    
    /opt/redhat-cs/bin/cert/tools/certutil.sh -M -n 
    "rho:caSigningCert cert-ca" -t "CTu,CTu,CTu" -d . -P 
    cert-ca-omega- -h epsilon
     
    
    /opt/redhat-cs/bin/cert/tools/certutil.sh -M -n 
    "rho:ocspSigningCert cert-ca" -t "CTu,Cu,Cu" -d . -P 
    cert-ca-omega- -h epsilon
     
    
     
    
  5. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd /opt/redhat-cs/cert-ca/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
ca.signing.cacertnickname=rho:caSigningCert cert-ca
 
ca.ocsp_signing.cacertnickname=rho:ocspSigningCert cert-ca
 
Since there is CA-DRM connectivity in this example, modify the 
following name/value pair:
 
ca.connector.KRA.nickName=rho:caSigningCert cert-ca
 

 
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 3 lines):
    servercertnickname="rho:Server-Cert cert-ca"
     
    servercertnickname="rho:Server-Cert cert-ca"
     
    servercertnickname="rho:Server-Cert cert-ca"
     
    
     
    

Step 5: Migration of Password Cache Data

Click on "CMS 6.0, CMS 6.1, CMS 6.2, CMS 7.0, or CS 7.1 Password Cache Data and Password.conf", and execute the following tasks for the CA subsystem:

Migrate [CA] password cache data from CMS 6.1 (SP 4) to CS 7.1

  1. Login to "alpha.example.com" as "cmsuser", and execute the following commands:
    cd /usr/netscape/servers/cert-ca/config
     
    /usr/netscape/servers/bin/cert/tools/PasswordCache diamond -d 
    /usr/netscape/servers/alias
    
    -P cert-ca-alpha-
    
    list
     
    cert/key prefix = cert-ca-alpha-
    
    path = /usr/netscape/servers/alias
    
    about to read password cache
    
    ----- Password Cache Content -----
    
    internal : diamond
    
    Internal LDAP Database : diamond
     
    
Write down this information.
  1. Since this example used a "password.conf" file to automatically start the old CA instance on the machine called "alpha.example.com", transfer the "password.conf" file to "omega.example.com", overwriting any existing "password.conf" file:
    cp /usr/netscape/servers/cert-ca/config/password.conf 
    /opt/redhat-cs/cert-ca/config/password.conf
     
    
  2. Login to "omega.example.com" as "csuser", and change into the correct directory:
    cd /opt/redhat-cs/cert-ca/config
     
    
  3. Since "omega.example.com" is a Linux system, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown csuser:csgroup password.conf
     
    Logout as "root" so that you are "csuser" again.
     
    chmod 00600 password.conf
     
    
  4. Recreate the pwcache.db in the latest CS instance:
    1. Remove the new pwcache.db (this is the original password cache file created during the configuration phase documented in Step 2: Creation of a New CS Installation).
    2. Generate a new protection key. To do this, execute the following command:
      /opt/redhat-cs/bin/cert/tools/PasswordCache diamond -d 
      /opt/redhat-cs/alias
      
      -P cert-ca-omega-
      
      -c pwcache.db
      
      rekey
      
       
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-ca-omega-
      
      cert/key db path = /opt/redhat-cs/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      generating new key...
      
      PWsdrCache: mToken = internal
      
      PWsdrCache: SDR key generated
      
      key generated successfully with key id = OPHHNSQTY0RUGFJbcaco1g==
      
      Save the VALUE portion of this key id in a local file,
      
      and under variable "pwcKeyid" in CS.cfg!!
      
      If you have not already done so,
      
      remove the old pwcache.db and use this local file to add 
      passwords.
       
      
    3. Save the value portion of the key id into a local file such as key.txt.
    4. Save the value portion of the key id into the CS.cfg file under the variable "pwcKeyid":
    5. Execute the following command to create an empty new password cache file:
      touch pwcache.db
       
      
    6. Add old password tags and their associated old/new passwords (from step 1 of CMS 6.0, CMS 6.1, CMS 6.2, CMS 7.0, or CS 7.1 Password Cache Data and Password.conf) back to the cache. You may need to do this multiple times. For example, execute the following commands:
      /opt/redhat-cs/bin/cert/tools/PasswordCache diamond
      
      -d /opt/redhat-cs/alias
      
      -P cert-ca-omega-
      
      -c pwcache.db
      
      -k key.txt
      
      add "Internal LDAP Database" diamond
      
       
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-ca-omega-
      
      cert/key db path = /opt/redhat-cs/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      adding Internal LDAP Database:diamond
      
      PWsdrCache: in addEntry
      
      about to read password cache
      
      PWsdrCache: after readPWcache()
      
      adding new tag: Internal LDAP Database
      
      operation completed for pwcache.db
       
       
       
      /opt/redhat-cs/bin/cert/tools/PasswordCache diamond
      
      -d /opt/redhat-cs/alias
      
      -P cert-ca-omega-
      
      -c pwcache.db
      
      -k key.txt
      
      add "internal" diamond
       
       
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-ca-omega-
      
      cert/key db path = /opt/redhat-cs/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      adding internal:diamond
      
      PWsdrCache: in addEntry
      
      about to read password cache
      
      PWsdrCache: after readPWcache()
      
      adding new tag: internal
      
      operation completed for pwcache.db
       
      
    7. Execute the following command to confirm that everything is OK:
      /opt/redhat-cs/bin/cert/tools/PasswordCache diamond -d 
      /opt/redhat-cs/alias
      
      -P cert-ca-omega-
      
      -c pwcache.db
      
      list
      
       
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-ca-omega-
      
      cert/key db path = /opt/redhat-cs/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      about to read password cache
      
      ----- Password Cache Content -----
      
      internal : diamond
      
      Internal LDAP Database : diamond
       
      

Step 6: Migration of Internal DB Data

Click on "CMS 6.1 Internal DB Data", and execute the following tasks for the CA subsystem:

Migrate [CA] internal DB data from CMS 6.1 (SP 4) to CS 7.1

  1. Login as "csuser" on the machine hosting the new CA server instance, "omega.example.com", and execute the following commands to export the new internal database content into LDIF format:
    cd /opt/redhat-cs/slapd-ca-db
     
    db2ldif -n userRoot
     
     
     
    Text should be output to the screen detailing the location and 
    name of the LDIF file that was created. For example:
     
    ldiffile: /opt/redhat-cs/slapd-ca-db/ldif/2005_06_07_874021.ldif
     
    Go to this location, and rename the LDIF file to "new.ldif":
     
    cd /opt/redhat-cs/slapd-ca-db/ldif
     
    mv 2005_06_07_874021.ldif new.ldif 
     
    
  2. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" /opt/redhat-cs/bin/cert/upgrade directory.
    1. Go to the following directory:
      cd /opt/redhat-cs/bin/cert
       
      
    2. Rename the misnamed "upgrade" directory to "migrate":
      mv /opt/redhat-cs/bin/cert/upgrade 
      /opt/redhat-cs/bin/cert/migrate
       
      
    3. Use "zip" or "tar" to package the latest version of the CS Migration Utility:
      /opt/redhat-cs/bin/cert/tools/zip -r migrate.zip migrate 
      
      
      
      --- OR ---
      
      
      
      tar -cvf migrate.tar migrate
      
      
      
      Note:  	Whichever packaging tool you use, the corresponding tool 
      must be present on the platform where the old server resides. If 
      the platforms are identical, and the "zip" utility is used, feel 
      free to copy the /opt/redhat-cs/bin/cert/tools/unzip utility to 
      the /usr/netscape/servers/bin/cert/ directory so that the 
      zip/unzip versions match appropriately.
       
      
    4. Transfer the package from the new server to the old server using cp, rcp, scp, mv, ftp, sftp, etc, and delete it from the new server. For example, using cp:
      cp /opt/redhat-cs/bin/cert/migrate.zip 
      /usr/netscape/servers/bin/cert
       
      rm /opt/redhat-cs/bin/cert/migrate.zip
      
      
      
      --- OR ---
      
      
      
      cp /opt/redhat-cs/bin/cert/migrate.tar 
      /usr/netscape/servers/bin/cert
       
      rm /opt/redhat-cs/bin/cert/migrate.tar
       
      
    5. Login as "cmsuser" on the machine hosting the old CS/CMS/iCMS server instance(s) to be migrated, "alpha.example.com", and change to the following directory:
      cd /usr/netscape/servers/bin/cert
       
      
    6. Since "alpha.example.com" is a Solaris (UNIX) system, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
      su
       
      chown cmsuser:cmsgroup migrate.zip
       
      
      
      --- OR ---
      
      
      
      chown cmsuser:cmsgroup migrate.tar
       
      Logout as "root" so that you are "cmsuser" again.
       
      chmod 00600 migrate.zip
       
      
      
      --- OR ---
      
      
      
      chmod 00600 migrate.tar
       
      
    7. Since you will not be using the original CS/CMS/iCMS Migration Utility packaged with the old server, remove the "misnamed" /usr/netscape/servers/bin/cert/upgrade directory. For example, using recursive rm:
      rm -rf /usr/netscape/servers/bin/cert/upgrade
       
      
    8. Use "unzip" or "tar" to unpackage the latest version of the CS Migration Utility:
      unzip migrate.zip 
      
      
      
      --- OR ---
      
      
      
      tar -xvf migrate.tar
      
       
      
      Remove the package, and any additional utilities that may have 
      been copied to the old CS/CMS/iCMS server (e. g. - if the unzip 
      executable was copied to this location, rm unzip):
       
      rm migrate.zip 
      
      
      
      --- OR ---
      
      
      
      rm migrate.tar 
       
      
  3. Execute the following commands to export the old internal database content into LDIF format:
    cd /usr/netscape/servers/slapd-ca-db
     
    db2ldif -n userRoot
    
     
     
    Text should be output to the screen detailing the location and 
    name of the LDIF file that was created. For example:
     
    ldiffile: 
    /usr/netscape/servers/slapd-ca-db/ldif/2005_06_07_439837.ldif
    
     
     
    Go to this location, and rename the LDIF file to "old.ldif":
     
    cd /usr/netscape/servers/slapd-ca-db/ldif
     
    mv 2005_06_07_439837.ldif old.ldif 
     
    
  4. Adjust the LDIF content of "old.ldif". To do this:
Note: For this example, we assumed that the data was relatively small, so basically any editor would suffice.
  1. Go to the following directory:
    cd /usr/netscape/servers/slapd-ca-db/ldif
     
    
  2. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 6.1 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd /usr/netscape/servers/bin/cert/migrate/61ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=/usr/netscape/servers and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=ca and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh /usr/netscape/servers/slapd-ca-db/ldif/old.ldif > 
      /usr/netscape/servers/slapd-ca-db/ldif/old.txt
       
      
  2. Go to the old CA LDIF directory, and transfer the "old.txt" file into the new CA server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd /usr/netscape/servers/slapd-ca-db/ldif
     
    cp /usr/netscape/servers/slapd-ca-db/ldif/old.txt 
    /opt/redhat-cs/slapd-ca-db/ldif
     
    
  3. Login as the "csuser" on the machine hosting the new CA server instance, "omega.example.com", and change to the following directory:
    cd /opt/redhat-cs/slapd-ca-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown csuser:csgroup old.txt
     
    Logout as "root" so that you are the "csuser" again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance.
    1. Go to the following directory:
      cd /opt/redhat-cs/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=/opt/redhat-cs and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=ca and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      /opt/redhat-cs/slapd-ca-db/ldif/old.txt > 
      /opt/redhat-cs/slapd-ca-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new CA server instance's internal database. To do this:
    1. Go to the following directory:
      cd /opt/redhat-cs/slapd-ca-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i /opt/redhat-cs/slapd-ca-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

Step 7: Customization of User Data (non-Console)

This particular example contains no user customizations.

Step 8: Starting all new CS instances

  1. Execute the following commands to start the CS 7.1 Configuration Directory Server instance:
    cd /opt/redhat-cs/slapd-ds
     
    start-slapd
     
    
  2. Execute the following commands to start the CS 7.1 CA internal DB instances:
    cd /opt/redhat-cs/slapd-ca-db
     
    start-slapd
     
    
  3. Execute the following commands to start the CS 7.1 Administration Server:
    cd /opt/redhat-cs
     
    start-admin 
     
    
  4. Execute the following commands to start the CS 7.1 CA instance:
    cd /opt/redhat-cs/cert-ca
     
    start-cert
     
    

Step 9: Generation of New CS Server Certificates

Perform the following migration steps for the CA subsystem:

Renew the CA SSL Server Certificate

Click on "Renew a [CA] SSL Server Certificate by Signing it with your CA Signing Certificate", and execute the following tasks:

  1. Go to the following directory:
    cd /opt/redhat-cs
     
    
  2. Execute the following command:
    startconsole
     
    
  3. Login to the primary Red Hat console.
  4. Highlight your newly imported CS instance, and login to the Red Hat CS console associated with this CS instance.
  5. In the Red Hat CS console, select the tab entitled "Configuration".
  6. Highlight the "System Keys and Certificates" option from the menu on the left-hand side.
  7. Select the tab entitled "Local Certificates" on the right-hand side.
  8. Press the button labeled "Add/Renew" to launch the "Certificate Setup Wizard":
    1. The first panel is entitled "Introduction"; click "Next>".
    2. The next panel is entitled "Type of Operation"; select the "Request a certificate" option (the default), and click "Next>".
    3. The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and choose the option entitled "Sign this SSL Certificate with my CA Signing Certificate" (the default); the SSL Server Certificate will automatically be generated. Click "Next>".
    4. The next panel is entitled "Key-Pair Information for the SSL Server Certificate". Select "Create new key pair", since the renewed SSL Server Certificate will require a change to the "CN" component of its distinguished name. Fill in information in the other fields on this panel as desired (using the other defaults as desired), and click "Next>".
    5. The next panel is entitled "Message Digest Algorithm". Select the desired hashing algorithm (or use the default of SHA-1), and click "Next>".
    6. The next panel is entitled "Subject Name for the SSL Certificate". For the "CN" component, enter omega.example.com. Fill in information in the other fields on this panel as desired (it is highly recommended that the "O" and "C" components also be filled with useful information), and click "Next>".
    7. Click through the remainder of the panels in the "Certificate Setup Wizard" selecting the desired options (or merely accepting the defaults).
    8. The newly migrated CA's SSL Server Certificate should automatically be renewed containing the correct data.
  9. Dismiss the Red Hat CS console.
  10. Dismiss the primary Red Hat console.
  11. Go to the directory of the newly migrated CS CA instance for which the SSL Server Certificate was just renewed:
    cd /opt/redhat-cs/cert-ca
     
    
  12. Shutdown this particular new CS CA instance:
    stop-cert
     
    
  13. Restart this particular new CS CA instance:
    start-cert
     
    

Step 10: Customization of User Data (Console)

This particular example contains no user customizations.

Step 11: After Migration

After migrating the CMS 6.1 (SP 4) CA instance to its CS 7.1 CA instance counterpart, access the End-Entity Services and the Agent Services interfaces of the CS 7.1 CA instance to ensure that everything is working properly.

You must also log in to the CS 7.1 Red Hat Console and verify that you can manage the new server via the console.

The port numbers for all CA interfaces can be found in the following file:

CA: /opt/redhat-cs/cert-ca/config/server.xml
 

[DRM] Migration

Step 1: Before Migration

Since a complete full backup of all old CMS 6.1 (SP 4) instances were made during the CA subsystem migration, no further action is required for this step during the DRM subsystem migration.

Note: All old CMS 6.1 (SP 4) subsystems should still be shutdown from the previous migration.

Step 2: Creation of a New CS Installation

  1. For this example, since all subsystems are being migrated to the same machine, this step has already been accomplished during the CA subsystem migration.
  2. Configure "cert-drm":
    1. Use the Red Hat console to create "cert-drm".
    2. In another terminal session, go to the following directory:
      cd /opt/redhat-cs/cert-drm/config
       
      
    3. Edit the file called "CertSetup.cfg" and append the following line to the end of this file:
      kra.keySplitting=true 
       
      
    4. Back in the Red Hat console, configure "cert-drm".
    5. Dismiss the Red Hat console.

Step 3: Stopping all new CS instances

  1. Execute the following commands to stop the CS 7.1 DRM and CA instances:
    cd /opt/redhat-cs/cert-drm
     
    stop-cert
     
    cd /opt/redhat-cs/cert-ca
     
    
stop-cert
  1. Execute the following commands to stop the CS 7.1 Administration Server:
    cd /opt/redhat-cs
     
    stop-admin
     
    
  2. Execute the following commands to stop the CS 7.1 DRM and CA internal DB instances:
    cd /opt/redhat-cs/slapd-drm-db
     
    stop-slapd
     
    cd /opt/redhat-cs/slapd-ca-db
     
    stop-slapd
     
    
  3. Execute the following commands to stop the CS 7.1 Configuration Directory Server instance:
    cd /opt/redhat-cs/slapd-ds
     
    stop-slapd
     
    

Step 4: Migration of Security Databases

Perform the following migration steps for the DRM subsystem:

Migrate [DRM] data from the CMS 6.1 (SP 4) software security databases to the CS 7.1 HSM

Click on "CMS 6.1, or CMS 6.2", then click on "CMS 6.1, or CMS 6.2 [DRM]", and finally click on "Case II: CMS 6.1, or CMS 6.2 [DRM] - Software (old server) --> HSM (new server)". Login to "omega.example.com" as "csuser", and execute the following tasks:

  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance:
    rm /opt/redhat-cs/alias/cert-drm-omega-cert8.db
     
    rm /opt/redhat-cs/alias/cert-drm-omega-key3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp /usr/netscape/servers/alias/cert-drm-alpha-cert8.db 
    /opt/redhat-cs/alias/cert-drm-omega-cert8.db
     
    cp /usr/netscape/servers/alias/cert-drm-alpha-key3.db 
    /opt/redhat-cs/alias/cert-drm-omega-key3.db
     
    
  3. Login as the new user, "csuser", on the machine hosting the new server, "omega.example.com", and change into the correct directory:
    cd /opt/redhat-cs/alias
     
    
  4. Since "omega.example.com" is a Linux system, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown csuser:csgroup cert-drm-omega-cert8.db
     
    chown csuser:csgroup cert-drm-omega-key3.db
     
    Logout as "root" so that you are "csuser" again.
     
    chmod 00600 cert-drm-omega-cert8.db
     
    chmod 00600 cert-drm-omega-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    /opt/redhat-cs/bin/cert/tools/certutil.sh -L -d . -P 
    cert-drm-omega-
     
        Server-Cert cert-drm cu,cu,cu
     
        caSigningCert cert-drm cT,c,
     
        kraStorageCert cert-drm u,u,u
     
        kraTransportCert cert-drm u,u,u
     
    
  6. Extract the public/private key pairs of each entry from the old software security databases:
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -o ServerCert.p12 -n 
    "Server-Cert cert-drm" -d . -P cert-drm-omega-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
     
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -o kraStorageCert.p12 
    -n "kraStorageCert cert-drm" -d . -P cert-drm-omega-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
     
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -o 
    kraTransportCert.p12 -n "kraTransportCert cert-drm" -d . -P 
    cert-drm-omega-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
Note: For this example, the old software security databases did not contain any additional public/private key pairs that needed to be extracted using this command.
  1. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    /opt/redhat-cs/bin/cert/tools/certutil.sh -L -n "caSigningCert 
    cert-drm" -d . -P cert-drm-omega- -a > caSigningCert.b64
     
    Note: For this example, the old software security databases did not contain any 
    additional public keys that needed to be extracted using this command.
     
    
  2. Delete the old software security databases:
    rm /opt/redhat-cs/alias/cert-drm-omega-cert8.db
     
    rm /opt/redhat-cs/alias/cert-drm-omega-key3.db
     
    
  3. Execute the specified command to register the new HSM in the new token database:
    /opt/redhat-cs/bin/cert/modutil.sh -nocertdb -dbdir . -add 
    "epsilon" -libfile /usr/lib/libepsilon.so
     
    
  4. Identify the new HSM slot name by executing the following command:
    /opt/redhat-cs/bin/cert/tools/modutil.sh -dbdir . -nocertdb 
    -list
     
    This reveals slots called "rho", "tau", and "phi". The slot 
    called "tau" will be used for the DRM.
     
    
  5. Create new software security databases:
    /opt/redhat-cs/bin/cert/tools/certutil.sh -N -d . -P 
    cert-drm-omega-
     
    
  6. Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM:
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -i ServerCert.p12 -d . 
    -P cert-drm-omega- -h tau
     
    Enter Password or Pin for "tau":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
     
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -i kraStorageCert.p12 
    -d . -P cert-drm-omega- -h tau
     
    Enter Password or Pin for "tau":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
     
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -i 
    kraTransportCert.p12 -d . -P cert-drm-omega- -h tau
     
    Enter Password or Pin for "tau":********
     
    Enter password for PKCS12 file: ********
     
    pk12util: PKCS12 IMPORT SUCCESSFUL
     
    
  7. Optionally, delete the PKCS #12 files:
    rm /opt/redhat-cs/alias/ServerCert.p12
     
    rm /opt/redhat-cs/alias/kraStorageCert.p12
     
    rm /opt/redhat-cs/alias/kraTransportCert.p12
     
    
  8. Set the trust bits on the public/private key pairs that were imported into the new HSM:
    /opt/redhat-cs/bin/cert/tools/certutil.sh -M -n "tau:Server-Cert 
    cert-drm" -t "cu,cu,cu" -d . -P cert-drm-omega- -h epsilon
     
    
    /opt/redhat-cs/bin/cert/tools/certutil.sh -M -n 
    "tau:kraStorageCert cert-drm" -t "u,u,u" -d . -P cert-drm-omega- 
    -h epsilon
     
    
    /opt/redhat-cs/bin/cert/tools/certutil.sh -M -n 
    "tau:kraTransportCert cert-drmdrm" -t "u,u,u" -d . -P 
    cert-drm-omega- -h epsilon
     
    
  9. Import the public key of the entry from the base-64 file into the new HSM, and set the trust bits:
    /opt/redhat-cs/bin/cert/tools/certutil.sh -A -n 
    "tau:caSigningCert cert-drm" -t "CT,c," -d . -P cert-drm-omega- 
    -h epsilon -i caSigningCert.b64
     
    
  10. Optionally, delete the base-64 file:
    rm /opt/redhat-cs/alias/caSigningCert.b64
     
    
  11. Update the appropriate new CS.cfg configuration file by executing the following commands:
    cd /opt/redhat-cs/cert-drm/config
     
    
Edit the new CS.cfg, and modify the following name/value pairs:
kra.storageUnit.nickName=tau:kraStorageCert cert-drm
 
kra.transportUnit.nickName=tau:kraTransportCert cert-drm
 
Note: The caSigningCert is not referenced by the new CS.cfg.
  1. Within the same directory, update the appropriate new server.xml configuration file by editing the new server.xml (changing 2 lines):
    servercertnickname="tau:Server-Cert cert-drm"
     
    servercertnickname="tau:Server-Cert cert-drm"
     
    

Step 5: Migration of Password Cache Data

Click on "CMS 6.0, CMS 6.1, CMS 6.2, CMS 7.0, or CS 7.1 Password Cache Data and Password.conf", and execute the following tasks for the DRM subsystem:

Migrate [DRM] password cache data from CMS 6.1 (SP 4) to CS 7.1

  1. Login to "alpha.example.com" as "cmsuser", and execute the following commands:
    cd /usr/netscape/servers/cert-drm/config
     
    /usr/netscape/servers/bin/cert/tools/PasswordCache 
    /usr/netscape/servers -d /usr/netscape/servers/alias
    
    -P cert-drm-alpha-
    
    list
     
    cert/key prefix = cert-drm-alpha-
    
    path = /usr/netscape/servers/alias
    
    about to read password cache
    
    ----- Password Cache Content -----
    
    internal : emerald
    
    Internal LDAP Database : emerald
     
    Write down this information.
     
    
  2. Since this example used a "password.conf" file to automatically start the old DRM instance on the machine called "alpha.example.com", transfer the "password.conf" file to "omega.example.com", overwriting any existing "password.conf" file:
    cp /usr/netscape/servers/cert-drm/config/password.conf 
    /opt/redhat-cs/cert-drm/config/password.conf
     
    
  3. Login to "omega.example.com" as "csuser", and change into the correct directory:
    cd /opt/redhat-cs/cert-drm/config
     
    
  4. Since "omega.example.com" is a Linux system, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown csuser:csgroup password.conf
     
    Logout as "root" so that you are "csuser" again.
     
    chmod 00600 password.conf
     
    
  5. Recreate the pwcache.db in the latest CS instance:
    1. Remove the new pwcache.db (this is the original password cache file created during the configuration phase documented in Step 2: Creation of a New CS Installation).
    2. Generate a new protection key. To do this, execute the following command:
      /opt/redhat-cs/bin/cert/tools/PasswordCache emerald -d 
      /opt/redhat-cs/alias
      
      -P cert-drm-omega-
      
      -c pwcache.db
      
      rekey
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-drm-omega-
      
      cert/key db path = /opt/redhat-cs/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      generating new key...
      
      PWsdrCache: mToken = internal
      
      PWsdrCache: SDR key generated
      
      key generated successfully with key id = OPHHNSQTY0RUGFJbcaco1g==
      
      Save the VALUE portion of this key id in a local file,
      
      and under variable "pwcKeyid" in CS.cfg!!
      
      If you have not already done so,
      
      remove the old pwcache.db and use this local file to add 
      passwords.
       
      
    3. Save the value portion of the key id into a local file such as key.txt.
    4. Save the value portion of the key id into the CS.cfg file under the variable "pwcKeyid":
    5. Execute the following command to create an empty new password cache file:
      touch pwcache.db
       
      
    6. Add old password tags and their associated old/new passwords (from step 1 of CMS 6.0, CMS 6.1, CMS 6.2, CMS 7.0, or CS 7.1 Password Cache Data and Password.conf) back to the cache. You may need to do this multiple times. For example, execute the following commands:
      /opt/redhat-cs/bin/cert/tools/PasswordCache emerald
      
      -d /opt/redhat-cs/alias
      
      -P cert-drm-omega-
      
      -c pwcache.db
      
      -k key.txt
      
      add "Internal LDAP Database" emerald
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-drm-omega-
      
      cert/key db path = /opt/redhat-cs/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      adding Internal LDAP Database:emerald
      
      PWsdrCache: in addEntry
      
      about to read password cache
      
      PWsdrCache: after readPWcache()
      
      adding new tag: Internal LDAP Database
      
      operation completed for pwcache.db
       
      
       
      /opt/redhat-cs/bin/cert/tools/PasswordCache emerald
      
      -d /opt/redhat-cs/alias
      
      -P cert-drm-omega-
      
      -c pwcache.db
      
      -k key.txt
      
      add "internal" emerald
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-drm-omega-
      
      cert/key db path = /opt/redhat-cs/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      adding internal:emerald
      
      PWsdrCache: in addEntry
      
      about to read password cache
      
      PWsdrCache: after readPWcache()
      
      adding new tag: internal
      
      operation completed for pwcache.db
       
      
    7. Execute the following command to confirm that everything is OK:
      /opt/redhat-cs/bin/cert/tools/PasswordCache emerald -d 
      /opt/redhat-cs/alias
      
      -P cert-drm-omega-
      
      -c pwcache.db
      
      list
       
      Text similar to the following output should appear on the screen:
       
      cert/key prefix = cert-drm-omega-
      
      cert/key db path = /opt/redhat-cs/alias
      
      password cache file = pwcache.db
      
      token name = internal
      
      PWsdrCache: mToken = internal
      
      about to read password cache
      
      ----- Password Cache Content -----
      
      internal : emerald
      
      Internal LDAP Database : emerald
       
      

Step 6: Migration of Internal DB Data

Click on "CMS 6.1 Internal DB Data", and execute the following tasks for the DRM subsystem:

Migrate [DRM] internal DB data from CMS 6.1 (SP 4) to CS 7.1

  1. Login as "csuser" on the machine hosting the new DRM server instance, "omega.example.com", and execute the following commands to export the new internal database content into LDIF format:
    cd /opt/redhat-cs/slapd-drm-db
     
    db2ldif -n userRoot
     
    Text should be output to the screen detailing the location and 
    name of the LDIF file that was created. For example:
     
    ldiffile: 
    /opt/redhat-cs/slapd-drm-db/ldif/2005_06_07_720658.ldif
     
    Go to this location, and rename the LDIF file to "new.ldif":
     
    cd /opt/redhat-cs/slapd-drm-db/ldif
     
    mv 2005_06_07_720658.ldif new.ldif 
     
    
  2. Since the CS Migration Utility is platform independent, you should always use the latest version of the CS Migration Utility on both versions of the server; the latest migration tools are available in the "misnamed" /opt/redhat-cs/bin/cert/upgrade directory.
NOTE: For this particular example, since the latest CS Migration Utility has already been installed during the "Migrate [CA] internal DB data from CMS 6.1 (SP 4) to CS 7.1" procedure above, there is no need to repeat this process for the DRM.
  1. Execute the following commands to export the old internal database content into LDIF format:
    cd /usr/netscape/servers/slapd-drm-db
     
    db2ldif -n userRoot
     
    Text should be output to the screen detailing the location and 
    name of the LDIF file that was created. For example:
     
    ldiffile: 
    /usr/netscape/servers/slapd-drm-db/ldif/2005_06_07_390512.ldif
     
    Go to this location, and rename the LDIF file to "old.ldif":
     
    cd /usr/netscape/servers/slapd-drm-db/ldif
     
    mv 2005_06_07_390512.ldif old.ldif 
     
    
  2. Adjust the LDIF content of "old.ldif". To do this:
Note: For this example, we assumed that the data was relatively small, so basically any editor would suffice.
  1. Go to the following directory:
    cd /usr/netscape/servers/slapd-drm-db/ldif
     
    
  2. Replace the following entry with the one in "new.ldif" as created in step 1 of CMS 6.1 Internal DB Data:
    cn=aclResources,o=CertificateServer
     
    
  1. Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
    1. Go to the following directory:
      cd /usr/netscape/servers/bin/cert/migrate/61ToTxt
       
      
    2. In run.sh, set SERVER_ROOT=/usr/netscape/servers and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=drm and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.ldif" is redirected to create "old.txt"):
      run.sh /usr/netscape/servers/slapd-drm-db/ldif/old.ldif > 
      /usr/netscape/servers/slapd-drm-db/ldif/old.txt
       
      
  2. Go to the old DRM LDIF directory, and transfer the "old.txt" file into the new DRM server instance's internal database LDIF directory using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cd /usr/netscape/servers/slapd-drm-db/ldif
     
    cp /usr/netscape/servers/slapd-drm-db/ldif/old.txt 
    /opt/redhat-cs/slapd-drm-db/ldif
     
    
  3. Login as the "csuser" on the machine hosting the new DRM server instance, "omega.example.com", and change to the following directory:
    cd /opt/redhat-cs/slapd-drm-db/ldif
     
    
  4. On Linux/UNIX systems, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown csuser:csgroup old.txt
     
    Logout as "root" so that you are the "csuser" again.
     
    chmod 00600 old.txt
     
    
  5. Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance.
    1. Go to the following directory:
      cd /opt/redhat-cs/bin/cert/migrate/TxtTo71
       
      
    2. In run.sh, set SERVER_ROOT=/opt/redhat-cs and uncomment it
    3. In run.sh, uncomment export SERVER_ROOT
    4. In run.sh, set INSTANCE=drm and uncomment it
    5. In run.sh, uncomment export INSTANCE
    6. Execute the following command (note that "old.txt" is redirected to create "old.ldif"):
      run.sh
      
      /opt/redhat-cs/slapd-drm-db/ldif/old.txt > 
      /opt/redhat-cs/slapd-drm-db/ldif/old.ldif
       
      
  6. Import the "old.ldif" LDIF file into this new DRM server instance's internal database. To do this:
    1. Go to the following directory:
      cd /opt/redhat-cs/slapd-drm-db
       
      
    2. Execute the following command:
      ldif2db -n userRoot -i /opt/redhat-cs/slapd-drm-db/ldif/old.ldif
       
      
    3. Force the VLV indexes to be re-indexed by executing the following command:
      db2index
       
      

Step 7: Customization of User Data (non-Console)

This particular example contains no user customizations.

Step 8: Starting all new CS instances

  1. Execute the following commands to start the CS 7.1 Configuration Directory Server instance:
    cd /opt/redhat-cs/slapd-ds
     
    start-slapd
     
    
  2. Execute the following commands to start the CS 7.1 CA and DRM internal DB instances:
    cd /opt/redhat-cs/slapd-ca-db
     
    start-slapd
     
    cd /opt/redhat-cs/slapd-drm-db
     
    start-slapd
     
    
  3. Execute the following commands to start the CS 7.1 Administration Server:
    cd /opt/redhat-cs
     
    start-admin 
     
    
  4. Execute the following commands to start the CS 7.1 CA and DRM instances:
    cd /opt/redhat-cs/cert-ca
     
    start-cert
     
    cd /opt/redhat-cs/cert-drm
     
    start-cert
     
    

Step 9: Generation of New CS Server Certificates

Perform the following migration steps for the DRM subsystem:

Renew the DRM SSL Server Certificate

Click on "Renew a [DRM], [OCSP], or [TKS] SSL Server Certificate", and execute the following tasks:

  1. Go to the following directory:
    cd /opt/redhat-cs
     
    
  2. Execute the following command:
    startconsole
     
    
  3. Login to the primary Red Hat console.
  4. Highlight your newly imported CS instance, and login to the Red Hat CS console associated with this CS instance.
  5. In the Red Hat CS console, select the tab entitled "Configuration".
  6. Highlight the "System Keys and Certificates" option from the menu on the left-hand side.
  7. Select the tab entitled "Local Certificates" on the right-hand side.
  8. Press the button labeled "Add/Renew" to launch the "Certificate Setup Wizard":
    1. The first panel is entitled "Introduction"; click "Next>".
    2. The next panel is entitled "Type of Operation"; select the "Request a certificate" option (the default), and click "Next>".
    3. The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and click "Next>". An SSL Server Certificate Request will be generated which first needs to be submitted to, and approved by, a CA.
    4. The next panel is entitled "Key-Pair Information for the SSL Server Certificate". Select "Create new key pair", since the renewed SSL Server Certificate will require a change to the "CN" component of its distinguished name. Fill in information in the other fields on this panel as desired, and click "Next>".
    5. The next panel is entitled "Subject Name for the SSL Certificate". For the "CN" component, enter omega.example.com. Fill in information in the other fields on this panel as desired (it is highly recommended that the "O" and "C" components also be filled with useful information), and click "Next>".
    6. Click through the remainder of the panels in the "Certificate Setup Wizard" selecting the desired options (or merely accepting the defaults).
  9. Obtain the SSL Server Certificate Request, and store it in a file with a base-64 encoded format.
  10. Submit the SSL Server Certificate Request to a CA, and await approval of this request.
  11. Once the SSL Server Certificate has been approved, relaunch the "Certificate Setup Wizard" by once again pressing the button labeled "Add/Renew".
    1. The first panel is entitled "Introduction"; click "Next>".
    2. The next panel is entitled "Type of Operation"; this time, select the "Install a certificate" option, and click "Next>".
    3. The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and click "Next>".
    4. The next panel is entitled "Location of Certificate"; enter in the desired information, and click "Next>".
    5. Click through the remainder of the panels in the "Certificate Setup Wizard" to install the correctly updated renewed SSL Server Certificate for your newly migrated CS subsystem instance.
  12. Dismiss the Red Hat CS console.
  13. Dismiss the primary Red Hat console.
  14. Go to the directory of the newly migrated CS subsystem instance for which the SSL Server Certificate was just renewed:
    cd /opt/redhat-cs/cert-drm
     
    
  15. Shutdown this particular new CS subsystem instance:
    stop-cert
     
    
  16. Restart this particular new CS subsystem instance:
    start-cert
     
    

Step 10: Customization of User Data (Console)

This particular example contains no user customizations.

Step 11: After Migration

After migrating the CMS 6.1 (SP 4) DRM instance to its CS 7.1 DRM instance counterpart, access the End-Entity Services and the Agent Services interfaces of both the CS 7.1 CA and DRM instances to ensure that everything is working properly.

You must also log in to the CS 7.1 Red Hat Console and verify that you can manage the new server via the console.

The port numbers for all CA and DRM interfaces can be found in the following files:

CA: /opt/redhat-cs/cert-ca/config/server.xml
 
DRM: /opt/redhat-cs/cert-drm/config/server.xml
 

[OCSP] Migration

Step 1: Before Migration

Since a complete full backup of all old CMS 6.1 (SP 4) instances were made during the CA subsystem migration, no further action is required for this step during the OCSP subsystem migration.

Note: All old CMS 6.1 (SP 4) subsystems should still be shutdown from the previous migrations.

Step 2: Creation of a New CS Installation

  1. For this example, since all subsystems are being migrated to the same machine, this step has already been accomplished during the CA subsystem migration.
  2. Configure "cert-ocsp":
    1. Use the Red Hat console to create "cert-ocsp".
    2. Configure "cert-ocsp".
    3. Dismiss the Red Hat console.

Step 3: Stopping all new CS instances

  1. Execute the following commands to stop the CS 7.1 OCSP, DRM, and CA instances:
    cd /opt/redhat-cs/cert-ocsp
     
    stop-cert
     
    cd /opt/redhat-cs/cert-drm
     
    stop-cert
     
    cd /opt/redhat-cs/cert-ca
     
    stop-cert
     
    
  2. Execute the following commands to stop the CS 7.1 Administration Server:
    cd /opt/redhat-cs
     
    stop-admin
     
    
  3. Execute the following commands to stop the CS 7.1 OCSP, DRM, and CA internal DB instances:
    cd /opt/redhat-cs/slapd-ocsp-db
     
    stop-slapd
     
    cd /opt/redhat-cs/slapd-drm-db
     
    stop-slapd
     
    cd /opt/redhat-cs/slapd-ca-db
     
    stop-slapd
     
    
  4. Execute the following commands to stop the CS 7.1 Configuration Directory Server instance:
    cd /opt/redhat-cs/slapd-ds
     
    stop-slapd
     
    

Step 4: Migration of Security Databases

Perform the following migration steps for the OCSP subsystem:

Migrate [OCSP] data from the CMS 6.1 (SP 4) software security databases to the CS 7.1 HSM

Click on "CMS 6.1, or CMS 6.2", then click on "CMS 6.1, or CMS 6.2 [OCSP]", and finally click on "Case II: CMS 6.1, or CMS 6.2 [OCSP] - Software (old server) --> HSM (new server)". Login to "omega.example.com" as "csuser", and execute the following tasks:

  1. Remove all security databases associated with each CS instance residing on the new server that is intended to have data migrated to it from an old CS/CMS/iCMS instance:
    rm /opt/redhat-cs/alias/cert-ocsp-omega-cert8.db
     
    rm /opt/redhat-cs/alias/cert-ocsp-omega-key3.db
     
    
  2. Transfer the certificate and key software security databases from the old server to the new server using cp, rcp, scp, mv, ftp, sftp, etc. For example, using cp:
    cp /usr/netscape/servers/alias/cert-ocsp-alpha-cert8.db 
    /opt/redhat-cs/alias/cert-ocsp-omega-cert8.db
     
    cp /usr/netscape/servers/alias/cert-ocsp-alpha-key3.db 
    /opt/redhat-cs/alias/cert-ocsp-omega-key3.db
     
    
  3. Login as the new user, "csuser", on the machine hosting the new server, "omega.example.com", and change into the correct directory:
    cd /opt/redhat-cs/alias
     
    
  4. Since "omega.example.com" is a Linux system, be sure to change all file ownership/permissions to the correct user and group ownership/permissions (you will need to have "root" permission to change file ownership):
    su
     
    chown csuser:csgroup cert-ocsp-omega-cert8.db
     
    chown csuser:csgroup cert-ocsp-omega-key3.db
     
    Logout as "root" so that you are "csuser" again.
     
    chmod 00600 cert-ocsp-omega-cert8.db
     
    chmod 00600 cert-ocsp-omega-key3.db
     
    
  5. List the contents of the old software security databases by executing the specified command:
    cd /opt/redhat-cs/alias
     
    /opt/redhat-cs/bin/cert/tools/certutil.sh -L -d . -P 
    cert-ocsp-omega-
     
        Server-Cert cert-ocsp cu,cu,cu
     
        caSigningCert cert-ocsp CT,c,
     
        ocspSigningCert cert-ocsp cu,cu,cu
     
    
  6. Extract the public/private key pairs of each entry from the old software security databases:
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -o ServerCert.p12 -n 
    "Server-Cert cert-ocsp" -d . -P cert-ocsp-omega-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
    /opt/redhat-cs/bin/cert/tools/pk12util.sh -o ocspSigningCert.p12 
    -n "ocspSigningCert cert-ocsp" -d . -P cert-ocsp-omega-
     
    Enter Password or Pin for "NSS Certificate DB":********
     
    Enter password for PKCS12 file: ********
     
    Re-enter password: ********
     
    pk12util: PKCS12 EXPORT SUCCESSFUL
     
    
Note: For this example, the old software security databases did not contain any additional public/private key pairs that needed to be extracted using this command.
  1. Extract the public key of the following entry from the old software security databases and save the base-64 output to a file:
    /opt/redhat-cs/bin/cert/tools/certutil.sh -L -n "caSigningCert 
    cert-ocsp" -d . -P cert-ocsp-omega- -a > caSigningCert.b64
     
    
Note: For this example, the old software security databases did not contain any additional public keys that needed to be extracted using this command.
  1. Delete the old software security databases:
    rm /opt/redhat-cs/alias/cert-ocsp-omega-cert8.db
     
    rm /opt/redhat-cs/alias/cert-ocsp-omega-key3.db