| 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>
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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_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- 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:
- cd <old_server_root>/cert-<old_DRM_instance>/config
- Use the old standalone certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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
- 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 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>-
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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 IV: CMS 4.2 [DRM] - 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_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- 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:
- cd <old_server_root>/cert-<old_DRM_instance>/config
- Use the old standalone certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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_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>
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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]
- CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [DRM]
- CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [OCSP]
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)
- Case II: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [CA] - Software (old server) --> HSM (new server)
- Case III: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [CA] - HSM (old server) --> Software (new server)
- Case IV: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [CA] - HSM (old server) --> HSM (new server)
Case I: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 - [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> 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>
- 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)
- 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 rm <new_server_root>/alias/ocspSigningCert.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> 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>
- 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)
- 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 cp <old_server_root>/cert-<old_CA_instance>/config/ocspSigningCert. p12 <new_server_root>/alias/ocspSigningCert.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 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- 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 rm <new_server_root>/alias/ocspSigningCert.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> 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>
- 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)
- 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 cp <old_server_root>/cert-<old_CA_instance>/config/ocspSigningCert. p12 <new_server_root>/alias/ocspSigningCert.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 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- 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 rm <new_server_root>/alias/ocspSigningCert.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> 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>
- 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)
- Case II: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [DRM] - Software (old server) --> HSM (new server)
- Case III: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [DRM] - HSM (old server) --> Software (new server)
- Case IV: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [DRM] - HSM (old server) --> HSM (new server)
Case I: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [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 (SP 2), CMS 4.5, or iCMS 4.7 [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>
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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_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- 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:
- cd <old_server_root>/cert-<old_DRM_instance>/config
- Use the old standalone certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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
- 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 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>-
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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 IV: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [DRM] - 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_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- 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:
- cd <old_server_root>/cert-<old_DRM_instance>/config
- Use the old standalone certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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_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>
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- Case II: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [OCSP] - Software (old server) --> HSM (new server)
- Case III: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [OCSP] - HSM (old server) --> Software (new server)
- Case IV: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [OCSP] - HSM (old server) --> HSM (new server)
Case I: CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 [OCSP] - 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_OCSP_instance>-<new_hostname>- cert8.db rm <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>- key3.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_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>.- 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_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- 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>-
- 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_OCSP_instance>-<new_hostname>- cert7.db- 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.
- 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)
- 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- 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- 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_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- 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>-
- 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_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
- 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.- 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- 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_OCSP_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_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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_token_name>- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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_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- 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:
- cd <old_server_root>/cert-<old_OCSP_instance>/config
- Use the old standalone certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>-- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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_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- 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:
- cd <old_server_root>/cert-<old_OCSP_instance>/config
- Use the old standalone certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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_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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_token_name>- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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>/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>.- 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> 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>
- 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)
- 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>/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- 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 rm <new_server_root>/alias/ocspSigningCert.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> 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>
- 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)
- 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>/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- 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 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- 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 rm <new_server_root>/alias/ocspSigningCert.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> 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>
- 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)
- 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>/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- 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 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- 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 rm <new_server_root>/alias/ocspSigningCert.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> 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>
- 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)
- 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>/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>.- 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 6.0 [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>/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- 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>
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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>/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- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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
- 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 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>-
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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 IV: CMS 6.0 [DRM] - 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>/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- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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_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>
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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- 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>.- 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_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- 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>-
- 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_OCSP_instance>-<new_hostname>- cert7.db- 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.
- 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)
- 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- 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- 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_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- 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>-
- 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_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
- 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.- 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- 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_OCSP_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_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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_token_name>- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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>/alias/ServerCert.p12 <new_server_root>/alias/ServerCert.p12 cp <old_server_root>/alias/ocspSigningCert.p12 <new_server_root>/alias/ocspSigningCert.p12- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>-- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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>/alias/ServerCert.p12 <new_server_root>/alias/ServerCert.p12 cp <old_server_root>/alias/ocspSigningCert.p12 <new_server_root>/alias/ocspSigningCert.p12- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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_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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_token_name>- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- Case II: CMS 6.1, or CMS 6.2 [CA] - Software (old server) --> HSM (new server)
- Case III: CMS 6.1, or CMS 6.2 [CA] - HSM (old server) --> Software (new server)
- Case IV: CMS 6.1, or CMS 6.2 [CA] - HSM (old server) --> HSM (new server)
Case I: CMS 6.1, or CMS 6.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>/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>.- 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>-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- 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- 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>
- 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)
- 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>/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- 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>-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- 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- 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 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 rm <new_server_root>/alias/ocspSigningCert.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> 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>
- 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)
- 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>/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- 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 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- 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 rm <new_server_root>/alias/ocspSigningCert.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> 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>
- 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)
- 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>/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- 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 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- 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 rm <new_server_root>/alias/ocspSigningCert.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> 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>
- 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)
- Case II: CMS 6.1, or CMS 6.2 [DRM] - Software (old server) --> HSM (new server)
- Case III: CMS 6.1, or CMS 6.2 [DRM] - HSM (old server) --> Software (new server)
- Case IV: CMS 6.1, or CMS 6.2 [DRM] - HSM (old server) --> HSM (new server)
Case I: CMS 6.1, or CMS 6.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>/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>.- 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>-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- 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>-- 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 6.1, or CMS 6.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>/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- 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>-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- 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>-- 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 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>
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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>/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- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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
- 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 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>-
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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 IV: CMS 6.1, or CMS 6.2 [DRM] - 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>/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- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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_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>
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- Case II: CMS 6.1, or CMS 6.2 [OCSP] - Software (old server) --> HSM (new server)
- Case III: CMS 6.1, or CMS 6.2 [OCSP] - HSM (old server) --> Software (new server)
- Case IV: CMS 6.1, or CMS 6.2 [OCSP] - HSM (old server) --> HSM (new server)
Case I: CMS 6.1, or CMS 6.2 [OCSP] - 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_OCSP_instance>-<new_hostname>- cert8.db rm <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>- key3.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>/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>.- 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_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- 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>-- 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.
- 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)
- 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- 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- 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_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- 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- 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
- 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.- 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- 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_OCSP_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_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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_token_name>- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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>/alias/ServerCert.p12 <new_server_root>/alias/ServerCert.p12 cp <old_server_root>/alias/ocspSigningCert.p12 <new_server_root>/alias/ocspSigningCert.p12- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>-- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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>/alias/ServerCert.p12 <new_server_root>/alias/ServerCert.p12 cp <old_server_root>/alias/ocspSigningCert.p12 <new_server_root>/alias/ocspSigningCert.p12- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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_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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_token_name>- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- Case II: CMS 7.0, or CS 7.1 [CA] - Software (old server) --> HSM (new server)
- Case III: CMS 7.0, or CS 7.1 [CA] - HSM (old server) --> Software (new server)
- Case IV: CMS 7.0, or CS 7.1 [CA] - HSM (old server) --> HSM (new server)
Case I: CMS 7.0, or CS 7.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>/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>.- 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>-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- 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>-- 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.
- 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)
- 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>/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- 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>-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- 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>-- 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 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 rm <new_server_root>/alias/ocspSigningCert.p12 rm <new_server_root>/alias/subsystemCert.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> 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.
- 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)
- 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>/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- 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 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- 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 rm <new_server_root>/alias/ocspSigningCert.p12 rm <new_server_root>/alias/subsystemCert.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> 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.
- 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)
- 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>/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- 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 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- 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 rm <new_server_root>/alias/ocspSigningCert.p12 rm <new_server_root>/alias/subsystemCert.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> 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.
- 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)
- Case II: CMS 7.0, or CS 7.1 [DRM] - Software (old server) --> HSM (new server)
- Case III: CMS 7.0, or CS 7.1 [DRM] - HSM (old server) --> Software (new server)
- Case IV: CMS 7.0, or CS 7.1 [DRM] - HSM (old server) --> HSM (new server)
Case I: CMS 7.0, or CS 7.1 [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>/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>.- 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>-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- 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>-- 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 7.0, or CS 7.1 [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>/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- 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>-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- 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>-- 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 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>
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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>/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- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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
- 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 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>-
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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 IV: CMS 7.0, or CS 7.1 [DRM] - 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>/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- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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_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>
- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- Case II: CMS 7.0, or CS 7.1 [OCSP] - Software (old server) --> HSM (new server)
- Case III: CMS 7.0, or CS 7.1 [OCSP] - HSM (old server) --> Software (new server)
- Case IV: CMS 7.0, or CS 7.1 [OCSP] - HSM (old server) --> HSM (new server)
Case I: CMS 7.0, or CS 7.1 [OCSP] - 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_OCSP_instance>-<new_hostname>- cert8.db rm <new_server_root>/alias/cert-<new_OCSP_instance>-<new_hostname>- key3.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>/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>.- 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_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- 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>-- 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.
- 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)
- 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- 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- 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_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- 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>-- 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
- 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.- 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- 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_OCSP_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_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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_token_name>- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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>/alias/ServerCert.p12 <new_server_root>/alias/ServerCert.p12 cp <old_server_root>/alias/ocspSigningCert.p12 <new_server_root>/alias/ocspSigningCert.p12- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>-- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- 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>/alias/ServerCert.p12 <new_server_root>/alias/ServerCert.p12 cp <old_server_root>/alias/ocspSigningCert.p12 <new_server_root>/alias/ocspSigningCert.p12- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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> 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- 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_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- Optionally, delete the PKCS #12 files:
rm <new_server_root>/alias/ServerCert.p12 rm <new_server_root>/alias/ocspSigningCert.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_OCSP_instance>" -t "cu,cu,cu" -d . -P cert-<new_OCSP_instance>-<new_hostname>- -h <new_HSM_token_name>- 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- Optionally, delete the base-64 file:
rm <new_server_root>/alias/caSigningCert.b64- 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.
- 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)
- Case II: CMS 7.0, or CS 7.1 [TKS] - Software (old server) --> HSM (new server)
- Case III: CMS 7.0, or CS 7.1 [TKS] - HSM (old server) --> Software (new server)
- Case IV: CMS 7.0, or CS 7.1 [TKS] - HSM (old server) --> HSM (new server)
Case I: CMS 7.0, or CS 7.1 - [TKS] 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_TKS_instance>-<new_hostname>-c ert8.db rm <new_server_root>/alias/cert-<new_TKS_instance>-<new_hostname>-k ey3.db- Login as the <old_user> on the machine hosting the old server.
- 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>.
- 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>.- 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_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- 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,- 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.
- 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)
- 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- Login as the <old_user> on the machine hosting the old server.
- 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>.
- 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).
- 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- 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_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- 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>-- 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- 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- 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- 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_TKS_instance>-<new_hostname>-- 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- Optionally, delete the PKCS #12 file:
rm <new_server_root>/alias/ServerCert.p12- 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- 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- Optionally, delete the base-64 files:
rm <new_server_root>/alias/caSigningCert.b64 rm <new_server_root>/alias/tksTransportCert.b64- 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.
- 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.
- 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.
- 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.
- 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)
- 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.
- Login as the <old_user> on the machine hosting the old server.
- 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>.
- In order to migrate symmetric keys from your old TKS instance, the following will be needed:
- 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- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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- 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.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- 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- Optionally, delete the PKCS #12 file:
rm <new_server_root>/alias/ServerCert.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_TKS_instance>" -t "cu,cu,cu" -d . -P cert-<new_TKS_instance>-<new_hostname>-- 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- Optionally, delete the base-64 files:
rm <new_server_root>/alias/caSigningCert.b64 rm <new_server_root>/alias/tksTransportCert.b64- 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.
- 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.
- 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.
- 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.
- 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)
- 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.
- Login as the <old_user> on the machine hosting the old server.
- 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>.
- In order to migrate symmetric keys from your old TKS instance, the following will be needed:
- 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- 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:
- cd <old_server_root>/alias
- 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- Use the old certutil executable to identify the old HSM slot name:
<old_server_root>/bin/cert/tools/certutil -U -d .- 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- 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.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- 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 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- Optionally, delete the PKCS #12 file:
rm <new_server_root>/alias/ServerCert.p12- 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>- 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- Optionally, delete the base-64 files:
rm <new_server_root>/alias/caSigningCert.b64 rm <new_server_root>/alias/tksTransportCert.b64- 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.
- 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.
- 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.
- 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.
- 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
- CMS 4.2, CMS 4.2 (SP 2), CMS 4.5, or iCMS 4.7 Password Cache Data
- CMS 6.0, CMS 6.1, CMS 6.2, CMS 7.0, or CS 7.1 Password Cache Data and Password.conf
CMS 4.1 Password Cache Data
- 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.
- 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.
- Login as the <new_user> on the machine hosting the new server, and recreate the pwcache.db in the latest CS instance:
- Go to the following directory:
cd <new_server_root>/cert-<new_instance>/config- 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).
- 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.- Save the value portion of the key id into a local file such as key.txt.
- Save the value portion of the key id into the CS.cfg file under the variable "pwcKeyid":
- Execute the following command to create an empty new password cache file (e. g . - Linux/UNIX):
touch pwcache.db- 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- 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
- 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.
- Login as the <new_user> on the machine hosting the new server, and recreate the pwcache.db in the latest CS instance:
- Go to the following directory:
cd <new_server_root>/cert-<new_instance>/config- 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).
- 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.- Save the value portion of the key id into a local file such as key.txt.
- Save the value portion of the key id into the CS.cfg file under the variable "pwcKeyid":
- Execute the following command to create an empty new password cache file (e. g. - Linux/UNIX):
touch pwcache.db- 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- 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
- 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.- 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- 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- 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- Recreate the pwcache.db in the latest CS instance:
- 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).
- 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.- Save the value portion of the key id into a local file such as key.txt.
- Save the value portion of the key id into the CS.cfg file under the variable "pwcKeyid":
- Execute the following command to create an empty new password cache file (e. g. - Linux/UNIX):
touch pwcache.db- 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- 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
- CMS 4.2 Internal DB Data
- CMS 4.2 (SP 2) Internal DB Data
- CMS 4.5 Internal DB Data
- iCMS 4.7 Internal DB Data
- CMS 6.0 Internal DB Data
- CMS 6.01 Internal DB Data
- CMS 6.1 Internal DB Data
- CMS 6.2 Internal DB Data
- CMS 7.0 Internal DB Data
- CS 7.1 Internal DB Data
CMS 4.1 Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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- 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- 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- 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
- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd <old_server_root>/bin/cert/migrate/41ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
CMS 4.2 Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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- 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- 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- 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
- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd <old_server_root>/bin/cert/migrate/42ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
CMS 4.2 (SP 2) Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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- 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- 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- 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
- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd <old_server_root>/bin/cert/migrate/42SP2ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
CMS 4.5 Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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- 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- 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- 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
- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go the following directory:
cd <old_server_root>/bin/cert/migrate/45ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
iCMS 4.7 Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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- 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- 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- 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- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go the following directory:
cd <old_server_root>/bin/cert/migrate/47ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
CMS 6.0 Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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:
- 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- 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- 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
- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd <old_server_root>/bin/cert/migrate/60ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
CMS 6.01 Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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- 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- 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- 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- 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- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd <old_server_root>/bin/cert/migrate/60ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
CMS 6.1 Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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- 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- 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- 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- 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
- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd <old_server_root>/bin/cert/migrate/61ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
CMS 6.2 Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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- 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- 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- 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- 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
- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd <old_server_root>/bin/cert/migrate/62ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
CMS 7.0 Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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- 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- 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- 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- 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
- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd <old_server_root>/bin/cert/migrate/70ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
CS 7.1 Internal DB Data
- 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
- 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.
- Go to the following directory:
cd <new_server_root>/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv <new_server_root>/bin/cert/upgrade <new_server_root>/bin/cert/migrate- 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.- 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- 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- 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- 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- 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- 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
- 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.
- Go to the following directory:
cd <old_server_root>/slapd-<old_instance>-db/ldif- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd <old_server_root>/bin/cert/migrate/71ToTxt- In run.sh, set SERVER_ROOT=<old_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<old_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- 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:
- Go to the following directory:
cd <new_server_root>/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=<new_server_root> and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=<new_instance> and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CS server instance's internal database. To do this:
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:
- 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).
- 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:
- If a configuration directory resides on this machine, execute the specified commands:
cd <new_server_root>/slapd-<new_config_directory_instance> start-slapd- For each internal DB that resides on this machine, execute the specified commands:
cd <new_server_root>/slapd-<new_instance>-db start-slapd- Execute the specified commands to start the Administration Server:
cd <new_server_root> start-admin- For each new CS subsystem that resides on this machine, execute the specified commands:
cd <new_server_root>/cert-<new_instance> start-certStep 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
- Renew a [CA] SSL Server Certificate by Issuing an SSL Server Certificate Request
- Renew a [DRM], [OCSP], or [TKS] SSL Server Certificate
Renew a [CA] SSL Server Certificate by Signing it with your CA Signing Certificate
- Go to the following directory:
cd <new_server_root>- Execute the following command:
startconsole- Login to the primary Red Hat console.
- Highlight your newly imported CS instance, and login to the Red Hat CS console associated with this CS instance.
- In the Red Hat CS console, select the tab entitled "Configuration".
- Highlight the "System Keys and Certificates" option from the menu on the left-hand side.
- Select the tab entitled "Local Certificates" on the right-hand side.
- Press the button labeled "Add/Renew" to launch the "Certificate Setup Wizard":
- The first panel is entitled "Introduction"; click "Next>".
- The next panel is entitled "Type of Operation"; select the "Request a certificate" option (the default), and click "Next>".
- 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>".
- 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>".
- The next panel is entitled "Message Digest Algorithm". Select the desired hashing algorithm (or use the default of SHA-1), and click "Next>".
- 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>".
- Click through the remainder of the panels in the "Certificate Setup Wizard" selecting the desired options (or merely accepting the defaults).
- The newly migrated CA's SSL Server Certificate should automatically be renewed containing the correct data.
- Dismiss the Red Hat CS console.
- Dismiss the primary Red Hat console.
- 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>- Shutdown this particular new CS CA instance:
stop-cert- Restart this particular new CS CA instance:
start-certRenew 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.
- Go to the following directory:
cd <new_server_root>- Execute the following command:
startconsole- Login to the primary Red Hat console.
- Highlight your newly imported CS instance, and login to the Red Hat CS console associated with this CS instance.
- In the Red Hat CS console, select the tab entitled "Configuration".
- Highlight the "System Keys and Certificates" option from the menu on the left-hand side.
- Select the tab entitled "Local Certificates" on the right-hand side.
- Press the button labeled "Add/Renew" to launch the "Certificate Setup Wizard":
- The first panel is entitled "Introduction"; click "Next>".
- The next panel is entitled "Type of Operation"; select the "Request a certificate" option (the default), and click "Next>".
- 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.
- 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>".
- 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>".
- Click through the remainder of the panels in the "Certificate Setup Wizard" selecting the desired options (or merely accepting the defaults).
- Obtain the SSL Server Certificate Request, and store it in a file with a base-64 encoded format.
- Submit the SSL Server Certificate Request to a CA, and await approval of this request.
- Once the SSL Server Certificate has been approved, relaunch the "Certificate Setup Wizard" by once again pressing the button labeled "Add/Renew".
- The first panel is entitled "Introduction"; click "Next>".
- The next panel is entitled "Type of Operation"; this time, select the "Install a certificate" option, and click "Next>".
- The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and click "Next>".
- The next panel is entitled "Location of Certificate"; enter in the desired information, and click "Next>".
- 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.
- Dismiss the Red Hat CS console.
- Dismiss the primary Red Hat console.
- 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>- Shutdown this particular new CS CA instance:
stop-cert- Restart this particular new CS CA instance:
start-certRenew a [DRM], [OCSP], or [TKS] SSL Server Certificate
- Go to the following directory:
cd <new_server_root>- Execute the following command:
startconsole- Login to the primary Red Hat console.
- Highlight your newly imported CS instance, and login to the Red Hat CS console associated with this CS instance.
- In the Red Hat CS console, select the tab entitled "Configuration".
- Highlight the "System Keys and Certificates" option from the menu on the left-hand side.
- Select the tab entitled "Local Certificates" on the right-hand side.
- Press the button labeled "Add/Renew" to launch the "Certificate Setup Wizard":
- The first panel is entitled "Introduction"; click "Next>".
- The next panel is entitled "Type of Operation"; select the "Request a certificate" option (the default), and click "Next>".
- 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.
- 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>".
- 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>".
- Click through the remainder of the panels in the "Certificate Setup Wizard" selecting the desired options (or merely accepting the defaults).
- Obtain the SSL Server Certificate Request, and store it in a file with a base-64 encoded format.
- Submit the SSL Server Certificate Request to a CA, and await approval of this request.
- Once the SSL Server Certificate has been approved, relaunch the "Certificate Setup Wizard" by once again pressing the button labeled "Add/Renew".
- The first panel is entitled "Introduction"; click "Next>".
- The next panel is entitled "Type of Operation"; this time, select the "Install a certificate" option, and click "Next>".
- The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and click "Next>".
- The next panel is entitled "Location of Certificate"; enter in the desired information, and click "Next>".
- 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.
- Dismiss the Red Hat CS console.
- Dismiss the primary Red Hat console.
- 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>- Shutdown this particular new CS subsystem instance:
stop-cert- Restart this particular new CS subsystem instance:
start-certStep 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.xmlDetailed Example of a CS Migration
The following detailed example is provided for reference:
- 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:
- Stop the CMS 6.1 (SP 4) RA instance:
cd /usr/netscape/servers/cert-ra stop-cert- Stop the associated CMS 6.1 (SP 4) RA internal-DB instance:
cd /usr/netscape/servers/slapd-ra-db stop-slapdSince 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:
- 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- Stop the CMS 6.1 (SP 4) Admin Server instance:
cd /usr/netscape/servers stop-admin- 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- Stop the CMS 6.1 (SP 4) Configuration Directory Server instance:
cd /usr/netscape/servers/slapd-ds stop-slapdFinally, 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
- Create a new CS 7.1 installation on the machine called "omega.example.com" running Red Hat Enterprise Linux (RHEL) 4:
- 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- 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".- Go to the following directory:
cd /opt/redhat-cs- Execute the following command:
./setup/setup- Configure "cert-ca":
Step 3: Stopping all new CS instances
- Execute the following commands to stop the CS 7.1 CA instance:
cd /opt/redhat-cs/cert-ca stop-cert- Execute the following commands to stop the CS 7.1 Administration Server:
cd /opt/redhat-cs stop-admin- Execute the following commands to stop the CS 7.1 CA internal DB instance:
cd /opt/redhat-cs/slapd-ca-db stop-slapd- Execute the following commands to stop the CS 7.1 Configuration Directory Server instance:
cd /opt/redhat-cs/slapd-ds stop-slapdStep 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:
- 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- 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- 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- 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- 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-- 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
- 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- 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- 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.
- Create new software security databases:
/opt/redhat-cs/bin/cert/tools/certutil.sh -N -d . -P cert-ca-omega-- 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
- 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- 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- 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
- 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
- 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.
- 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- Login to "omega.example.com" as "csuser", and change into the correct directory:
cd /opt/redhat-cs/cert-ca/config- 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- Recreate the pwcache.db in the latest CS instance:
- 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).
- 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.- Save the value portion of the key id into a local file such as key.txt.
- Save the value portion of the key id into the CS.cfg file under the variable "pwcKeyid":
- Execute the following command to create an empty new password cache file:
touch pwcache.db- 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- 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 : diamondStep 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
- 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- 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.
- Go to the following directory:
cd /opt/redhat-cs/bin/cert- Rename the misnamed "upgrade" directory to "migrate":
mv /opt/redhat-cs/bin/cert/upgrade /opt/redhat-cs/bin/cert/migrate- 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.- 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- 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- 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- 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- 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- 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- 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.
- Go to the following directory:
cd /usr/netscape/servers/slapd-ca-db/ldif- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd /usr/netscape/servers/bin/cert/migrate/61ToTxt- In run.sh, set SERVER_ROOT=/usr/netscape/servers and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=ca and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance.
- Go to the following directory:
cd /opt/redhat-cs/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=/opt/redhat-cs and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=ca and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new CA server instance's internal database. To do this:
Step 7: Customization of User Data (non-Console)
This particular example contains no user customizations.
Step 8: Starting all new CS instances
- Execute the following commands to start the CS 7.1 Configuration Directory Server instance:
cd /opt/redhat-cs/slapd-ds start-slapd- Execute the following commands to start the CS 7.1 CA internal DB instances:
cd /opt/redhat-cs/slapd-ca-db start-slapd- Execute the following commands to start the CS 7.1 Administration Server:
cd /opt/redhat-cs start-admin- Execute the following commands to start the CS 7.1 CA instance:
cd /opt/redhat-cs/cert-ca start-certStep 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:
- Go to the following directory:
cd /opt/redhat-cs- Execute the following command:
startconsole- Login to the primary Red Hat console.
- Highlight your newly imported CS instance, and login to the Red Hat CS console associated with this CS instance.
- In the Red Hat CS console, select the tab entitled "Configuration".
- Highlight the "System Keys and Certificates" option from the menu on the left-hand side.
- Select the tab entitled "Local Certificates" on the right-hand side.
- Press the button labeled "Add/Renew" to launch the "Certificate Setup Wizard":
- The first panel is entitled "Introduction"; click "Next>".
- The next panel is entitled "Type of Operation"; select the "Request a certificate" option (the default), and click "Next>".
- 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>".
- 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>".
- The next panel is entitled "Message Digest Algorithm". Select the desired hashing algorithm (or use the default of SHA-1), and click "Next>".
- 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>".
- Click through the remainder of the panels in the "Certificate Setup Wizard" selecting the desired options (or merely accepting the defaults).
- The newly migrated CA's SSL Server Certificate should automatically be renewed containing the correct data.
- Dismiss the Red Hat CS console.
- Dismiss the primary Red Hat console.
- 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- Shutdown this particular new CS CA instance:
stop-cert- Restart this particular new CS CA instance:
start-certStep 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
- For this example, since all subsystems are being migrated to the same machine, this step has already been accomplished during the CA subsystem migration.
- Configure "cert-drm":
- Use the Red Hat console to create "cert-drm".
- In another terminal session, go to the following directory:
cd /opt/redhat-cs/cert-drm/config- Edit the file called "CertSetup.cfg" and append the following line to the end of this file:
kra.keySplitting=true- Back in the Red Hat console, configure "cert-drm".
- Dismiss the Red Hat console.
Step 3: Stopping all new CS instances
- 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
- Execute the following commands to stop the CS 7.1 Administration Server:
cd /opt/redhat-cs stop-admin- 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- Execute the following commands to stop the CS 7.1 Configuration Directory Server instance:
cd /opt/redhat-cs/slapd-ds stop-slapdStep 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:
- 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- 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- 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- 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- 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- 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.
- 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.- 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- 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- 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.- Create new software security databases:
/opt/redhat-cs/bin/cert/tools/certutil.sh -N -d . -P cert-drm-omega-- 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- 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- 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- 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- Optionally, delete the base-64 file:
rm /opt/redhat-cs/alias/caSigningCert.b64- 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.
- 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
- 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.- 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- Login to "omega.example.com" as "csuser", and change into the correct directory:
cd /opt/redhat-cs/cert-drm/config- 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- Recreate the pwcache.db in the latest CS instance:
- 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).
- 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.- Save the value portion of the key id into a local file such as key.txt.
- Save the value portion of the key id into the CS.cfg file under the variable "pwcKeyid":
- Execute the following command to create an empty new password cache file:
touch pwcache.db- 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- 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 : emeraldStep 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
- 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- 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.
- 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- 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.
- Go to the following directory:
cd /usr/netscape/servers/slapd-drm-db/ldif- 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
- Convert the "old.ldif" file into an "old.txt" format by running the following (examples are for a Linux/UNIX system).
- Go to the following directory:
cd /usr/netscape/servers/bin/cert/migrate/61ToTxt- In run.sh, set SERVER_ROOT=/usr/netscape/servers and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=drm and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- 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- 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- 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- Convert the "old.txt" file into an "old.ldif" format compatible with the new server instance.
- Go to the following directory:
cd /opt/redhat-cs/bin/cert/migrate/TxtTo71- In run.sh, set SERVER_ROOT=/opt/redhat-cs and uncomment it
- In run.sh, uncomment export SERVER_ROOT
- In run.sh, set INSTANCE=drm and uncomment it
- In run.sh, uncomment export INSTANCE
- 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- Import the "old.ldif" LDIF file into this new DRM server instance's internal database. To do this:
Step 7: Customization of User Data (non-Console)
This particular example contains no user customizations.
Step 8: Starting all new CS instances
- Execute the following commands to start the CS 7.1 Configuration Directory Server instance:
cd /opt/redhat-cs/slapd-ds start-slapd- 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- Execute the following commands to start the CS 7.1 Administration Server:
cd /opt/redhat-cs start-admin- 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-certStep 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:
- Go to the following directory:
cd /opt/redhat-cs- Execute the following command:
startconsole- Login to the primary Red Hat console.
- Highlight your newly imported CS instance, and login to the Red Hat CS console associated with this CS instance.
- In the Red Hat CS console, select the tab entitled "Configuration".
- Highlight the "System Keys and Certificates" option from the menu on the left-hand side.
- Select the tab entitled "Local Certificates" on the right-hand side.
- Press the button labeled "Add/Renew" to launch the "Certificate Setup Wizard":
- The first panel is entitled "Introduction"; click "Next>".
- The next panel is entitled "Type of Operation"; select the "Request a certificate" option (the default), and click "Next>".
- 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.
- 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>".
- 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>".
- Click through the remainder of the panels in the "Certificate Setup Wizard" selecting the desired options (or merely accepting the defaults).
- Obtain the SSL Server Certificate Request, and store it in a file with a base-64 encoded format.
- Submit the SSL Server Certificate Request to a CA, and await approval of this request.
- Once the SSL Server Certificate has been approved, relaunch the "Certificate Setup Wizard" by once again pressing the button labeled "Add/Renew".
- The first panel is entitled "Introduction"; click "Next>".
- The next panel is entitled "Type of Operation"; this time, select the "Install a certificate" option, and click "Next>".
- The next panel is entitled "Certificate Selection"; select "SSL Server Certificate" from the pull-down menu, and click "Next>".
- The next panel is entitled "Location of Certificate"; enter in the desired information, and click "Next>".
- 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.
- Dismiss the Red Hat CS console.
- Dismiss the primary Red Hat console.
- 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- Shutdown this particular new CS subsystem instance:
stop-cert- Restart this particular new CS subsystem instance:
start-certStep 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
- For this example, since all subsystems are being migrated to the same machine, this step has already been accomplished during the CA subsystem migration.
- Configure "cert-ocsp":
Step 3: Stopping all new CS instances
- 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- Execute the following commands to stop the CS 7.1 Administration Server:
cd /opt/redhat-cs stop-admin- 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- Execute the following commands to stop the CS 7.1 Configuration Directory Server instance:
cd /opt/redhat-cs/slapd-ds stop-slapdStep 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:
- 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- 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- 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- 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- 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- 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
- 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.
- 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.