15.3. OCSP Migration

15.3.1. Step 1: Preparing the Old Server

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

NOTE

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

15.3.2. Step 2: Creating a New Certificate System Installation

Install a new Certificate System 7.2 system 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=ocsp
 -pki_package_path=/media/cdrom/RedHat/RPMS -force
```
Configure the OCSP 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:11080/ocsp/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.3.3. Step 3: Stopping All New Certificate System Instances

Stop the Certificate System 7.2 OCSP, DRM, and CA instances.

/etc/init.d/rhpki-ocsp stop

/etc/init.d/rhpki-kra stop

/etc/init.d/rhpki-ca stop

Stop the Directory Server;

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

./stop-slapd

15.3.4. Step 4: Migrating Security Databases

To migrate the data from the 6.1 security databases to the 7.2 HSM, do the following:

NOTE

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

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

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

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

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

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

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

Log into the new server, server.example.com, as the Certificate System user, and open the Certificate System alias/ directory.
```
cd /var/lib/rhpki-ocsp/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-ocsp cu,cu,cu
caSigningCert cert-ocsp CT,c,
ocspSigningCert cert-ocsp cu,cu,cu
```

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 gives the name of the certificate and the old database prefix.

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

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

pk12util -o ocspSigningCert.p12 -n "ocspSigningCert cert-ocsp" -d .

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

NOTE

The 6.1 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-ocsp" -d . -a > caSigningCert.b64
```
NOTE

The 6.1 security databases do 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 lists the slots rho, tau, and phi. The phi slot is used for the OCSP.
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 phi

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

pk12util -i ocspSigningCert.p12 -d . -h phi

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

Optionally, delete the PKCS #12 files.

rm ServerCert.p12

rm ocspSigningCert.p12

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

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

certutil -M -n "phi:ocspSigningCert cert-ocsp" -t "cu,cu,cu" -d . -h epsilon

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

certutil -A -n "phi:caSigningCert cert-ocsp" -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-ocsp/conf

vi CS.cfg
```
Edit the ocsp.signing.certnickname attribute to reflect the new OCSP information.
```
ocsp.signing.certnickname=phi:ocspSigningCert cert-ocsp
```
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

phi:Server-Cert cert-ocsp
```

15.3.5. Step 5: Migrating Password Cache Data

Migrate the password cache data from the 6.1 pwcache.db and password.conf files to the 7.2 password.conf file by doing the following:

NOTE

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

Log into alpha.example.com as the Certificate System user, and use the PasswordCache tool to extract the passwords from the old password cache.

cd /usr/netscape/servers/cert-ocsp/config

/usr/netscape/servers/bin/cert/tools/PasswordCache sapphire 
-d /usr/netscape/servers/alias -P cert-ocsp-alpha-

list
cert/key prefix = cert-ocsp-alpha-
path = /usr/netscape/servers/alias
about to read password cache
----- Password Cache Content -----
internal : sapphire
Internal LDAP Database : sapphire

Write down this information.
Since this example used a password.conf file to start the OCSP instance automatically on the alpha.example.com machine, copy the password.conf file to server.example.com, overwriting any existingpassword.conf file:
```
cp /usr/netscape/servers/cert-ocsp/config/password.conf 
/var/lib/rhpki-ocsp/conf/password.conf
```
Log into server.example.com as the Certificate System user, and open the Certificate System conf/ directory.
```
cd /var/lib/rhpki-ocsp/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 data extracted from the 6.1 pwdcache.db database into the 7.2 password.conf file.

15.3.6. Step 6: Migration of Internal Databases

To migrate the data from the 6.1 OCSP internal databases to the 7.2 OCSP internal databases, do the following:

NOTE

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

Log into the new OCSP server instance on 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-ocsp
```
The location and name of the LDIF file is shown once the conversion from the database to LDIF is complete.
```
ldif file: 
/opt/redhat-ds/slapd-DS-instance/ldif/2005_06_07_843092.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_843092.ldif new.ldif

Since the Certificate System migration utility is platform independent, always use the latest version of the migration utility on both server installations. The latest migration tools are available in the /bin/cert/upgrade directory of the new server instance.

NOTE

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

db2ldif -n userRoot
```
The location and name of the LDIF file is shown once the conversion from the database to LDIF is complete.
```
ldif file: 
/usr/netscape/servers/slapd-ocsp-db/ldif/2005_06_07_914768.ldif
```

Open the given LDIF location, and rename the LDIF file old.ldif.

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

mv 2005_06_07_914768.ldif old.ldif

Adjust the LDIF content of old.ldif.

NOTE

For this example, the LDIF file is small, so any text editor works. For large files, use an appropriate program.
1. Open the old Certificate System LDIF directory.
```
cd /usr/netscape/servers/slapd-ocsp-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=ocsp
  - export INSTANCE
3. Run the run.sh to use the old.ldif file to create a text file.
```
run.sh /usr/netscape/servers/slapd-ocsp-db/ldif/old.ldif >
 /usr/netscape/servers/slapd-ocsp-db/ldif/old.txt
```

Open the 6.1 OCSP LDIF directory, and copy the old.txt file into the 7.2 OCSP internal database LDIF directory.

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

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

Log into the new OCSP server instance on 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.txtfile to LDIF.
1. Open the text-to-version directory.
```
cd /usr/share/rhpki/migrate/TxtTo72
```
2. Edit the run.sh script by uncommenting and setting the values for the following lines:
  - SERVER_ROOT=/var/lib
  - export SERVER_ROOT
  - INSTANCE=rhpki-ocsp
  - 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 the 7.2 OCSP internal database.
1. Open the OCSP database directory.
```
cd /opt/redhat-ds/slapd-DS-instance
```
2. Import the old LDIF for the user directory.
```
ldif2db -n server.example.com-rhpki-ocsp
 -i /opt/redhat-ds/slapd-DS-instance/ldif/old.ldif
```
3. Force the virtual list views (VLV) indexes to be re-indexed.
```
db2index
```

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

This example contains no user customizations.

15.3.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, DRM, and OCSP instances.

/etc/init.d/rhpki-ca start

/etc/init.d/rhpki-kra start

/etc/init.d/rhpki-ocsp start

15.3.9. Step 9: Renewing the Certificate System Server Certificates

Renew the SSL server certificate for the 7.2 OCSP 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 OCSP Console.

pkiconsole https://server.example.com:11443/ocsp

In the Certificate System 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 panels in the wizard, and fill in the information as directed.
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 a 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 selected information or accept the defaults.
Obtain the SSL server certificate request, and save it in a base-64 file.
Submit the SSL server certificate request to a CA for approval.
After the SSL server certificate is approved, relaunch the Certificate Setup Wizard by pressing the Add/Renew button.
Go through the certificate wizard panels again, and supply the new certificate information as directed.
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 required information in the Location of Certificate panel.
4. Click through the remaining panels in the Certificate Setup Wizard to install the renewed SSL server certificate is the OCSP instance.
Close the Console windows.
Restart the new Certificate System subsystem instance.
```
/etc/init.d/rhpki-ocsp start
```

15.3.10. Step 10: Customizing User Data (Console)

This example contains no user customizations.

15.3.11. Step 11: Verifying Migration

After migrating the Certificate Management System 6.1 (SP4) OCSP instance to the Certificate System 7.2 OCSP instance, access the end-entity services and the agent services pages for the new CA, DRM, and OCSP subsystem instances to ensure that everything is working properly.

https://server.example.com:11443/ocsp

Also log into the 7.2 Console to verify that the new servers can be managed through the Console.

pkiconsole https://server.example.com:11443/ocsp

The port numbers for all CA, DRM, and OCSP interfaces can be found in the server.xml in the configuration directory of each subsystem.