Chapter 7. Step 4: Migrating Security Databases

Chapter 7. Step 4: Migrating Security Databases

7.1. Certificate Management System 4.1 Certificate Authority (CA) Migration
7.2. Certificate Management System 4.2
7.3. Netscape Certificate Management System 4.2 (SP 2) and 4.5 and iPlanet Certificate Management System 4.7
7.4. Certificate Management System 6.0
7.5. Certificate Management System 6.1 and 6.2
7.6. Certificate Management System 7.0 and Certificate System 7.1

For every Certificate System subsystem instance migration, the data from the old Certificate System's certificate (cert7.db or cert8.db) and key (key3.db) security databases must be extracted and copied into the new Certificate System's alias/ directory. Follow the migration procedure corresponding to the Certificate System being migrated.

7.1. Certificate Management System 4.1 Certificate Authority (CA) Migration

Determine if the Certificate Management System 4.1 Certificate Authority (CA) being migrated uses security databases, HSM, or both. There are four possible migration scenarios; follow the appropriate process for the deployment scenario being migrated.

7.1.1. Case I: Security Databases to Security Databases Migration

  1. Remove all the security databases in the new Certificate System which will receive migrated data. 

    rm /var/lib/instance_ID/alias/cert8.db

rm /var/lib/instance_ID/alias/key3.db

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

    cp old_server_root/cert-old_CA_instance/config/cert-old_CA_instance-cert7.db 
/var/lib/instance_ID/alias/cert7.db

cp old_server_root/cert-old_CA_instance/config/cert-old_CA_instance-key3.db 
/var/lib/instance_ID/alias/key3.db

  3. As the Certificate System user account, open the new Certificate System alias/ directory. 

    cd /var/lib/instance_ID/alias/

  4. Log in as root, and set the file user and group to the Certificate System user and group. 

    su

chown user:group cert7.db

chown user:group key3.db

  5. Log out as root. As the Certificate System user, set the permissions on the security database files. 

    chmod 00600 cert7.db

chmod 00600 key3.db

  6. Use the certutil tool to list all of the old Certificate System certificates. In this example, -L lists the certificates, and -X forces them to be read/write. 

    certutil -L -X -d .

Server-Cert cert-old_CA_instance cu,cu,cu 
caSigningCert cert-old_CA_instance cu,cu,cu

    NOTE

    The certificate database is automatically converted from cert7.db to cert8.db.

  7. Remove the cert7.db file from the alias/ directory. 

    rm cert7.db

  8. Open the CS.cfg configuration file in the CA instance directory. 

    cd /var/lib/instance_ID/conf

vi CS.cfg

  9. Modify the values for the ca.signing.cacertnickname and ca.ocsp_signing.cacertnickname attributes to reflect the new CA instance. 

    ca.signing.cacertnickname=
 caSigningCert cert-old_CA_instance
ca.ocsp_signing.cacertnickname=
 caSigningCert cert-old_CA_instance

  10. In the same directory, edit the serverCertNick.conf file to contain the old certificate nickname. For example: 

    vi serverCertNick.conf

Server-Cert cert-old_CA_instance

7.1.2. Case II: Security Databases to HSM Migration

  1. Remove all the security databases in the new Certificate System which will receive migrated data. 

    rm /var/lib/instance_ID/alias/cert8.db

rm /var/lib/instance_ID/alias/key3.db

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

    cp old_server_root/cert-old_CA_instance/config/cert-old_CA_instance-cert7.db 

/var/lib/instance_ID/alias/cert7.db

cp old_server_root/cert-old_CA_instance/config/cert-old_CA_instance-key3.db 
/var/lib/instance_ID/alias/key3.db

  3. As the Certificate System user account, open the new Certificate System's alias/ directory. 

    cd /var/lib/instance_ID/alias/

  4. Log in as root, and set the file user and group to the user and group as whom the Certificate System runs. 

    su

chown user:group cert7.db

chown user:group key3.db

  5. Log out as root. As the Certificate System user, set the permissions on the security database files. 

    chmod 00600 cert7.db

chmod 00600 key3.db

  6. Use the certutil tool to list all of the old Certificate Management System certificates. In this example, -L lists the certificates, and -X forces them to be read/write. 

    certutil -L -X -d .

Server-Cert cert-old_CA_instance cu,cu,cu 
caSigningCert cert-old_CA_instance cu,cu,cu

    NOTE

    The certificate database is automatically converted from cert7.db to cert8.db.

  7. 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-old_CA_instance" -d .

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

pk12util -o caSigningCert.p12 -n "caSigningCert cert-old_CA_instance" -d .

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

    NOTE

    The old security databases may contain additional public/private key pairs; these can also be extracted using pk12util.

  8. Remove the security databases from the alias/ directory. 

    rm cert7.db

rm cert8.db

rm key3.db

  9. Register the new HSM in the new token database. 

    modutil -nocertdb -dbdir . -add new_HSM_token_name
 -libfile new_HSM_library_path/new_HSM_library

  10. Identify the new HSM slot name. 

    modutil -dbdir . -nocertdb -list

  11. Create new security databases. 

    certutil -N -d .

  12. Import the public/private key pairs for each entry from the PKCS #12 files into the new HSM; -i imports the specified file, and -h sets the name for the new HSM. 

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

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

pk12util -i caSigningCert.p12 -d . -h new_HSM_slot_name

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

  13. Optionally, delete the PKCS #12 files from the alias/ directory. 

    rm ServerCert.p12

rm caSigningCert.p12

  14. Set the trust bits on the public/private key pairs that were imported into the new HSM; -t sets the trust. 

    certutil -M -n "new_HSM_slot_nameServer-Cert cert-old_CA_instance" -t "cu,cu,cu" 
-d . -h new_HSM_token_name

certutil -M -n "new_HSM_slot_name:caSigningCert cert-old_CA_instance" 
-t "CTu,CTu,CTu" -d . -h new_HSM_token_name

  15. Open the CS.cfg configuration file in the new CA instance directory. 

    cd /var/lib/instance_ID/conf/

vi CS.cfg

  16. Modify the value for the ca.signing.cacertnickname and ca.ocsp_signing.cacertnickname attributes to reflect the new HSM information. 

    ca.signing.cacertnickname=
 new_HSM_slot_name:caSigningCert cert-old_CA_instance

ca.ocsp_signing.cacertnickname=
 new_HSM_slot_name:caSigningCert cert-old_CA_instance

  17. In the same directory, edit the serverCertNick.conf file to contain the old certificate nickname. For example: 

    vi serverCertNick.conf

new_HSM_slot_name:Server-Cert cert-old_CA_instance

7.1.3. Case III: HSM to Security Databases Migration

  1. Extract the public/private key pairs from the HSM. The format for the extracted key pairs should be portable, such as a PKCS #12 file.

    The pk12util tool provided by the Certificate System cannot extract public/private key pairs from an HSM because of requirements in the FIPS 140-1 standard which protect the private key portion of an entry. To extract this information, contact the HSM vendor for more information. The extracted keys should not have any dependencies, such as nickname prefixes, on the HSM.

  2. Copy this PKCS #12 file from the old server to the new server. 

    cp old_server_root/cert-old_CA_instance/config/ServerCert.p12 
/var/lib/instance_ID/alias/ServerCert.p12

cp old_server_root/cert-old_CA_instance/config/caSigningCert.p12 
/var/lib/instance_ID/alias/caSigningCert.p12

  3. Log into the new server machine as the Certificate System user account. Open the new server alias/ directory. 

    cd /var/lib/instance_ID/alias/

  4. Log in as root and change the file user and group to the Certificate System user and group. 

    su

chown user:group ServerCert.p12

chown user:group caSigningCert.p12

  5. Log out as root. As the regular Certificate System user, change the permissions on the key pair files. 

    chmod 00600 ServerCert.p12

chmod 00600 caSigningCert.p12

  6. Import the public/private key pairs from the PKCS #12 files into the security databases; -i imports the designated file. 

    pk12util -i ServerCert.p12 -d . 

Enter Password or Pin for "NSS Certificate DB":********
Enter password for PKCS12 file: ********
pk12util: PKCS12 IMPORT SUCCESSFUL

pk12util -i caSigningCert.p12 -d .

Enter Password or Pin for "NSS Certificate DB":********
Enter password for PKCS12 file: ********
pk12util: PKCS12 IMPORT SUCCESSFUL

  7. Optionally, delete the PKCS #12 files from the alias/ directory. 

    rm ServerCert.p12

rm caSigningCert.p12

  8. Set the trust bits on the public/private key pairs that were imported into the new security databases; -t sets the trust. 

    certutil -M -n "Server-Cert cert-old_CA_instance" -t "cu,cu,cu" -d . 

certutil -M -n "caSigningCert cert-old_CA_instance" -t "CTu,CTu,CTu" -d .

  9. Open the new CA instance's CS.cfg file. 

    cd /var/lib/instance_ID/conf/

vi CS.cfg

  10. Edit the ca.signing.cacertnickname and ca.ocsp_signing.cacertnickname attributes to reflect the new CA instance directory. 

    ca.signing.cacertnickname=
 caSigningCert cert-old_CA_instance
ca.ocsp_signing.cacertnickname=
 caSigningCert cert-old_CA_instance

  11. In the same directory, edit the serverCertNick.conf file to contain the old certificate nickname. For example: 

    vi serverCertNick.conf

Server-Cert cert-old_CA_instance

7.1.4. Case IV: HSM to HSM Migration

  1. Extract the public/private key pairs from the HSM. The format for the extracted key pairs should be portable, such as a PKCS #12 file.

    The pk12util tool provided by the Certificate System cannot extract public/private key pairs from an HSM because of requirements in the FIPS 140-1 standard which protect the private key portion of an entry. To extract this information, contact the HSM vendor for more information. The extracted keys should not have any dependencies, such as nickname prefixes, on the HSM.

  2. Copy the data from the old server to the new server. 

    cp old_server_root/cert-old_CA_instance/config/ServerCert.p12 
/var/lib/instance_ID/alias/ServerCert.p12

cp old_server_root/cert-old_CA_instance/config/caSigningCert.p12 
/var/lib/instance_ID/alias/caSigningCert.p12

  3. Log into the new server machine as the Certificate System user, and open the new Certificate System alias/ directory. 

    cd /var/lib/instance_ID/alias/

  4. Login as root, and set the file owner to the Certificate System user and group. 

    su

chown user:group ServerCert.p12

chown user:group caSigningCert.p12

  5. Log out of root. As the regular Certificate System user, set the permissions on the files. 

    chmod 00600 ServerCert.p12

chmod 00600 caSigningCert.p12

  6. Register the new HSM in the new token database. 

    modutil -nocertdb -dbdir . -add new_HSM_token_name -libfile 
new_HSM_library_path/new_HSM_library

  7. Identify the new HSM slot name. 

    modutil -dbdir . -nocertdb -list

  8. Import the public/private key pairs for each entry from the PKCS #12 files into the new HSM; -i imports the specified file, and -h sets the name for the new HSM. 

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

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

pk12util -i caSigningCert.p12 -d . -h new_HSM_slot_name

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

  9. Optionally, delete the PKCS #12 files from the alias/ directory. 

    rm ServerCert.p12

rm caSigningCert.p12

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

    certutil -M -n "new_HSM_slot_name:Server-Cert cert-old_CA_instance" 
-t "cu,cu,cu" -d . -h new_HSM_token_name

certutil -M -n "new_HSM_slot_name:caSigningCert cert-old_CA_instance" 
-t "CTu,CTu,CTu" -d . -h new_HSM_token_name

  11. Open the new CA instance CS.cfg file. 

    cd /var/lib/instance_ID/conf/

vi CS.cfg

  12. Edit the ca.signing.cacertnickname and ca.ocsp_signing.cacertnickname attributes in the CS.cfg file to reflect the new CA instance directory. 

    ca.signing.cacertnickname=
 new_HSM_slot_name:caSigningCert cert-old_CA_instance
ca.ocsp_signing.cacertnickname=
 new_HSM_slot_name:caSigningCert cert-old_CA_instance

  13. In the same directory, edit the serverCertNick.conf file to contain the old certificate nickname. For example: 

    vi serverCertNick.conf

new_HSM_slot_name:Server-Cert cert-old_CA_instance