Page 1 Red Hat Certificate System Migration Guide 7.2...
Page 4: Table Of Contents
Table of Contents 1. Introduction to the Certificate System Migration Utility ................1 1. History of Certificate System Releases ..................1 2. Migration Overview ......................... 3 3. Considerations before Migration ......................7 4. Step 1: Preparing the Older Server Instance for Migration ............... 8 5.
Page 5 Red Hat Certificate System Migration Guide 7.2 5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration ............94 5.2.1. Case I: Security Databases to Security Databases Migration ........94 5.2.2. Case II: Security Databases to HSM Migration ............95 5.2.3. Case III: HSM to Security Databases Migration ............98 5.2.4.
Page 6 Red Hat Certificate System Migration Guide 7.2 2. DRM Migration ........................214 2.1. Step 1: Preparing the Old Server ................... 215 2.2. Step 2: Creating a New Certificate System Installation ............215 2.3. Step 3: Stopping All New Certificate System Instances ............215 2.4.
Page 7: Introduction To The Certificate System Migration Utility
Chapter 1. Introduction to the Certificate System Migration Utility Previous installations of Red Hat Certificate System, Netscape Certificate Management System (CMS), or iPlanet Certific- ate Management System (iCMS, also known as Sun ONE Certificate Server) can be migrated to Red Hat Certificate System version 7.2 or later using the Red Hat Certificate System migration utility.
Page 8 1. History of Certificate System Releases Release Date Product Name Service Packs November 6, 2006 Red Hat Certificate System 7.2 Table 1.1. Summary of Certificate System Releases Every version of Certificate System has the ability to extract data from the installation of a previous version and migrate this data to the newer version.
Page 9: Migration Overview
Chapter 2. Migration Overview The migration process is staged to migrate the different subsets of Certificate System information separately. The general process is as follows: Install the new Certificate System instances. Migrate the old Certificate System security databases, which contains the key and certificate materials for the server, to the new Certificate System instances.
Page 10 The scripts to use for migration to Certificate System version 7.2 are in the TxtTo72 directory. The following table defines the migration export programs and corresponding import programs. An X indicates compatib- ility between the export and import programs. Migration Import Package Migration TxtTo60 TxtTo61...
Page 11 • Token Processing System (TPS) The following table defines the platforms and subsystems supported by different versions of Certificate System: Product (including service packs Subsystems Platforms and hot-fixes) Netscape Certificate Server 1.0 Digital UNIX 3.2C/4.0B, HP-UX 10.10, IBM AIX 4.1.4/4.2, IRIX 5.3/6.2, Solaris 2.4/2.5.1, Windows NT 3.51/4.0 [Intel], Windows NT 4.0 [Alpha]...
Page 12 this table because it is supported on different platforms. Chapter 2. Migration Overview...
Page 13: Considerations Before Migration
Chapter Considerations before Migration Before migrating any subsystem from any platform, consider the following: • Since all migrations are unique to a deployment, it is strongly recommended that the entire migration process be planned in advance. • Not all steps in the migration processes apply to every deployment. Follow only the steps which apply to the deploy- ment being migrated.
Page 14: Step 1: Preparing The Older Server Instance For Migration
Chapter 4. Step 1: Preparing the Older Server Instance for Migration Before migrating a Certificate System instance, back up the Certificate System instance. When the backup process is com- plete, then make sure that the old Certificate System, Directory Server, and Administration Server instances have been stopped.
Page 15 Chapter 4. Step 1: Preparing the Older...
Page 16: Step 2: Installing The New Certificate System
Chapter 5. Step 2: Installing the New Certificate System Install a new Certificate System 7.2 instance. All subsystem instances are installed separately; make sure that every subsystem type which will be migrated has a corresponding new subsystem instance. Obtain the appropriate packages. This can be done through the up2date command or through downloading the ISO image from the Red Hat Certificate System 7.2 Red Hat Network channel.
Page 17: Step 3: Stopping The New Certificate System Servers
Chapter 6. Step 3: Stopping the New Certificate System Servers Before beginning migration, stop all new Certificate System instances. /etc/init.d/instance_ID stop Stop the Directory Server. cd /opt/redhat-ds/slapd-DS-instance ./stop-slapd Chapter 6. Step 3: Stopping the New...
Page 18: Step 4: Migrating Security Databases
Chapter 7. Step 4: Migrating Security Databases 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. •...
Page 19: Case Ii: Security Databases To Hsm Migration
1.2. Case II: Security Databases to HSM Migration Log in as root, and set the file user and group to the Certificate System user and group. chown user:group cert7.db chown user:group key3.db 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 Use the certutil tool to list all of the old Certificate System certificates.
Page 20 1.2. Case II: Security Databases to HSM Migration rm /var/lib/instance_ID/alias/key3.db 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 As the Certificate System user account, open the new Certificate System's alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the user and group as whom the Certificate System runs.
Page 21 1.2. Case II: Security Databases to HSM Migration NOTE The old security databases may contain additional public/private key pairs; these can also be extracted using pk12util. Remove the security databases from the alias/ directory. rm cert7.db rm cert8.db rm key3.db Register the new HSM in the new token database.
Page 22: Case Iii: Hsm To Security Databases Migration
1.3. Case III: HSM to Security Databases Migration cd /var/lib/instance_ID/conf/ vi CS.cfg 16. Modify the value for the ca.signing.cacertnickname and ca.ocsp_signing.cacertnickname at- tributes 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 1.3.
Page 23: Case Iv: Hsm To Hsm Migration
1.4. Case IV: HSM to HSM Migra- tion 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 Optionally, delete the PKCS #12 files from the alias/ directory.
Page 24 1.4. Case IV: HSM to HSM Migra- tion /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 Log into the new server machine as the Certificate System user, and open the new Certificate System alias/ direct- ory. cd /var/lib/instance_ID/alias/ Login as root, and set the file owner to the Certificate System user and group. chown user:group ServerCert.p12 chown user:group caSigningCert.p12 Log out of root.
Page 25: Certificate Management System 4.2
2. Certificate Management System 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=...
Page 26 2.1. 4.2 Certificate Authority (CA) Migration 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 Log into the new server machine as the Certificate System user account. Open the new Certificate System's alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file owner to the Certificate System user and group. chown user:group cert7.db chown user:group key3.db Log out as root.
Page 27: Case Ii: Security Databases To Hsm Migration
2.1. 4.2 Certificate Authority (CA) Migration ca.connector.KRA.nickname=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 2.1.2. Case II: Security Databases to HSM Migration 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 Copy the certificate and key security databases from the old server to the new server.
Page 28 2.1. 4.2 Certificate Authority (CA) Migration the name of the file to which to export them. 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"...
Page 29: Case Iii: Hsm To Security Databases Migration
2.1. 4.2 Certificate Authority (CA) Migration rm caSigningCert.p12 14. 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"...
Page 30 2.1. 4.2 Certificate Authority (CA) Migration Log in as root, and set the file user and group to the Certificate System user and group. chown user:group ServerCert.p12 chown user:group caSigningCert.p12 Log out as root. As the Certificate System user, set the file permissions on the key pair files. chmod 00600 ServerCert.p12 chmod 00600 caSigningCert.p12 Import the public/private key pairs in the PKCS #12 files into the new server's security databases.
Page 31: Case Iv: Hsm To Hsm Migration
2.1. 4.2 Certificate Authority (CA) Migration 12. 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 2.1.4. Case IV: HSM to HSM Migration 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.
Page 32: Data Recovery Manager (Drm) Migration
2.2. 4.2 Data Recovery Manager (DRM) Migration 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 Optionally, delete the PKCS #12 files. rm ServerCert.p12 rm caSigningCert.p12 10.
Page 33 2.2. 4.2 Data Recovery Manager (DRM) Migration 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 Copy the certificate and key security databases from the old server to the new server. cp old_server_root/cert-old_DRM_instance/config/cert-old_DRM_instance-cert7.db /var/lib/instance_ID/alias/cert7.db cp old_server_root/cert-old_DRM_instance/config/cert-old_DRM_instance-key3.db...
Page 34: Case Ii: Security Databases To Hsm Migration
2.2. 4.2 Data Recovery Manager (DRM) Migration DRM instance. kra.storageUnit.nickname= kraStorageCert cert-old_DRM_instance kra.transportUnit.nickname= kraTransportCert cert-old_DRM_instance NOTE The caSigningCert is not referenced in the CS.cfg for the DRM 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_DRM_instance 2.2.2.
Page 35 2.2. 4.2 Data Recovery Manager (DRM) Migration kraTransportCert cert-old_DRM_instance u,u,u NOTE The certificate database is automatically converted from cert7.db to cert8.db. Export the public/private key pairs of each entry in the Certificate Management 4.2 databases; -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_DRM_instance"...
Page 36 2.2. 4.2 Data Recovery Manager (DRM) Migration 13. Import the public/private key pairs from the PKCS #12 files into 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 kraStorageCert.p12 -d .
Page 37: Case Iii: Hsm To Security Databases Migration
2.2. 4.2 Data Recovery Manager (DRM) Migration NOTE The caSigningCert attribute is not listed in the CS.cfg file. 20. 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_DRM_instance 2.2.3. Case III: HSM to Security Databases Migration Extract the public/private key pairs from the HSM.
Page 38 2.2. 4.2 Data Recovery Manager (DRM) Migration cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group. chown user:group ServerCert.p12 chown user:group kraStorageCert.p12 chown user:group kraTransportCert.p12 chown user:group caSigningCert.b64 Log out as root. As the Certificate System user, set the file permissions on the certificate files. chmod 00600 ServerCert.p12 chmod 00600 kraStorageCert.p12 chmod 00600 kraTransportCert.p12...
Page 39: Case Iv: Hsm To Hsm Migration
2.2. 4.2 Data Recovery Manager (DRM) Migration certutil -A -n "caSigningCert cert-old_DRM_instance" -t "CT,c," -d . -i caSigningCert.b64 11. Optionally, delete the base-64 file. rm caSigningCert.b64 12. Open the CS.cfg configuration file. cd /var/lib/instance_ID/conf/ 13. Modify the kra.storageUnit.nickname and kra.transportUnit.nickname attributes to reflect the new DRM instance.
Page 40 2.2. 4.2 Data Recovery Manager (DRM) Migration Use the certutil tool from the old Certificate System installation to identify the old HSM slot name. old_server_root/bin/cert/tools/certutil -U -d . Extract the public key using the certutil tool, and save the output to a base 64 file. In this example, -L lists the named certificate, -n names the old certificate, -h gives the old HSM name, and -a saves it to the base 64 file.
Page 41 2.2. 4.2 Data Recovery Manager (DRM) Migration pk12util -i kraStorageCert.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 kraTransportCert.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 10.
Page 42: Netscape Certificate Management System 4.2 (Sp 2) And 4.5 And Iplanet Certificate Management System 4.7
3. Netscape Certificate Manage- ment System 4.2 (SP 2) and 4.5 new_HSM_slot_name:Server-Cert cert-old_DRM_instance 3. Netscape Certificate Management System 4.2 (SP 2) and 4.5 and iPlanet Certificate Management System 4.7 There are three subsystems that can be migrated from Netscape Certificate Management System 4.2 (SP2) and 4.5 and iPlanet Certificate Management System 4.7 to a later version of the Certificate System: the Certificate Authority (CA), Data Recovery Manager (DRM), and Online Certificate Status Protocol (OCSP).
Page 43: Case Ii: Security Databases To Hsm Migration
3.1. 4.2SP2, 4.5, and 4.7 Certificate Authority (CA) Migration chown user:group key3.db Log out as root. As the Certificate System user, set the file permissions on the certificate and key databases. chmod 00600 cert7.db chmod 00600 key3.db Use the certutil tool to list all of the old certificates. In this example, -L lists the certificates, and -X forces them to be read/write.
Page 44 and iPlanet Certificate Manage- ment System 4.7 rm /var/lib/instance_ID/alias/key3.db 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 Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group.
Page 45 3.1. 4.2SP2, 4.5, and 4.7 Certificate Authority (CA) Migration 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. Delete the old security databases.
Page 46: Case Iii: Hsm To Security Databases Migration
3.1. 4.2SP2, 4.5, and 4.7 Certificate Authority (CA) Migration 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 certutil -M -n "new_HSM_slot_name:ocspSigningCert cert-old_CA_instance" -t "CTu,Cu,Cu" -d . -h new_HSM_token_name 15.
Page 47 3.1. 4.2SP2, 4.5, and 4.7 Certificate Authority (CA) Migration chown user:group ServerCert.p12 chown user:group caSigningCert.p12 chown user:group ocspSigningCert.p12 Log out as root. As the Certificate System user, set the file permissions on the PKCS #12 files. 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 security databases.
Page 48: Case Iv: Hsm To Hsm Migration
3.1. 4.2SP2, 4.5, and 4.7 Certificate Authority (CA) Migration ca.signing.cacertnickname= caSigningCert cert-old_CA_instance ca.ocsp_signing.cacertnickname= ocspSigningCert cert-old_CA_instance 11. If there is CA-DRM connectivity, then also edit the ca.connector.KRA.nickname attribute. ca.connector.KRA.nickname=caSigningCert cert-old_CA_instance 12. 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 3.1.4.
Page 49 3.1. 4.2SP2, 4.5, and 4.7 Certificate Authority (CA) Migration modutil -nocertdb -dbdir . -add new_HSM_token_name -libfile new_HSM_library_path/new_HSM_library Identify the new HSM slot name. modutil -dbdir . -nocertdb -list Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM. pk12util -i ServerCert.p12 -d .
Page 50: Sp2, 4.5, And 4.7 Data Recovery Manager (Drm) Migration
3.2. 4.2SP2, 4.5, and 4.7 Data Re- covery Manager (DRM) Migration ca.connector.KRA.nickname=new_HSM_slot_name:caSigningCert cert-old_CA_instance 14. 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 3.2. 4.2SP2, 4.5, and 4.7 Data Recovery Manager (DRM) Mi- gration Determine if the Certificate System Data Recover Manager (DRM) being migrated uses security databases, HSM, or both.
Page 51: Case Ii: Security Databases To Hsm Migration
3.2. 4.2SP2, 4.5, and 4.7 Data Re- covery Manager (DRM) Migration 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_DRM_instance cu,cu,cu caSigningCert cert-old_DRM_instance CT,c, kraStorageCert cert-old_DRM_instance u,u,u...
Page 52 3.2. 4.2SP2, 4.5, and 4.7 Data Re- covery Manager (DRM) Migration Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group. chown user:group cert7.db chown user:group key3.db Log out as root.
Page 53 3.2. 4.2SP2, 4.5, and 4.7 Data Re- covery Manager (DRM) Migration certutil -L -n "caSigningCert cert-old_DRM_instance" -d . -a > caSigningCert.b64 NOTE The old security databases may contain additional public keys; these can also be extracted using certutil. Delete the old security databases. rm cert7.db rm cert8.db rm key3.db...
Page 54: Case Iii: Hsm To Security Databases Migration
3.2. 4.2SP2, 4.5, and 4.7 Data Re- covery Manager (DRM) Migration -t "cu,cu,cu" -d . -h new_HSM_token_name certutil -M -n "new_HSM_slot_name:kraStorageCert cert-old_DRM_instance" -t "u,u,u" -d . -h new_HSM_token_name certutil -M -n "new_HSM_slot_name:kraTransportCert cert-old_DRM_instance" -t "u,u,u" -d . -h new_HSM_token_name 16. Import the public key from the base-64 file into the new HSM, and set the trust bits. certutil -A -n "new_HSM_slot_name:caSigningCert cert-old_DRM_instance"...
Page 55 3.2. 4.2SP2, 4.5, and 4.7 Data Re- covery Manager (DRM) Migration /var/lib/instance_ID/alias/kraTransportCert.p12 Extract the public key of the old_HSM_slot_name:caSigningCert cert-old_DRM_instance from the old se- curity databases and save the base-64 encoded output to a file called caSigningCert.b64. Open the old Certificate System configuration directory. cd old_server_root/cert-old_DRM_instance/config Use the old Certificate System's certutil tool to identify the old HSM slot name.
Page 56 3.2. 4.2SP2, 4.5, and 4.7 Data Re- covery Manager (DRM) Migration pk12util -i kraStorageCert.p12 -d . Enter Password or Pin for "NSS Certificate DB":******** Enter password for PKCS12 file: ******** pk12util: PKCS12 IMPORT SUCCESSFUL pk12util -i kraTransportCert.p12 -d . Enter Password or Pin for "NSS Certificate DB":******** Enter password for PKCS12 file: ******** pk12util: PKCS12 IMPORT SUCCESSFUL Optionally, delete the PKCS #12 files.
Page 57: Case Iv: Hsm To Hsm Migration
3.2. 4.2SP2, 4.5, and 4.7 Data Re- covery Manager (DRM) Migration vi serverCertNick.conf Server-Cert cert-old_DRM_instance 3.2.4. Case IV: HSM to HSM Migration 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.
Page 58 3.2. 4.2SP2, 4.5, and 4.7 Data Re- covery Manager (DRM) Migration chown user:group kraStorageCert.p12 chown user:group kraTransportCert.p12 chown user:group caSigningCert.b64 Log out as root. As the Certificate System user, set the file permissions. chmod 00600 ServerCert.p12 chmod 00600 kraStorageCert.p12 chmod 00600 kraTransportCert.p12 chmod 00600 caSigningCert.b64 Register the new HSM in the new token database.
Page 59: Sp2, 4.5, And 4.7 Online Certificate Status Protocol (Ocsp) Migration
3.3. 4.2SP2, 4.5, and 4.7 Online Certificate Status Protocol (OCSP) -t "u,u,u" -d . -h new_HSM_token_name 12. Import the public key from the base-64 file into the new HSM, and set the trust bits. certutil -A -n "new_HSM_slot_name:caSigningCert cert-old_DRM_instance" -t "CT,c," -d . -h new_HSM_token_name -i caSigningCert.b64 13.
Page 60 3.3. 4.2SP2, 4.5, and 4.7 Online Certificate Status Protocol (OCSP) Copy the certificate and key security databases from the old server to the new server. cp old_server_root/cert-old_OCSP_instance/config/cert-old_OCSP_instance-cert7.db /var/lib/instance_ID/alias/cert7.db cp old_server_root/cert-old_OCSP_instance/config/cert-old_OCSP_instance-key3.db /var/lib/instance_ID/alias/key3.db Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group.
Page 61: Case Ii: Security Databases To Hsm Migration
Migration 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_OCSP_instance 3.3.2. Case II: Security Databases to HSM Migration 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 Copy the certificate and key security databases from the old server to the new server.
Page 62 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-old_OCSP_instance" -d . Enter Password or Pin for "NSS Certificate DB":******** Enter password for PKCS12 file: ******** Re-enter password: ******** pk12util: PKCS12 EXPORT SUCCESSFUL NOTE...
Page 63: Case Iii: Hsm To Security Databases Migration
3.3. 4.2SP2, 4.5, and 4.7 Online Certificate Status Protocol (OCSP) pk12util: PKCS12 IMPORT SUCCESSFUL 14. Optionally, delete the PKCS #12 files. rm ServerCert.p12 rm ocspSigningCert.p12 15. 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_OCSP_instance"...
Page 64 3.3. 4.2SP2, 4.5, and 4.7 Online Certificate Status Protocol (OCSP) cp old_server_root/cert-old_OCSP_instance/config/ServerCert.p12 /var/lib/instance_ID/alias/ServerCert.p12 cp old_server_root/cert-old_OCSP_instance/config/ocspSigningCert.p12 /var/lib/instance_ID/alias/ocspSigningCert.p12 Extract the public key of the old_HSM_slot_name:caSigningCert cert-old_OCSP_instance from the old se- curity databases and save the base-64 encoded output to a file called caSigningCert.b64. Open the old Certificate System's configuration directory.
Page 65: Case Iv: Hsm To Hsm Migration
Migration pk12util: PKCS12 IMPORT SUCCESSFUL pk12util -i ocspSigningCert.p12 -d . Enter Password or Pin for "NSS Certificate DB":******** 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 security databases. certutil -M -n "Server-Cert cert-old_OCSP_instance"...
Page 66 cause of requirements in the FIPS 140-1 standard which protect the private key portion of an entry. To extract this in- formation, contact the HSM vendor for more information. The extracted keys should not have any dependencies, such as nickname prefixes, on the HSM. Copy the extracted public/private key pairs from the old server to the new server.
Page 67 3.3. 4.2SP2, 4.5, and 4.7 Online Certificate Status Protocol (OCSP) modutil -nocertdb -dbdir . -add new_HSM_token_name -libfile new_HSM_library_path/new_HSM_library Identify the new HSM slot name. modutil -dbdir . -nocertdb -list Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM. pk12util -i ServerCert.p12 -d .
Page 68: Certificate Management System 6.0
4. Certificate Management System The caSigningCert is not referenced in the CS.cfg file. 16. 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_OCSP_instance 4. Certificate Management System 6.0 There are three subsystems that can be migrated from Netscape Certificate Management System 6.0 to a later version of the Certificate System: the Certificate Authority (CA), Data Recovery Manager (DRM), and Online Certificate Status Pro- tocol (OCSP).
Page 69: Case Ii: Security Databases To Hsm Migration
Migration chown user:group key3.db Log out as root. As the Certificate System user, set the file permissions on the security databases. chmod 00600 cert7.db chmod 00600 key3.db 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.
Page 70 4.1. 6.0 Certificate Authority (CA) Migration Copy the certificate and key security databases from the old server to the new server. cp old_server_root/alias/cert-old_CA_instance-cert7.db /var/lib/instance_ID/alias/cert7.db cp old_server_root/alias/cert-old_CA_instance-key3.db /var/lib/instance_ID/alias/key3.db Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group.
Page 71 4.1. 6.0 Certificate Authority (CA) Migration NOTE The old security databases may contain additional public/private key pairs; these can also be extracted using pk12util. Delete the old security databases. rm cert7.db rm cert8.db rm key3.db Register the new HSM in the new token database. modutil -nocertdb -dbdir .
Page 72: Case Iii: Hsm To Security Databases Migration
4.1. 6.0 Certificate Authority (CA) Migration -t "CTu,CTu,CTu" -d . -h new_HSM_token_name certutil -M -n "new_HSM_slot_name:ocspSigningCert cert-old_CA_instance" -t "CTu,Cu,Cu" -d . -h new_HSM_token_name 15. Open the CS.cfg configuration file. cd /var/lib/instance_ID/conf/ vi CS.cfg 16. Edit the ca.signing.cacertnickname and ca.ocsp_signing.cacertnickname attributes to reflect the new CA information.
Page 73 4.1. 6.0 Certificate Authority (CA) Migration chown user:group caSigningCert.p12 chown user:group ocspSigningCert.p12 Log out as root. As the Certificate System user, set the file permissions on the PKCS #12 files. 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 security databases. pk12util -i ServerCert.p12 -d .
Page 74: Case Iv: Hsm To Hsm Migration
4.1. 6.0 Certificate Authority (CA) Migration ocspSigningCert cert-old_CA_instance 11. If there is CA-DRM connectivity, then also modify the ca.connector.KRA.nickname attribute. ca.connector.KRA.nickname=caSigningCert cert-old_CA_instance 12. 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 4.1.4.
Page 75 4.1. 6.0 Certificate Authority (CA) Migration Identify the new HSM slot name. modutil -dbdir . -nocertdb -list Import the public/private key pairs of each entry from the PKCS #12 files into 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...
Page 76: Data Recovery Manager (Drm) Migration
4.2. 6.0 Data Recovery Manager (DRM) Migration 14. 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 4.2. 6.0 Data Recovery Manager (DRM) Migration Determine if the migration to be performed involves software security databases, an HSM, or both. There are four possible migration scenarios;...
Page 77: Case Ii: Security Databases To Hsm Migration
4.2. 6.0 Data Recovery Manager (DRM) Migration caSigningCert cert-old_DRM_instance CT,c, kraStorageCert cert-old_DRM_instance u,u,u kraTransportCert cert-old_DRM_instance u,u,u NOTE The certificate database is automatically converted from cert7.db to cert8.db. Remove the cert7.db database from the alias/ directory. rm cert7.db Open the CS.cfg configuration file. cd /var/lib/instance_ID/conf/ vi CS.cfg Edit the kra.storageUnit.nickname and kra.transportUnit.nickname attributes to reflect the new...
Page 78 4.2. 6.0 Data Recovery Manager (DRM) Migration chown user:group cert7.db chown user:group key3.db Log out as root. As the Certificate System user, set the file permissions. chmod 00600 cert7.db chmod 00600 key3.db 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.
Page 79 4.2. 6.0 Data Recovery Manager (DRM) Migration The old security databases may contain additional public keys; these can also be extracted using the certutil tool. Delete the old security databases. rm cert7.db rm cert8.db rm key3.db 10. Register the new HSM in the new token database. modutil -nocertdb -dbdir .
Page 80: Case Iii: Hsm To Security Databases Migration
4.2. 6.0 Data Recovery Manager (DRM) Migration -t "u,u,u" -d . -h new_HSM_token_name 16. Import the public key from the base-64 file into the new HSM, and set the trust bits. certutil -A -n new_HSM_slot_name:caSigningCert cert-old_DRM_instance" -t "CT,c," -d . -h new_HSM_token_name -i caSigningCert.b64 17.
Page 81 4.2. 6.0 Data Recovery Manager (DRM) Migration Open the old Certificate System's alias/ directory. cd old_server_root/alias Set the LD_LIBRARY_PATH environment variable to search the Certificate System libraries. LD_LIBRARY_PATH=old_server_root/bin/cert/lib export LD_LIBRARY_PATH Use the old Certificate System certutil tool to identify the old HSM slot name. old_server_root/bin/cert/tools/certutil -U -d .
Page 82 4.2. 6.0 Data Recovery Manager (DRM) Migration pk12util: PKCS12 IMPORT SUCCESSFUL pk12util -i kraStorageCert.p12 -d . Enter Password or Pin for "NSS Certificate DB":******** Enter password for PKCS12 file: ******** pk12util: PKCS12 IMPORT SUCCESSFUL pk12util -i kraTransportCert.p12 -d . Enter Password or Pin for "NSS Certificate DB":******** Enter password for PKCS12 file: ******** pk12util: PKCS12 IMPORT SUCCESSFUL Optionally, delete the PKCS #12 files.
Page 83: Case Iv: Hsm To Hsm Migration
4.2. 6.0 Data Recovery Manager (DRM) Migration vi serverCertNick.conf Server-Cert cert-old_DRM_instance 4.2.4. Case IV: HSM to HSM Migration 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 be- cause of requirements in the FIPS 140-1 standard which protect the private key portion of an entry.
Page 84 4.2. 6.0 Data Recovery Manager (DRM) Migration cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group. chown user:group ServerCert.p12 chown user:group kraStorageCert.p12 chown user:group kraTransportCert.p12 chown user:group caSigningCert.b64 Log out as root. As the Certificate System user, set the file permissions. chmod 00600 ServerCert.p12 chmod 00600 kraStorageCert.p12 chmod 00600 kraTransportCert.p12...
Page 85: Online Certificate Status Protocol Responder (Ocsp) Migration
4.3. 6.0 Online Certificate Status Protocol Responder (OCSP) Mi- 11. 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_DRM_instance" -t "cu,cu,cu" -d . -h new_HSM_token_name certutil -M -n "new_HSM_slot_name:kraStorageCert cert-old_DRM_instance" -t "u,u,u"...
Page 86 4.3. 6.0 Online Certificate Status Protocol Responder (OCSP) Mi- 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 Copy the certificate and key security databases from the old server to the new server. cp old_server_root/alias/cert-old_OCSP_instance-cert7.db /var/lib/instance_ID/alias/cert7.db cp old_server_root/alias/cert-old_OCSP_instance-key3.db...
Page 87: Case Ii: Security Databases To Hsm Migration
gration ocsp.signing.certnickname=ocspSigningCert cert-old_OCSP_instance NOTE The caSigningCert is not referenced in the CS.cfg file. 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_OCSP_instance 4.3.2. Case II: Security Databases to HSM Migration Remove all the security databases in the new Certificate System which will receive migrated data.
Page 88 NOTE The certificate database is automatically converted from cert7.db to cert8.db. 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, -n sets the name of the certificate and the old database prefix. pk12util -o ServerCert.p12 -n "Server-Cert cert-old_OCSP_instance"...
Page 89: Case Iii: Hsm To Security Databases Migration
4.3. 6.0 Online Certificate Status Protocol Responder (OCSP) Mi- 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 ocspSigningCert.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 14.
Page 90 4.3. 6.0 Online Certificate Status Protocol Responder (OCSP) Mi- 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 be- cause of requirements in the FIPS 140-1 standard which protect the private key portion of an entry.
Page 91 gration Log out as root. As the Certificate System user, set the file permissions. chmod 00600 ServerCert.p12 chmod 00600 ocspSigningCert.p12 chmod 00600 caSigningCert.b64 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 Identify the new HSM slot name.
Page 92: Certificate Management System 6.1 And 6.2
vi CS.cfg 15. Edit the ocsp.signing.certnickname attribute to reflect the new OCSP instance. ocsp.signing.certnickname=new_HSM_slot_name:ocspSigningCert cert-old_OCSP_instance NOTE The caSigningCert is not referenced in the CS.cfg file. 16. 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_OCSP_instance 5.
Page 93: Case Ii: Security Databases To Hsm Migration
5.1. 6.1 and 6.2 Certificate Author- ity (CA) Migration Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group. chown user:group cert8.db chown user:group key3.db Log out as root.
Page 94 5.1. 6.1 and 6.2 Certificate Author- ity (CA) Migration rm /var/lib/instance_ID/alias/cert8.db rm /var/lib/instance_ID/alias/key3.db Copy the certificate and key security databases from the old server to the new server. cp old_server_root/alias/cert-old_CA_instance-cert8.db /var/lib/instance_ID/alias/cert8.db cp old_server_root/alias/cert-old_CA_instance-key3.db /var/lib/instance_ID/alias/key3.db Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group.
Page 95 5.1. 6.1 and 6.2 Certificate Author- ity (CA) Migration NOTE The old security databases may contain additional public/private key pairs; these can also be extracted using pk12util. Delete the old security databases. rm cert8.db rm key3.db Register the new HSM in the new token database. modutil -nocertdb -dbdir .
Page 96: Case Iii: Hsm To Security Databases Migration
5.1. 6.1 and 6.2 Certificate Author- ity (CA) Migration -t "CTu,Cu,Cu" -d . -h new_HSM_token_name 15. Open the CS.cfg configuration file. cd /var/lib/instance_ID/conf/ vi CS.cfg 16. Edit the ca.signing.cacertnickaname and ca.ocsp_signing.cacertnickname attributes to reflect the new CA instance. ca.signing.cacertnickname= new_HSM_slot_name:caSigningCert cert-old_CA_instance ca.ocsp_signing.cacertnickname= new_HSM_slot_name:ocspSigningCert cert-old_CA_instance 17.
Page 97 5.1. 6.1 and 6.2 Certificate Author- ity (CA) Migration Log out as root. As the Certificate System user, set the file permissions. 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 security databases. pk12util -i ServerCert.p12 -d .
Page 98: Case Iv: Hsm To Hsm Migration
5.1. 6.1 and 6.2 Certificate Author- ity (CA) Migration 11. If there is CA-DRM connectivity, then also modify the ca.connector.KRA.nickname attribute. ca.connector.KRA.nickname=caSigningCert cert-old_CA_instance 12. 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 5.1.4.
Page 99 5.1. 6.1 and 6.2 Certificate Author- ity (CA) Migration modutil -dbdir . -nocertdb -list Import the public/private key pairs of each entry from the PKCS #12 files into 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 .
Page 100: And 6.2 Data Recovery Manager (Drm) Migration
5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration 14. 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 5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration Determine if the migration to be performed involves software security databases, an HSM, or both. There are four possible migration scenarios;...
Page 101: Case Ii: Security Databases To Hsm Migration
5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration List the certificates in the old security databases by using the certutil tool. In this example, -L lists the certific- ates. certutil -L -d . Server-Cert cert-old_DRM_instance cu,cu,cu caSigningCert cert-old_DRM_instance CT,c, kraStorageCert cert-old_DRM_instance u,u,u kraTransportCert cert-old_DRM_instance u,u,u Open the CS.cfg configuration file.
Page 102 5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration chown user:group cert8.db chown user:group key3.db Log out as root. As the Certificate System user, set the file permissions. 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.
Page 103: Import The Public/Private Key Pairs Of Each Entry From The Pkcs #12 Files Into The New Hsm
5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration rm cert8.db rm key3.db 10. 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 11. Identify the new HSM slot name. modutil -dbdir . -nocertdb -list 12.
Page 104: Case Iii: Hsm To Security Databases Migration
5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration certutil -A -n "new_HSM_slot_name:caSigningCert cert-old_DRM_instance" -t "CT,c," -d . -h new_HSM_token_name -i caSigningCert.b64 17. Optionally, delete the base-64 file. rm caSigningCert.b64 18. Open the CS.cfg configuration file. cd /var/lib/instance_ID/conf/ vi CS.cfg 19.
Page 105 5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration Set the LD_LIBRARY_PATH environment variable to search the Certificate System libraries. LD_LIBRARY_PATH=old_server_root/bin/cert/lib export LD_LIBRARY_PATH Use the old Certificate System certutil tool to identify the old HSM slot name. old_server_root/bin/cert/tools/certutil -U -d . Use the old Certificate System certutil tool to extract the public key from the security databases and save the base-64 output to a file.
Page 106 5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration Enter password for PKCS12 file: ******** pk12util: PKCS12 IMPORT SUCCESSFUL pk12util -i kraTransportCert.p12 -d . Enter Password or Pin for "NSS Certificate DB":******** Enter password for PKCS12 file: ******** pk12util: PKCS12 IMPORT SUCCESSFUL Optionally, delete the PKCS #12 files.
Page 107: Case Iv: Hsm To Hsm Migration
5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration 5.2.4. Case IV: HSM to HSM Migration 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 be- cause of requirements in the FIPS 140-1 standard which protect the private key portion of an entry.
Page 108 5.2. 6.1 and 6.2 Data Recovery Manager (DRM) Migration chown user:group ServerCert.p12 chown user:group kraStorageCert.p12 chown user:group kraTransportCert.p12 chown user:group caSigningCert.b64 Log out as root. As the Certificate System user, set the file permissions. chmod 00600 ServerCert.p12 chmod 00600 kraStorageCert.p12 chmod 00600 kraTransportCert.p12 chmod 00600 caSigningCert.b64 Register the new HSM in the new token database.
Page 109: And 6.2 Online Certificate Status Protocol Manager (Ocsp) Migration
5.3. 6.1 and 6.2 Online Certificate Status Protocol Manager (OCSP) certutil -M -n "new_HSM_slot_name:kraStorageCert cert-old_DRM_instance" -t "u,u,u" -d . -h new_HSM_token_name certutil -M -n "new_HSM_slot_name:kraTransportCert cert-old_DRM_instance" -t "u,u,u" -d . -h new_HSM_token_name 12. Import the public key from the base-64 file into the new HSM, and set the trust bits. certutil -A -n "new_HSM_slot_name:caSigningCert cert-old_DRM_instance"...
Page 110 5.3. 6.1 and 6.2 Online Certificate Status Protocol Manager (OCSP) rm /var/lib/instance_ID/alias/cert8.db rm /var/lib/instance_ID/alias/key3.db Copy the certificate and key security databases from the old server to the new server. cp old_server_root/alias/cert-old_OCSP_instance-cert8.db /var/lib/instance_ID/alias/cert8.db cp old_server_root/alias/cert-old_OCSP_instance-key3.db /var/lib/instance_ID/alias/key3.db Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group.
Page 111: Case Ii: Security Databases To Hsm Migration
Migration vi serverCertNick.conf Server-Cert cert-old_OCSP_instance 5.3.2. Case II: Security Databases to HSM Migration 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 Copy the certificate and key security databases from the old server to the new server. cp old_server_root/alias/cert-old_OCSP_instance-cert8.db /var/lib/instance_ID/alias/cert8.db cp old_server_root/alias/cert-old_OCSP_instance-key3.db...
Page 112: Pk12Util -I Ocspsigningcert.p12 -D . -H New_Hsm_Slot_Name
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. Export the public key using the certutil tool; -L lists the named certificate, -n sets the name of the file and the old prefix, and -a outputs the information to a base-64 file.
Page 113: Case Iii: Hsm To Security Databases Migration
5.3. 6.1 and 6.2 Online Certificate Status Protocol Manager (OCSP) 15. 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_OCSP_instance" -t "cu,cu,cu" -d . -h new_HSM_token_name certutil -M -n "new_HSM_slot_name:ocspSigningCert cert-old_OCSP_instance" -t "cu,cu,cu"...
Page 114 5.3. 6.1 and 6.2 Online Certificate Status Protocol Manager (OCSP) curity databases and save the base-64 encoded output to a file called caSigningCert.b64. Open the old Certificate System alias/ directory. cd old_server_root/alias Set the LD_LIBRARY_PATH environment variable to search the Certificate System libraries. LD_LIBRARY_PATH=old_server_root/bin/cert/lib export LD_LIBRARY_PATH Use the old Certificate System certutil tool to identify the old HSM slot name.
Page 115: Case Iv: Hsm To Hsm Migration
Migration pk12util -i ocspSigningCert.p12 -d . Enter Password or Pin for "NSS Certificate DB":******** 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 security databases. certutil -M -n "Server-Cert cert-old_OCSP_instance"...
Page 116 as nickname prefixes, on the HSM. Copy the extracted key pairs from the old server to the new server. cp old_server_root/alias/ServerCert.p12 /var/lib/instance_ID/alias/ServerCert.p12 cp old_server_root/alias/ocspSigningCert.p12 /var/lib/instance_ID/alias/ocspSigningCert.p12 Extract the public key of the old_HSM_slot_name:caSigningCert cert-old_OCSP_instance from the old se- curity databases and save the base-64 encoded output to a file called caSigningCert.b64. Open the old Certificate System alias/ directory.
Page 117 5.3. 6.1 and 6.2 Online Certificate Status Protocol Manager (OCSP) chmod 00600 caSigningCert.b64 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 Identify the new HSM slot name. modutil -dbdir . -nocertdb -list Import the public/private key pairs of each entry from the PKCS #12 files into the new HSM.
Page 118: Certificate Management System 7.0 And Certificate System 7.1
6. Certificate Management System 7.0 and Certificate System 7.1 NOTE The caSigningCert is not referenced in the CS.cfg file. 16. 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_OCSP_instance 6.
Page 119: Case Ii: Security Databases To Hsm Migration
Migration cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group. chown user:group cert8.db chown user:group key3.db Log out as root. As the Certificate System user, set the file permissions. chmod 00600 cert8.db chmod 00600 key3.db List the contents of the certificate database using the certutil command.
Page 120 6.1. 7.0 and 7.1 Certificate Author- ity (CA) Migration Copy the certificate and key security databases from the old server to the new server. cp old_server_root/alias/cert-old_CA_instance-cert8.db /var/lib/instance_ID/alias/cert8.db cp old_server_root/alias/cert-old_CA_instance-key3.db /var/lib/instance_ID/alias/key3.db Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group.
Page 121: Rm Casigningcert.p12
6.1. 7.0 and 7.1 Certificate Author- ity (CA) Migration pk12util: PKCS12 EXPORT SUCCESSFUL NOTE The old security databases may contain additional public/private key pairs; these can also be extracted using pk12util. Delete the old security databases. rm cert8.db rm key3.db Register the new HSM in the new token database.
Page 122: Case Iii: Hsm To Security Databases Migration
6.1. 7.0 and 7.1 Certificate Author- ity (CA) Migration 14. 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"...
Page 123: Rm Ocspsigningcert.p12
6.1. 7.0 and 7.1 Certificate Author- ity (CA) Migration Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group. chown user:group ServerCert.p12 chown user:group caSigningCert.p12 chown user:group ocspSigningCert.p12...
Page 124: Case Iv: Hsm To Hsm Migration
6.1. 7.0 and 7.1 Certificate Author- ity (CA) Migration 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 . certutil -M -n "ocspSigningCert cert-old_CA_instance" -t "CTu,Cu,Cu" -d . certutil -M -n "subsystemCert cert-old_CA_instance" -t "cu,cu,cu"...
Page 125 6.1. 7.0 and 7.1 Certificate Author- ity (CA) Migration Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group. chown user:group ServerCert.p12 chown user:group caSigningCert.p12 chown user:group ocspSigningCert.p12...
Page 126: And 7.1 Data Recover Manager (Drm) Migration
6.2. 7.0 and 7.1 Data Recover Man- ager (DRM) Migration rm ServerCert.p12 rm caSigningCert.p12 rm ocspSigningCert.p12 rm subsystemCert.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"...
Page 127: Case I: Security Databases To Security Databases Migration
6.2. 7.0 and 7.1 Data Recover Man- ager (DRM) Migration 6.2.1. Case I: Security Databases to Security Databases Migration 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 Copy the certificate and key security databases from the old server to the new server. cp old_server_root/alias/cert-old_DRM_instance-cert8.db /var/lib/instance_ID/alias/cert8.db cp old_server_root/alias/cert-old_DRM_instance-key3.db...
Page 128: Case Ii: Security Databases To Hsm Migration
6.2. 7.0 and 7.1 Data Recover Man- ager (DRM) Migration 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 Server-Cert cert-old_DRM_instance 6.2.2.
Page 129 6.2. 7.0 and 7.1 Data Recover Man- ager (DRM) Migration pk12util -o ServerCert.p12 -n "Server-Cert cert-old_DRM_instance" -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-old_DRM_instance" -d . Enter Password or Pin for "NSS Certificate DB":******** Enter password for PKCS12 file: ******** Re-enter password: ********...
Page 130 6.2. 7.0 and 7.1 Data Recover Man- ager (DRM) Migration Enter Password or Pin for "new_HSM_slot_name":******** Enter password for PKCS12 file: ******** pk12util: PKCS12 IMPORT SUCCESSFUL pk12util -i kraStorageCert.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 kraTransportCert.p12 -d .
Page 131: Case Iii: Hsm To Security Databases Migration
6.2. 7.0 and 7.1 Data Recover Man- ager (DRM) Migration 20. 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_DRM_instance 6.2.3. Case III: HSM to Security Databases Migration 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.
Page 132 6.2. 7.0 and 7.1 Data Recover Man- ager (DRM) Migration Log in as root, and set the file user and group to the Certificate System user and group. chown user:group ServerCert.p12 chown user:group kraStorageCert.p12 chown user:group kraTransportCert.p12 chown user:group caSigningCert.b64 10.
Page 133: Case Iv: Hsm To Hsm Migration
6.2. 7.0 and 7.1 Data Recover Man- ager (DRM) Migration certutil -A -n "caSigningCert cert-old_DRM_instance" -t "CT,c," -d . -i caSigningCert.b64 15. Optionally, delete the base-64 file. rm caSigningCert.b64 16. Open the CS.cfg configuration file. cd /var/lib/instance_ID/conf 17. Edit the kra.storageUnit.nickname and kra.transportUnit.nickname attributes to reflect the new subsystem information.
Page 134 6.2. 7.0 and 7.1 Data Recover Man- ager (DRM) Migration LD_LIBRARY_PATH=old_server_root/bin/cert/lib export LD_LIBRARY_PATH Use the old Certificate System certutil tool to identify the old HSM slot name: old_server_root/bin/cert/tools/certutil -U -d . Use the old Certificate System certutil tool to extract the public key 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"...
Page 135 6.2. 7.0 and 7.1 Data Recover Man- ager (DRM) Migration 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 kraStorageCert.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 kraTransportCert.p12 -d .
Page 136: And 7.1 Online Certificate Status Protocol Manager (Ocsp) Migration
6.3. 7.0 and 7.1 Online Certificate Status Protocol Manager (OCSP) NOTE The caSigningCert is not referenced in the CS.cfg file. 20. 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_DRM_instance 6.3.
Page 137: Case Ii: Security Databases To Hsm Migration
6.3. 7.0 and 7.1 Online Certificate Status Protocol Manager (OCSP) List the certificates in the security databases using the certutil command. In this example, -L lists the certific- ates. certutil -L -d . Server-Cert cert-old_OCSP_instance cu,cu,cu caSigningCert cert-old_OCSP_instance CT,c, ocspSigningCert cert-old_OCSP_instance cu,cu,cu Open the CS.cfg configuration file.
Page 138 Migration Log out as root. As the Certificate System user, change the permissions on the files. 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.
Page 139 modutil -dbdir . -nocertdb -list 12. Create new security databases. certutil -N -d . 13. Import the public/private key pairs of each entry from the PKCS #12 files into 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 ocspSigningCert.p12 -d .
Page 140: Case Iii: Hsm To Security Databases Migration
6.3. 7.0 and 7.1 Online Certificate Status Protocol Manager (OCSP) The caSigningCert is not referenced in the CS.cfg file. 20. 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_OCSP_instance 6.3.3.
Page 141 6.3. 7.0 and 7.1 Online Certificate Status Protocol Manager (OCSP) cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group. chown user:group ServerCert.p12 chown user:group ocspSigningCert.p12 chown user:group caSigningCert.b64 Log out as root. As the Certificate System user, change the permissions on the files. chmod 00600 ServerCert.p12 chmod 00600 ocspSigningCert.p12 chmod 00600 caSigningCert.b64...
Page 142: Case Iv: Hsm To Hsm Migration
Migration cd /var/lib/instance_ID/conf/ vi CS.cfg 13. Edit the ocsp.signing.certnickname attribute to reflect the new subsystem information. ocsp.signing.certnickname=ocspSigningCert cert-old_OCSP_instance NOTE The caSigningCert is not referenced in the CS.cfg file. 14. In the same directory, edit the serverCertNick.conf file to contain the old certificate nickname. For example: vi serverCertNick.conf Server-Cert cert-old_OCSP_instance 6.3.4.
Page 143 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 Copy the key information from the old server to the new server. cp old_server_root/alias/caSigningCert.b64 /var/lib/instance_ID/alias/caSigningCert.b64 Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group.
Page 144: And 7.1 Token Key Service (Tks) Migration
6.4. 7.0 and 7.1 Token Key Service (TKS) Migration rm ocspSigningCert.p12 11. 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_OCSP_instance" -t "cu,cu,cu" -d . -h new_HSM_token_name certutil -M -n "new_HSM_slot_name:ocspSigningCert cert-old_OCSP_instance" -t "cu,cu,cu"...
Page 145 6.4. 7.0 and 7.1 Token Key Service (TKS) Migration rm /var/lib/instance_ID/alias/cert8.db rm /var/lib/instance_ID/alias/key3.db Log into the old server as the Certificate System user for that machine. To migrate a master key from the old TKS instance, do the following: Open the old Certificate System configuration file. If the migration is from CMS 7.0, open the CMS.cfg in the old Certificate System config directory.
Page 146: Case Ii: Security Databases To Hsm Migration
6.4. 7.0 and 7.1 Token Key Service (TKS) Migration Server-Cert cert-old_TKS_instance cu,cu,cu caSigningCert cert-old_TKS_instance CT,c, tksTransportCert cert-old_TKS_instance CT,C, Open the CS.cfg configuration file. cd /var/lib/instance_ID/conf/ vi CS.cfg 10. If server-side keygen has been enabled, edit the tks.drm_transport_cert_nickname attribute to reflect the new TKS instance.
Page 147 6.4. 7.0 and 7.1 Token Key Service (TKS) Migration this example, tks_master_key_version_ number, tks_master_key_v2 tks_master_key_version_name. To migrate symmetric keys from an old TKS instance, two things are necessary: • A written copy of the original three session key shares to reproduce the symmetric transport key on the old TKS instance.
Page 148 6.4. 7.0 and 7.1 Token Key Service (TKS) Migration 11. Export the public key using the certutil tool; -L lists the named 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-old_TKS_instance"...
Page 149: Case Iii: Hsm To Security Databases Migration
6.4. 7.0 and 7.1 Token Key Service (TKS) Migration rm caSigningCert.b64 rm tksTransportCert.b64 21. Import the original symmetric transport key into the new HSM. tksTool -I -d . new_HSM_token_name -n tks_transport_key_name 22. Type in the original three key session key shares (as prompted) to recreate the original transport key on the new HSM.
Page 150 6.4. 7.0 and 7.1 Token Key Service (TKS) Migration Log into the old server as the Certificate System user for that machine. To migrate a master key from the old TKS instance, do the following: Open the old Certificate System configuration file. If the migration is from CMS 7.0, this is the CMS.cfg file in the old Certificate System conf/ directory.
Page 151 6.4. 7.0 and 7.1 Token Key Service (TKS) Migration 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 Copy the key data from the old server to the new server. cp old_server_root/alias/caSigningCert.b64 /var/lib/instance_ID/alias/caSigningCert.b64 cp old_server_root/alias/tksTransportCert.b64 /var/lib/instance_ID/alias/tksTransportCert.b64 Log into the new server as the Certificate System user, and open the Certificate System alias/ directory. cd /var/lib/instance_ID/alias/ Log in as root, and set the file user and group to the Certificate System user and group.
Page 152: Case Iv: Hsm To Hsm Migration
6.4. 7.0 and 7.1 Token Key Service (TKS) Migration 14. Optionally, delete the base-64 files. rm caSigningCert.b64 rm tksTransportCert.b64 15. Import the original symmetric transport key into the new security databases. tksTool -I -d . -n tks_transport_key_name 16. Type in the original three key session keyshares (as prompted) to recreate the original transport key in the new secur- ity databases.
Page 153 6.4. 7.0 and 7.1 Token Key Service (TKS) Migration cause of requirements in the FIPS 140-1 standard which protect the private key portion of an entry. To extract this in- formation, contact the HSM vendor for more information. The extracted keys should not have any dependencies, such as nickname prefixes, on the HSM.
Page 154 6.4. 7.0 and 7.1 Token Key Service (TKS) Migration ity 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 Copy the key data from the old server to the new server.
Page 155 6.4. 7.0 and 7.1 Token Key Service (TKS) Migration rm ServerCert.p12 14. Set the trust bits on the public/private key pair that was imported into the new HSM. certutil -M -n "new_HSM_slot_name:Server-Cert cert-old_TKS_instance" -t "cu,cu,cu" -d . -h new_HSM_token_name 15. Import the public keys from the base-64 files, and set the trust bits. certutil -A -n "new_HSM_slot_name:caSigningCert cert-old_TKS_instance"...
Page 156 6.4. 7.0 and 7.1 Token Key Service (TKS) Migration NOTE The caSigningCert is not referenced in the CS.cfg file. 24. 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_TKS_instance Chapter 7.
Page 157: Step 5: Migrating Password Cache Data
This lists the information stored in the password cache. Write down both the tags and the passwords, such as the fol- lowing: internal=redhat The listed tags passwords are used to create the password.conf file. Log into the new server as the Certificate System user.
Page 158: Migrating 6.0, 6.1, 6.2, 7.0, And 7.1 Password Cache Data
= old_server_root/alias about to read password cache ----- Password Cache Content ----- internal : redhat Internal LDAP Database : passwordldap This lists the information stored in the password cache. Write down both the tags and the passwords, such as the fol-...
Page 159 3. Migrating 6.0, 6.1, 6.2, 7.0, and 7.1 Password Cache Data Log into the new server as the Certificate System user, and open the Certificate System config/ directory. cd /var/lib/instance_ID/conf/ Log in as root, and set the file user and group to the Certificate System user and group. chown user:group password.conf Log out as root.
Page 160: Step 6: Migrating Internal Databases
/opt/redhat-ds/slapd-DS-instance/db db2ldif -n server.example.com-rhpki-ca The location and name of the created LDIF file is given when the database to LDIF conversion is complete. ldif file: /opt/redhat-ds/slapd-DS-instance/ldif/dated_#_file.ldif Go to the location listed, and rename the LDIF file new.ldif. cd /opt/redhat-ds/slapd-DS-instance/ldif mv dated_#_file.ldif new.ldif...
Page 161 1. Migrating Internal Databases for Package the latest version of the Certificate System migration utility zip or tar. tar -cvf migrate.tar migrate NOTE Regardless of the packaging tool used, the corresponding tool must be present on the old server machine. If the platforms are identical and the zip utility is used, copy the unzip utility to the old_server_root/ bin/cert/ directory so that the zip and unzip versions match.
Page 162 Delete the first two entries in old.ldif which list the old domain name and the old LDAP port and domain name. 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 value for internaldb.basedn parameter in the CS.cfg file. For ex- ample: cn=aclResource,dc=server.example.com-rhpki-ca...
Page 163: Migrating Internal Databases For 4.2
INSTANCE=rhpki-ca • export INSTANCE Run the run.sh tool. The old.txt is directed to create old.ldif. run.sh /opt/redhat-ds/slapd-DS-instance/ldif/old.txt > /opt/redhat-ds/slapd-DS-instance/ldif/old.ldif 14. Import the old.ldif LDIF file into the new Certificate System instance internal database. Open the new Certificate System database directory.
Page 164 /opt/redhat-ds/slapd-DS-instance/db db2ldif -n server.example.com-rhpki-ca 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/dated_#_file.ldif Open the LDIF file directory, and rename the LDIF file new.ldif. cd /opt/redhat-ds/slapd-DS-instance/ldif mv dated_#_file.ldif new.ldif...
Page 165 Delete the first two entries in old.ldif, which give the old machine domain name and the LDAP port number and domain. 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 value of the internaldb.basedn parameter in the new.ldif file.
Page 166 /opt/redhat-ds/slapd-DS-instance/ldif 10. Log into the new server as the Certificate System user, and open the Certificate System ldif/ directory. cd /opt/redhat-ds/slapd-DS-instance/ldif 11. Log in as root, and set the file user and group to the Certificate System user and group.
Page 167: Migrating Internal Databases For 4.2 (Sp 2)
Log into the Directory Server for the new Certificate System instance, and export the new internal database content to LDIF. cd /opt/redhat-ds/slapd-DS-instance/db db2ldif -n server.example.com-rhpki-ca The location and name of the LDIF file is shown once the conversion from the database to LDIF is complete.
Page 168 2 to 4 Gb, such as vim, because the LDIF files may be larger than 2 Gb in some deployments. Delete the first two entries in old.ldif for the old machine domain name and the LDAP port and domain. Entry 1: dc=cert,dc=redhat,dc=com Databases...
Page 169 3. Migrating Internal Databases for 4.2 (SP 2) Entry 2: cn=ldap://:38900,dc=cert,dc=redhat,dc=com Replace the following entry with the value for internaldb.basedn parameter in the CS.cfg file. For ex- ample: cn=aclResources,dc=server.example.com-rhpki-ca Add new groups for the the security domains. cn=Security Domain Administrators,ou=groups,basedn...
Page 170: Migrating Internal Databases For 4.5
INSTANCE=rhpki-ca • export INSTANCE Run the run.sh tool. The old.txt is directed to create old.ldif. run.sh /opt/redhat-ds/slapd-DS-instance/ldif/old.txt > /opt/redhat-ds/slapd-DS-instance/ldif/old.ldif 14. Import the old.ldif LDIF file into the new Certificate System instance internal database. Open the new Certificate System database directory.
Page 171 4. Migrating Internal Databases for Open the given location, and rename the LDIF file new.ldif. cd /opt/redhat-ds/slapd-DS-instance/ldif mv dated_#_file.ldif new.ldif The migration utility is available as an independent RPM, which can be downloaded through the Certificate System Red Hat Network channel. The migration utilities are installed in the directory /usr/share/rhpki/migrate.
Page 172 2 to 4 Gb such as vim because the LDIF files may be larger than 2 Gb in some deployments. Delete the first two entries in old.ldif, for the old machine domain name and the LDAP port and domain. 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 value for internaldb.basedn parameter in the CS.cfg file.
Page 173 • export INSTANCE Run the run.sh tool. The old.txt file is directed to create old.ldif. run.sh /opt/redhat-ds/slapd-DS-instance/ldif/old.txt > /opt/redhat-ds/slapd-DS-instance/ldif/old.ldif 14. Import the old.ldif LDIF file into the new Certificate System instance internal database. Open the new Certificate System database directory.
Page 174: Migrating Internal Databases For 4.7
5. Migrating Internal Databases for ldif2db -n server.example.com-rhpki-ca -i /opt/redhat-ds/slapd-DS-instance/ldif/old.ldif Force the virtual list views (VLV) indexes to be re-indexed. db2index 5. Migrating Internal Databases for 4.7 Log into the Directory Server for the new Certificate System instance, and export the new internal database content to LDIF.
Page 175 5. Migrating Internal Databases for rm /usr/share/rhpki/migrate.tar Log into the old server as the Certificate System user for that machine, and open the Certificate System bin/ cert/ directory. cd old_server_root/bin/cert Log in as root, and set the file user and group to the Certificate System user and group. chown user:group migrate.tar Log out as root.
Page 176 /opt/redhat-ds/slapd-DS-instance/ldif 10. Log into the new server as the Certificate System user, and open the Certificate System ldif/ directory. cd /opt/redhat-ds/slapd-DS-instance/ldif 11. Log in as root, and set the file user and group to the Certificate System user and group.
Page 177: Migrating Internal Databases For 6.0
• export INSTANCE Run the run.sh command to use old.txt to create an LDIF. run.sh /opt/redhat-ds/slapd-DS-instance/ldif/old.txt > /opt/redhat-ds/slapd-DS-instance/ldif/old.ldif 14. Import the old.ldif LDIF file into this new Certificate System server instance's internal database. Open the new Certificate System database directory.
Page 178 6. Migrating Internal Databases for Open the given LDIF location, and rename the LDIF file new.ldif. cd /opt/redhat-ds/slapd-DS-instance/ldif mv dated_#_file.ldif new.ldif Copy the newest version of the migration utility from the new Certificate System instance to the old Certificate Sys- tem instance.
Page 179 6. Migrating Internal Databases for Run the db2ldif command to export the database contents to LDIF. cd old_server_root/slapd-old_instance-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: old_server_root/slapd-old_instance-db/ldif/dated_#_file.ldif Open the given LDIF location, and rename the LDIF file to old.ldif.
Page 180 • export INSTANCE Run the run.sh utility 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 14. Import the old.ldif LDIF file into this new Certificate System server instance's internal database. Open the new Certificate System database directory.
Page 181: Migrating Internal Databases For 6.01
Certificate System instance is in the internaldb.database parameter in the CS.cfg file. For example: cd /opt/redhat-ds/slapd-DS-instance/db db2ldif -n server.example.com-rhpki-ca The location and name of the LDIF file is shown once the conversion from the database to LDIF is complete.
Page 182 7. Migrating Internal Databases for 6.01 cp /usr/share/rhpki/migrate.tar old_server_root/bin/cert rm /usr/share/rhpki/migrate.tar Log into the old server as the Certificate System user for that machine, and open the Certificate System bin/ cert/ directory. cd old_server_root/bin/cert Log in as root, and set the file user and group to the Certificate System user and group. chown user:group migrate.tar Log out as root.
Page 183 7. Migrating Internal Databases for 6.01 mv dated_#_file.ldif old.ldif Adjust the LDIF content ofold.ldif. NOTE If using a text editor to perform the substitution instead of a script, use an editor that supports file sizes greater than 2 to 4 Gb such as vim because the LDIF files may be larger than 2 Gb in some deployments. Open the old Certificate System LDIF directory.
Page 184 • export INSTANCE Run the run.sh utility 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 13. Import the old.ldif LDIF file into this new Certificate System server instance's internal database. Open the new Certificate System database directory.
Page 185: Migrating Internal Databases For 6.1
LDIF. The internal database name for the Certificate System instance is in the internaldb.database parameter in the CS.cfg file. For example: cd /opt/redhat-ds/slapd-DS-instance/db db2ldif -n server.example.com-rhpki-ca The location and name of the LDIF file is shown once the conversion from the database to LDIF is complete.
Page 186 8. Migrating Internal Databases for Log into the old server as the Certificate System user for that machine, and open the Certificate System bin/ cert/ directory. cd old_server_root/bin/cert Log in as root, and set the file user and group to the Certificate System user and group. chown user:group migrate.tar Log out as root.
Page 187 Open the old Certificate System LDIF directory, and copy the old.txt file to the new Certificate System's internal database LDIF directory. cd old_server_root/slapd-old_instance-db/ldif cp old_server_root/slapd-old_instance-db/ldif/old.txt /opt/redhat-ds/slapd-DS-instance/ldif Log into the new server as the Certificate System user, and open the Certificate System ldif/ directory. cd /opt/redhat-ds/slapd-DS-instance/ldif Databases...
Page 188: Migrating Internal Databases For 6.2
• export INSTANCE Run the run.sh command to use the old.txt file 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 13. Import the old.ldif LDIF file into this new Certificate System server instance's internal database. Open the new Certificate System's database directory.
Page 189 LDIF. The internal database name for the Certificate System instance is in the internaldb.database parameter in the CS.cfg file. For example: cd /opt/redhat-ds/slapd-DS-instance/db db2ldif -n server.example.com-rhpki-ca The location and name of the LDIF file is shown once the conversion from the database to LDIF is complete.
Page 190 9. Migrating Internal Databases for chown user:group migrate.tar Log out as root. As the Certificate System user, change the permissions on the file. chmod 00600 migrate.tar Since the old Certificate System migration utility will not be used, remove the old Certificate System up- grade/ directory.
Page 191 /opt/redhat-ds/slapd-DS-instance/ldif Log into the new server as the Certificate System user, and open the Certificate System ldif/ directory. cd /opt/redhat-ds/slapd-DS-instance/ldif 10. Log in as root, and set the file user and group to the Certificate System user and group. Databases...
Page 192: Migrating Internal Databases For 7.0
INSTANCE=rhpki-ca • export INSTANCE 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 13. Import the old.ldif LDIF file into this new Certificate System server instance's internal database. Open the new Certificate System database directory.
Page 193 LDIF. The internal database name for the Certificate System instance is in the internaldb.database parameter in the CS.cfg file. For example: cd /opt/redhat-ds/slapd-DS-instance/db db2ldif -n server.example.com-rhpki-ca The location and name of the LDIF file is shown once the conversion from the database to LDIF is complete.
Page 194 10. Migrating Internal Databases for 7.0 Log out as root. As the Certificate System user, change the permissions on the file. chmod 00600 migrate.tar Since the old Certificate System migration utility will not be used, remove the upgrade/ directory. rm -rf old_server_root/bin/cert/upgrade Unpackage the latest version of the migration utility using unzip or tar.
Page 195 /opt/redhat-ds/slapd-DS-instance/ldif Log into the new server as the Certificate System user, and open the Certificate System ldif/ directory. cd /opt/redhat-ds/slapd-DS-instance/ldif 10. Log in as root, and set the file user and group to the Certificate System user and group. chown user:group old.txt 11.
Page 196: Migrating Internal Databases For 7.1
INSTANCE=rhpki-ca • export INSTANCE 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 13. Import the old.ldif LDIF file into this new Certificate System server instance's internal database. Open the new Certificate System database directory.
Page 197 /opt/redhat-ds/slapd-DS-instance/ldif/dated_#_file.ldif Open the given LDIF location, and rename the LDIF file new.ldif. cd /opt/redhat-ds/slapd-DS-instance/ldif mv dated_#_file.ldif new.ldif Copy the newest version of the migration utility to the old Certificate System. The migration utility is available as an independent RPM, which can be downloaded through the Certificate System Red Hat Network channel.
Page 198 11. Migrating Internal Databases for 7.1 Since the old Certificate System migration utility will not be used, remove the upgrade/ directory. rm -rf old_server_root/bin/cert/upgrade Unpackage the latest version of the migration utility using unzip or tar. tar -xvf migrate.tar Remove the migration utility package and any additional utilities, such as the unzip utility, that were copied to the old Certificate System server.
Page 199 /opt/redhat-ds/slapd-DS-instance/ldif Log into the new server as the Certificate System user, and open the Certificate System ldif/ directory. cd /opt/redhat-ds/slapd-DS-instance/ldif 10. Log in as root, and set the file user and group to the Certificate System user and group. chown user:group old.txt 11.
Page 200 INSTANCE=rhpki-ca • export INSTANCE 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 13. Import the old.ldif LDIF file into this new Certificate System server instance's internal database. Open the new Certificate System database directory.
Page 201: Step 7: Customizing User Data (Non-Console)
Chapter 10. Step 7: Customizing User Data (Non-Console) Copy all customized plug-ins, profiles, and forms to the new Certificate System, and apply any hand-edited changes to the new Certificate System CS.cfg file. For example, if the profile configuration in the old_CA_instance has been changed to enable S/MIME support, make the same changes to the new_CA_instance.
Page 202: Step 8: Starting All New Certificate System Instances
Chapter 11. Step 8: Starting All New Certificate System Instances Restart the Directory Server for the new instance. cd /opt/redhat-ds/slapd-DS-instance ./start-slapd Start all of the new Certificate System instances. /etc/init.d/instance_ID start Chapter 11. Step 8: Starting All New...
Page 203: Step 9: Renewing Certificate System Server Certificates
Chapter 12. Step 9: Renewing Certificate System Server Certificates If the new Certificate System server is on a different machine than the old Certificate System, the SSL server certificate as- sociated with each newly-migrated Certificate System server instance must be renewed. There are three procedures to generate new server certificates, depending on the subsystem: generating self-signed CA server certificates;...
Page 204: Renewing A Ca Ssl Server Certificate By Issuing An Ssl Server Certificate Request
2. Renewing a CA SSL Server Cer- tificate by Issuing an SSL Server The newly-migrated CA instance SSL server certificate is automatically renewed with the new server data. Close the Console. Restart the new Certificate System CA instance. /etc/init.d/rhpki-ca restart 2.
Page 205: Renewing A Drm, Ocsp, Or Tks Ssl Server Certificate
3. Renewing a DRM, OCSP, or TKS SSL Server Certificate Enter in any necessary information in the Location of Certificate panel. Go through the remaining panels in the Certificate Setup Wizard to install the updated SSL server certificate. 11. Close the Console. 12.
Page 206 Certificate Request /etc/init.d/rhpki-kra restart Certificate System Server Certificates...
Page 207: Step 10: Customizing User Data (Console)
Chapter 13. Step 10: Customizing User Data (Console) Use the Console to configure any custom behavior of the different subsystems, such as customized plug-ins, logging, and auditing. A subsystem may have to be restarted once all configuration changes have been applied. Chapter 13.
Page 208: Step 11: Verifying Migration
Chapter 14. Step 11: Verifying Migration After migrating all old Certificate System instances to the corresponding new Certificate System server instances, access the CA end-entities services page and the subsystem agent services pages of the new Certificate System server to ensure that everything is working properly.
Page 209: Detailed Example Of A Certificate System Migration
Chapter 15. Detailed Example of a Certificate System Migration This chapter contains a detailed example of a full Certificate System migration. OLD INSTALLATION NEW INSTALLATION Version Certificate Management System 6.1 Certificate System 7.2 (SP 4), including hot-fixes Platform Solaris 8 Red Hat Enterprise Linux 4 (AS) Subsystems CA, DRM, OCSP, RA...
Page 210: Ca Migration
1. CA Migration pha.example.com and are all migrated to Certificate System 7.2 instances located on a single machine called server.example.com. It is strongly recommended that real deployments separate the subsystems across multiple machines. Additionally, each subsystem uses a simple password; real deployments should use more robust, cryptographic- ally stronger passwords containing uppercase letters, lowercase letters, numbers, and other special characters.
Page 211: Step 2: Creating A New Certificate System Installation
-pki-subsystem=ca -pki_package_path=/media/cdrom/RedHat/RPMS -force Configure the CA 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...
Page 212: Step 4: Migrating Security Databases
1.4. Step 4: Migrating Security Databases cd /opt/redhat-ds/slapd-DS-instance ./stop-slapd 1.4. Step 4: Migrating Security Databases Do the following to migrate the Certificate Management System 6.1 CA subsystem security databases to the Certificate System 7.2 HSM: NOTE For more detailed information on migrating the 6.1 CA subsystem, refer to Section 5.1.2, “Case II: Security Data- bases to HSM Migration”.
Page 213 1.4. Step 4: Migrating Security Databases 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-ca" -d . Enter Password or Pin for "NSS Certificate DB":******** Enter password for PKCS12 file: ******** Re-enter password: ******** pk12util: PKCS12 EXPORT SUCCESSFUL...
Page 214: Step 5: Migrating Password Cache Data
1.5. Step 5: Migrating Password Cache Data Enter Password or Pin for "rho":******** Enter password for PKCS12 file: ******** pk12util: PKCS12 IMPORT SUCCESSFUL 13. Optionally, delete the PKCS #12 files. rm ServerCert.p12 rm caSigningCert.p12 rm ocspSigningCert.p12 14. Set the trust bits on the public/private key pairs that were imported into the new HSM. certutil -M -n "rho:Server-Cert cert-ca"...
Page 215: Step 6: Migrating Internal Databases
Log into the new CA server hosting server.example.com as the Certificate System user, and export the new in- ternal database content to LDIF using the db2ldif tool. cd /opt/redhat-ds/slapd-DS-instance/db/server.example.com-rhpki-ca-db db2ldif -n server.example.com-rhpki-ca The LDIF file location is given when the export from the database is finished.
Page 216 1.6. Step 6: Migrating Internal Databases ldif file: /opt/redhat-ds/slapd-DS-instance/ldif/2005_06_07_874021.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_874021.ldif new.ldif Copy the latest version of the migration utility from the new Certificate System to the old server.
Page 217 1.6. Step 6: Migrating Internal Databases Unpackage the latest version of the migration utility using unzip or tar. tar -xvf migrate.tar Remove the migration utility package and any additional utilities, such as the unzip utility, that were copied to the old Certificate System server. rm migrate.tar Run the db2ldif command to export the database contents to LDIF.
Page 218 Log into the new CA server hosting server.example.com as the Certificate System user, and open the Certific- ate System ldif/ directory. cd /opt/redhat-ds/slapd-DS-instance/ldif 10. Log in as root, and set the file user and group to the Certificate System user and group.
Page 219: Step 7: Customizing User Data (Non-Console)
Data (Non-Console) • export INSTANCE 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 13. Import the old.ldif LDIF file into this new CA server instance's internal database. Open the 7.2 CA database directory. cd /opt/redhat-ds/slapd-DS-instance/db Import the 6.1 LDIF file into the 7.2 database.
Page 220: Step 10: Customizing User Data (Console)
1.10. Step 10: Customizing User Data (Console) Select the 7.2 CA instance with the migrated data, and open 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.
Page 221: Step 1: Preparing The Old Server
-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...
Page 222 2.4. Step 4: Migrating Security Databases databases: NOTE For more information on migrating security databases to HSM, see Section 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.
Page 223 2.4. Step 4: Migrating Security Databases 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"...
Page 224 2.5. Step 5: Migrating Password Cache Data 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 14.
Page 225: Step 5: Migrating Password Cache Data
2.6. Step 6: Migrating Internal Databases 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 fol- lowing: NOTE For more information on migrating the password cache from 6.1 to 7.2, see Section 3, “Migrating 6.0, 6.1, 6.2, 7.0, and 7.1 Password Cache Data”.
Page 226 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.
Page 227 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.
Page 228: Step 7: Customizing User Data (Non-Console)
INSTANCE=rhpki-kra • export INSTANCE 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 12. Import the old.ldif LDIF file into this new DRM server instance's internal database. Open the 7.2 DRM database directory. cd /opt/redhat-ds/slapd-DS-instance/db/ Run the ldif2db tool to import the LDIF into the DRM database.
Page 229: Step 10: Customizing User Data (Console)
2.10. Step 10: Customizing User Data (Console) 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.
Page 230: Ocsp Migration
-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...
Page 231: Step 4: Migrating Security Databases
3.4. Step 4: Migrating Security Databases /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 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 5.3.2, “Case II: Security Databases to...
Page 232 3.4. Step 4: Migrating Security Databases 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"...
Page 233: Step 5: Migrating Password Cache Data
3.5. Step 5: Migrating Password Cache Data 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 14.
Page 234: Step 6: Migration Of Internal Databases
For more information on migrating internal databases, refer to Section 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/ Chapter 15. Detailed Example of a...
Page 235 /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.
Page 236 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 10. Log in as root, and set the file user and group to the Certificate System user and group.
Page 237: Step 7: Customizing User Data (Non-Console)
3.7. Step 7: Customizing User Data (Non-Console) • export INSTANCE 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 13. Import the old.ldif LDIF file into the 7.2 OCSP internal database. Open the OCSP database directory. cd /opt/redhat-ds/slapd-DS-instance Import the old LDIF for the user directory.
Page 238: Step 10: Customizing User Data (Console)
3.10. Step 10: Customizing User Data (Console) 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.
Page 239 3.11. Step 11: Verifying Migration 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.
Page 240: Index
Index command-line utilities CS Upgrade , 1 upgrading from previous versions , 1...

Red Hat CERTIFICATE SYSTEM 7.2 - MIGRATION GUIDE Manual

Table of Contents

Table of Contents

Quick Links

Chapters

Related Manuals for Red Hat CERTIFICATE SYSTEM 7.2 - MIGRATION GUIDE

Summary of Contents for Red Hat CERTIFICATE SYSTEM 7.2 - MIGRATION GUIDE

Table of Contents