15.2. DRM Migration

15.2.1. Step 1: Preparing the Old Server

Since a complete backup of all Certificate Management System 6.1 (SP 4) instances was made during the CA subsystem migration, it is not required to make another backup during the DRM subsystem migration.

NOTE

All the Certificate System 6.1 subsystems should still be stopped from the previous migration.

15.2.2. Step 2: Creating a New Certificate System Installation

Install a new Certificate System 7.2 DRM on the Red Hat Enterprise Linux 4 (AS) machine, server.example.com.
1. Download the Certificate System packages from the Red Hat Network or through the up2date command.
2. To install the subsystems, run the install utility; this is not necessary if the subsystems were installed through up2date.
```
rhpki-install -pki-subsystem=kra
 -pki_package_path=/media/cdrom/RedHat/RPMS -force
```
Configure the DRM instance. It is possible to change the names of migrated Certificate System subsystem instances, but greater care must be taken when extracting and renaming certain portions of the data. Because port numbers are stored in the server.xml file, which is unaffected by subsystem migration, port numbers can be changed between instances without difficulty.

Go through the HTML configuration wizard. When the installation process is completed, the server returns a URL pointing to the configuration wizard. For example:
```
http://server.example.com:10080/kra/admin/console/config/
 login?pin=Yc6EuvuY2OeezKeX7REk
```
For more information on the panels in the configuration wizard, see chapter 2, "Installation and Configuration," in the Certificate System Administration Guide.

15.2.3. Step 3: Stopping All New Certificate System Instances

Stop the 7.2 DRM and CA instances.

/etc/init.d/rhpki-kra stop

/etc/init.d/rhpki-ca stop

Stop the Directory Server instance.

cd /opt/redhat-ds/slapd-ds

./stop-slapd

15.2.4. Step 4: Migrating Security Databases

NOTE

In order to recover the archived keys stored in the 6.1 (SP4) DRM, obtain a migration patch from Red Hat services. This patch will recover the PIN needed to access the storage token where the DRM private key resides.

Do the following to migrate the Certificate Management System 6.1 (SP4) DRM data to the Certificate System 7.2 DRM databases:

NOTE

For more information on migrating security databases to HSM, see Section 7.5.2.2, “Case II: Security Databases to HSM Migration”.

Log into server.example.com as the Certificate System user, and do the following:

Remove the 7.2 DRM security databases which will receive migrated data.

rm /var/lib/rhpki-kra/alias/cert8.db

rm /var/lib/rhpki-kra/alias/key3.db

Copy the certificate and key security databases from the old server to the new server.

cp /usr/netscape/servers/alias/cert-drm-alpha-cert8.db
 /var/lib/rhpki-kra/alias/cert8.db

cp /usr/netscape/servers/alias/cert-drm-alpha-key3.db
 /var/lib/rhpki-rhpki-kra/alias/key3.db

Log into the new server hosting server.example.com as the Certificate System user, and open the Certificate System alias/ directory.
```
cd /var/lib/rhpki-kra/alias
```
Log in as root, and set the file user and group to the new server Certificate System user and group.
```
su

chown pkiuser:pkiuser cert8.db

chown pkiuser:pkiuser key3.db
```
Log out as root. As the Certificate System user, change the permissions on the file.
```
chmod 00600 cert8.db

chmod 00600 key3.db
```

List the certificates stored in the old security databases by using the certutil command. In this example, -L lists the certificates.

certutil -L -d .

Server-Cert cert-drm cu,cu,cu
caSigningCert cert-drm cT,c,
kraStorageCert cert-drm u,u,u
kraTransportCert cert-drm u,u,u

Export the public/private key pairs of each entry in the Certificate System databases using the pk12util tool; -o exports the key pairs to a PKCS #12 file, and -n sets the name of the certificate and the old database prefix.

pk12util -o ServerCert.p12 -n "Server-Cert cert-drm" -d .

Enter Password or Pin for "NSS Certificate DB":********
Enter password for PKCS12 file: ********
Re-enter password: ********
pk12util: PKCS12 EXPORT SUCCESSFUL

pk12util -o kraStorageCert.p12 -n "kraStorageCert cert-drm" -d .

Enter Password or Pin for "NSS Certificate DB":********
Enter password for PKCS12 file: ********
Re-enter password: ********
pk12util: PKCS12 EXPORT SUCCESSFUL

pk12util -o kraTransportCert.p12 -n "kraTransportCert cert-drm" -d .

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 security databases do not contain any additional public/private key pairs.

Export the public key using the certutil tool; -L lists the certificate, -n sets the name of the file and the old prefix, and -a outputs the information to a base-64 file.
```
certutil -L -n "caSigningCert cert-drm" -d . -a > caSigningCert.b64
```
NOTE

In this example, the old security databases did not contain any additional public keys.
Delete the old security databases.
```
rm cert8.db

rm key3.db
```

Register the new HSM in the new token database.

modutil -nocertdb -dbdir . -add "epsilon" -libfile /usr/lib/libepsilon.so

Identify the new HSM slot name.
```
modutil -dbdir . -nocertdb -list
```
This reveals the rho, tau, and phi slots for the different subsystems. The tau slot is used for the DRM.
Create new security databases.
```
certutil -N -d .
```

Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM.

pk12util -i ServerCert.p12 -d . -h tau

Enter Password or Pin for "tau":********
Enter password for PKCS12 file: ********
pk12util: PKCS12 IMPORT SUCCESSFUL

pk12util -i kraStorageCert.p12 -d . -h tau

Enter Password or Pin for "tau":********
Enter password for PKCS12 file: ********
pk12util: PKCS12 IMPORT SUCCESSFUL

pk12util -i kraTransportCert.p12 -d . -h tau

Enter Password or Pin for "tau":********
Enter password for PKCS12 file: ********
pk12util: PKCS12 IMPORT SUCCESSFUL

Optionally, delete the PKCS #12 files.

rm ServerCert.p12

rm kraStorageCert.p12

rm kraTransportCert.p12

Set the trust bits on the public/private key pairs that were imported into the new HSM.

certutil -M -n "tau:Server-Cert cert-drm" -t "cu,cu,cu" -d . -h epsilon

certutil -M -n "tau:kraStorageCert cert-drm" -t "u,u,u" -d . -h epsilon

certutil -M -n "tau:kraTransportCert cert-drm" -t "u,u,u" -d . -h epsilon

Import the public key from the base-64file into the new HSM, and set the trust bits.

certutil -A -n "tau:caSigningCert cert-drm" 
-t "CT,c," -d . -h epsilon -i caSigningCert.b64

Optionally, delete the base-64 file.
```
rm caSigningCert.b64
```
Open the CS.cfg configuration file.
```
cd /var/lib/rhpki-kra/conf/

vi CS.cfg
```
Edit the kra.storageUnit.nickname and kra.transportUnit.nickname attributes for the new DRM and HSM information.
```
kra.storageUnit.nickname=tau:kraStorageCert cert-drm
kra.transportUnit.nickname=tau:kraTransportCert cert-drm
```
NOTE

The caSigningCert is not referenced in the CS.cfg file.
In the same directory, edit the serverCertNick.conf file to contain the old certificate nickname. For example:
```
vi serverCertNick.conf

tau:Server-Cert cert-drm
```

15.2.5. Step 5: Migrating Password Cache Data

To migrate the data from the 6.1 pwdcache.db and password.conf files to the 7.2 password.conf, do the following:

NOTE

For more information on migrating the password cache from 6.1 to 7.2, see Section 8.3, “Migrating 6.0, 6.1, 6.2, 7.0, and 7.1 Password Cache Data”.

Log into the the old server on alpha.example.com as the Certificate System user, and run PasswordCache to extract the contents from the password cache.

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 the 6.1 Certificate System uses password.conf start the DRM instance automatically on alpha.example.com, copy the password.conf file to server.example.com, overwriting any existing password.conf file:
```
cp /usr/netscape/servers/cert-drm/config/password.conf 
/var/lib/rhpki-kra/conf/password.conf
```
Log into the new server hosting server.example.com as the Certificate System user, and open the Certificate System conf/ directory.
```
cd /var/lib/rhpki-kra/conf/
```
Log in as root, and set the file user and group to the new server Certificate System user and group.
```
su

chown pkiuser:pkiuser password.conf
```
Log out as root. As the Certificate System user, change the permissions on the file.
```
chmod 00600 password.conf
```
Copy the extracted passwords from the 6.1 pwdcache.db database into the 7.2 password.conf file.

15.2.6. Step 6: Migrating Internal Databases

Migrate the internal databases of the 6.1 DRM to the 7.2 DRM internal databases by doing the following:

NOTE

For more information on migrating internal databases, see Section 9.8, “Migrating Internal Databases for 6.1”.

Log into the new DRM instance server hosting server.example.com as the Certificate System user, and export the new internal database content to LDIF.
```
cd /opt/redhat-ds/slapd-DS-instance/db

db2ldif -n server.example.com-rhpki-kra
```
The LDIF file location is given when the export from the database is complete.
```
ldif file: 
/opt/redhat-ds/slapd-DS-instance/ldif/2005_06_07_720658.ldif
```
Open the given LDIF location, and rename the LDIF file new.ldif.
```
cd /opt/redhat-ds/slapd-DS-instance/ldif

mv 2005_06_07_720658.ldif new.ldif
```
NOTE

For this example, since the new Certificate System migration utility was copied during the CA migration described previously, there is no need to obtain it again for the DRM migration.
Run the db2ldif command to export the database contents to LDIF.
```
cd /usr/netscape/servers/slapd-drm-db

db2ldif -n userRoot
```
The location of the LDIF file is shown when the export from the database is complete.
```
ldif file: 
/usr/netscape/servers/slapd-drm-db/ldif/2005_06_07_390512.ldif
```

Open the given LDIF location, and rename the LDIF file 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.

NOTE

For this example, the amount of data is relatively small, so any text editor work. For large files, use an appropriate program.
1. Open the 6.1 DRM database ldif/ directory.
```
cd /usr/netscape/servers/slapd-drm-db/ldif/
```
2. Replace the following entry with the one in new.ldif:
```
cn=aclResources,o=CertificateServer
```
Convert the old.ldif file to a text file.
1. Open the version-to-text directory in the 6.1 migration directory.
```
cd /usr/netscape/servers/bin/cert/migrate/61ToTxt
```
2. Edit the run.sh script by uncommenting and setting the values for the following lines:
  - SERVER_ROOT=/usr/netscape/servers
  - export SERVER_ROOT
  - INSTANCE=drm
  - export INSTANCE
3. Run the run.sh to use the old.ldif file to create a text file.
```
run.sh /usr/netscape/servers/slapd-drm-db/ldif/old.ldif >
 /usr/netscape/servers/slapd-drm-db/ldif/old.txt
```

Open the 6.1 DRM LDIF directory, and copy the old.txt file to the 7.2 DRM internal database LDIF directory.

cd /usr/netscape/servers/slapd-drm-db/ldif

cp /usr/netscape/servers/slapd-drm-db/ldif/old.txt
 /opt/redhat-ds/slapd-DS-instance/ldif/old.txt

Log into the new DRM instance server hosting server.example.com as the Certificate System user, and open the Certificate System ldif directory.
```
cd /opt/redhat-ds/slapd-DS-instance/ldif
```
Log in as root, and set the file user and group to the Certificate System user and group.
```
su

chown pkiuser:pkiuser old.txt
```
Log out as root. As the Certificate System user, change the permissions on the file.
```
chmod 00600 old.txt
```
Convert the old.txt file to LDIF.
1. Open the migration tools directory.
```
cd /usr/share/rhpki/migrate/TxtTo72
```
2. Edit run.sh by uncommenting and setting the values for the following lines:
  - SERVER_ROOT=/var/lib
  - export SERVER_ROOT
  - INSTANCE=rhpki-kra
  - export INSTANCE
3. Run run.sh to use old.txt to create an LDIF file.
```
run.sh /opt/redhat-ds/slapd-DS-instance/ldif/old.txt > 
/opt/redhat-ds/slapd-DS-instance/ldif/old.ldif
```
Import the old.ldif LDIF file into this new DRM server instance's internal database.
1. Open the 7.2 DRM database directory.
```
cd /opt/redhat-ds/slapd-DS-instance/db/
```
2. Run the ldif2db tool to import the LDIF into the DRM database.
```
ldif2db -n server.example.com-rhpki-ca
 -i /opt/redhat-ds/slapd-DS-instance/ldif/old.ldif
```
3. Force the virtual list views (VLV) indexes to be re-indexed.
```
db2index
```

15.2.7. Step 7: Customizing User Data (Non-Console)

This example contains no user customizations.

15.2.8. Step 8: Starting All New Certificate System Instances

Start the Directory Server instance.

cd /opt/redhat-ds/slapd-DS-instance

./start-slapd

Start the 7.2 CA and DRM instances.

/etc/init.d/rhpki-ca start

/etc/init.d/rhpki-kra start

15.2.9. Step 9: Renewing the Certificate System Server Certificates

Renew the SSL server certificate for the DRM by doing the following:

NOTE

For more information on renewing subsystem server certificates, see Section 12.3, “Renewing a DRM, OCSP, or TKS SSL Server Certificate”.

Start the DRM Console.

pkiconsole https://server.example.com:10443/kra

Select the DRM instance from the list of server, and log into the Console for that instance.
In the Console, select the Configuration tab.
Select the System Keys and Certificates option from the menu on the left.
Select the Local Certificates tab on the right.
Press the Add/Renew button to launch the Certificate Setup Wizard.
Go through the wizard panels, and fill in the required information.
1. In the Type of Operation panel, select the Request a certificate option (the default).
2. In the Certificate Selection panel, select SSL Server Certificate from the pull-down menu. An SSL server certificate request is generated which can be submitted to another CA for approval.
3. In the Key-Pair Information for the SSL Server Certificate panel, select Create new key pair since the renewed SSL server certificate requires changing the CN component of its DN. Fill in information in the other fields on this panel as desired.
4. The next panel is Subject Name for the SSL Certificate. For the CN component, enter server.example.com. Fill in information in the other fields on this panel as desired; it is strongly recommended that the O and C components be filled in.
5. Click through the remaining panels in the Certificate Setup Wizard and either fill in the options as desired or accept the defaults.
Obtain the SSL server certificate request, and store it in a base-64 file.
Submit the SSL server certificate request to a CA for approval.
When the SSL server certificate is approved, relaunch the Certificate Setup Wizard by pressing the Add/Renew button.
Go through the wizard again and supply the certificate information.
1. In the Type of Operation panel, select the Install a certificate option.
2. In the Certificate Selection panel, select SSL Server Certificate from the pull-down menu.
3. Enter in the location information if required in the Location of Certificate panel.
4. Click through the remaining panels in the Certificate Setup Wizard to install the renewed SSL server certificate for the migrated DRM instance.
Close the Console windows.
Restart the 7.2 DRM instance.
```
/etc/init.d/rhpki-kra restart
```

15.2.10. Step 10: Customizing User Data (Console)

This example contains no user customizations.

15.2.11. Step 11: Verifying Migration

After migrating the Certificate Management System 6.1 (SP 4) DRM instance to the corresponding Certificate System 7.2 DRM instance, access the end-entity services and the agent services interfaces of both the Certificate System 7.2 CA and DRM instances to ensure that everything is working properly.

https://server.example.com:10043/kra

Also, log into the subsystem administrative consoles to verify that that the Certificate System subsystems can be managed through the Console.

pkiconsole https://server.example.com:10043/kra

The port numbers for all CA and DRM interfaces can be found in the server.xml in the subsystem configuration directories.