| 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
- Overview
- Caveats regarding Migration
- Step 1: Before Migration
- Step 2: Creation of a New CS Installation
- Step 3: Stopping all new CS instances
- Step 4: Migration of Security Databases
- Step 5: Migration of Password Cache Data and Password.conf
- Step 6: Migration of Internal DB Data
- Step 7: Customization of User Data (non-Console)
- Step 8: Starting all new CS instances
- Step 9: Generation of New CS Server Certificates
- Step 10: Customization of User Data (Console)
- Step 11: After Migration
- Detailed Example of a CS Migration
History
This table summarizes all CS/CMS/iCMS releases through CS 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:
- Product "downgrades," attempting to extract data from a newer version and import this data into a previous version, are not supported by the CS Migration Utility.
- Both CMS 4.1 and CMS 4.2 included several standalone platform-specific migration utilities which were created for the sole purpose of extracting data out of the predecessor of CS/CMS/iCMS, Netscape Certificate Server 1.0 or one of its service packs.
- CMS 4.1, CMS 4.2, CMS 4.2 (SP 2), and CMS 4.5 contained an in-place upgrade facility to automatically extract the data from one of its older CS siblings (presuming, of course, that the upgrade took place on the same machine running the same platform).
- Since CMS 4.7 was developed by another company, it contained only an in-place upgrade facility for CMS 4.1, CMS 4.2, and CMS 4.2 (SP 2).
- CMS 6.0 contained neither an in-place upgrade facility, nor a CMS Migration Utility. This oversight was corrected in the CMS 6.01 service pack by the inclusion of the first CMS Migration Utility which could also be used by CMS 6.0 installations.
- CMS 6.0, CMS 6.01, CMS 6.1, CMS 6.2, CMS 7.0, and CS 7.1 contained no in-place upgrade facility. Therefore, the associated version of the CS/CMS Migration Utility has represented the sole means by which a previous installation can be migrated to a new installation since the introduction of CMS 6.01 (with iCMS 4.7 being the lone exception). This has been true even for versions of the product that could be upgraded on the same machine of the same platform (e.g.,a CMS 6.2 installation resides on a machine named "delta.example.com" running Red Hat Linux Advanced Server 2.1 and needs to be migrated to a new CMS 7.0 installation residing on the machine named "delta.example.com" running Red Hat Linux Advanced Server 2.1); basically, this was accomplished by merely supplying a different <server_root> for each installation.
- CMS 6.01, CMS 6.1, CMS 6.2, CMS 7.0, and CS 7.1 contain various versions of the CS/CMS Migration Utility as described in the remainder of this document.
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:
- two precompiled java classes
- an executable shell script
- an executable batch script
- the Java source file that produced the precompiled Java classes
- a sample shell script that may be utilized to compile the source file
- 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:
- three precompiled java classes
- an executable shell script
- an executable batch script
- the Java source file that produced the precompiled Java classes
- a sample shell script that may be utilized to compile the source file
- 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.
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:
* 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:
- Since all migrations are unique to a particular user's deployment, it is strongly recommended that the user first plan out the entire migration process (e. g. - the strategy table as presented in the example migration of this document).
- Although this migration document is large and complex in nature, several steps in the step-by-step process documented below have been presented in the style of a decision tree; this allows the user to concentrate solely on the case(s) relevant to their particular deployment, and to ignore all of the other text for a particular step.
- If possible, always perform all eleven steps in the migration procedure for each and every instance of each subsystem type to be migrated. Always perform each migration step in sequential order, from the first step through the last step.
- Treat each subsystem as a standalone individual migration (i. e. - migrate one subsystem to completion before starting the migration of a second subsystem).
- On Linux/UNIX systems, whenever any file is moved between two separate instances, always make sure that both the file ownership (user and group) as well as the file permissions are correct, and that the target machine allows this transfer.
- Whenever any migration procedure refers to extraction of data from a Hardware Security Module (HSM), it should be noted that no CS/CMS/iCMS tool exists which can be used to extract public/private key pairs from an HSM; this is primarily due to stipulations imposed by Federal Information Processing Standard (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.
- 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 (i. e. - <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.
- For the purposes of this document, always assume that all old passwords match all new passwords exactly.
- Throughout this document, the permissions 00600 (octal, no sticky bit permissions, user read/write permissions, no group permissions, no other permissions) are documented for each use of the "chmod" command; these are merely suggested permissions, not mandatory.
Additionally, the following caveats apply to specific subsystems of specific versions of CS/CMS/iCMS:
- No migration path exists to move TPS data from CMS 7.0 to CS 7.1.
- Beginning with CS 7.1, the key-splitting scheme required by the key recovery feature of the DRM subsystem is no longer the default scheme. Currently, no migration method has been provided to convert the old key-splitting scheme to the new scheme. However, future versions of this product will contain such a utility. In short, DRM instances constructed in installations prior to CS 7.1 cannot be successfully migrated to new installations of CS 7.1.
- Beginning with CMS 7.0, the RA subsystem was deprecated in favor of the TPS subsystem. Therefore, since no migration path exists to import RA data into a CMS 7.0 or CS 7.1 installation, it is highly recommended that all RA request queues be processed by previous servers into their existing CAs prior to performing any CA migrations from these older servers.
- CMS 4.2 contained a third-party OCSP responder called the ValiCert Certificate Validation Authority (VATM). No migration path exists for data residing in this third-party component.
- CMS 4.1 and CMS 4.2 only contained stand-alone platform-dependent migration utilities to extract Certificate Server 1.0 data from AIX, HP-UX, Solaris, and Windows NT [Intel] platforms; no such migration utilities ever existed to extract data from Digital UNIX, IRIX, or Windows NT [alpha] platforms.
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:
- 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.
- 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:
- 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."
- 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
- RHEL 3, or RHEL 4:
- Download and install the <CS>.rpm as "root". For example:
rpm -ivh <CS>.rpm
- 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.
- Go to the following directory:
cd <new_server_root>
- 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]:
- 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.
- Download and decompress the compressed tarball. For example:
gunzip <CS>.tar.gz
- Unpack the tarball. For example:
tar -xvf <CS>.tar
- 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.
- If the instance to be configured is a DRM, perform steps a.) and b.), else proceed with step c.) below:
- Go to the following directory:
cd <new_server_root>/cert-<new_DRM_instance>/config
- Edit the file called "CertSetup.cfg" and append the following line to the end of this file:
kra.keySplitting=true
- Go to the following directory:
cd <new_server_root>
- Execute the following command:
startconsole
- Configure your desired subsystem.
- Optionally, if any additional CS instances need to be created:
- 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.):
- Go to the following directory:
cd <new_server_root>/cert-<new-instance>/config
- Edit the file called "CertSetup.cfg" and append the following line to the end of this file:
kra.keySplitting=true
- Configure this new subsystem
- 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:
- cd <new_server_root>/cert-<new_instance>
- stop-cert
- cd <new_server_root>
- stop-admin
- cd <new_server_root>/slapd-<new_instance>-db
- stop-slapd
- 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)
- Case II: CMS 4.1 [CA] - Software (old server) --> HSM (new server)
- Case III: CMS 4.1 [CA] - HSM (old server) --> Software (new server)
- Case IV: CMS 4.1 [CA] - HSM (old server) --> HSM (new server)
Case I: CMS 4.1 [CA] - Software (old server) --> Software (new server)
- 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- 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>.
- Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
cd <new_server_root>/alias/- 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- 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.
- Remove the "cert7.db" by executing the specified command:
rm <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce rt7.db- 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>
- 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)
- 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- 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- Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
cd <new_server_root>/alias/- 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
- 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.
- 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.- 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- 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>- Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list- Create new software security databases:
<new_server_root>/bin/cert/tools/certutil.sh -N -d . -P cert-<new_CA_instance>-<new_hostname>-- 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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/caSigningCert.p12- 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>- 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>
- 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)
- 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.
- 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- Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
cd <new_server_root>/alias/- 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- 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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/caSigningCert.p12- 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>-- 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>
- 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)
- 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.
- 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- Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
cd <new_server_root>/alias/- 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- 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>- Identify the new HSM slot name by executing the following command:
- <new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
- 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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/caSigningCert.p12- 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>- 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>
- 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)
- 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- 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>.- Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
cd <new_server_root>/alias/- 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- 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>-
- Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
- Remove the "cert7.db" by executing the specified command:
rm <new_server_root>/alias/cert-<new_CA_instance>-<new_hostname>-ce rt7.db- 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>
- 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)
- 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- 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- Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
cd <new_server_root>/alias/- 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- 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>-
- Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
- 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
- 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- 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>- Identify the new HSM slot name by executing the following command:
- <new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
- Create new software security databases:
<new_server_root>/bin/cert/tools/certutil.sh -N -d . -P cert-<new_CA_instance>-<new_hostname>-- 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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/caSigningCert.p12- 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>- 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>
- 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)
- 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.
- 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- Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
cd <new_server_root>/alias/- 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- 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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/caSigningCert.p12- 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>-- 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>
- 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)
- 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.
- 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- Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
cd <new_server_root>/alias/- 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- 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>- Identify the new HSM slot name by executing the following command:
- <new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list
- 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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/caSigningCert.p12- 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>- 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>
- 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)
- 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- 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>.- Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
cd <new_server_root>/alias/- 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- 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>-
- Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
- Remove the "cert7.db" by executing the specified command:
rm <new_server_root>/alias/cert-<new_DRM_instance>-<new_hostname>-c ert7.db- 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.
- 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)
- 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- 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- Login as the <new_user> on the machine hosting the new server, and change into the correct directory:
cd <new_server_root>/alias/- 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- 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>-
- Note: The certificate database will automatically be converted from "cert7.db" to "cert8.db" when this command is executed.
- 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
- 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.- 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- 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>- Identify the new HSM slot name by executing the following command:
<new_server_root>/bin/cert/tools/modutil.sh -dbdir . -nocertdb -list- Create new software security databases:
<new_server_root>/bin/cert/tools/certutil.sh -N -d . -P cert-<new_DRM_instance>-<new_hostname>-- 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
- 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- 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>