1. Manuals
  2. Brands
  3. Red Hat Manuals
  4. Software
  5. CERTIFICATE SYSTEM 7.0 - MIGRATION GUIDE
  6. Manual

Red Hat CERTIFICATE SYSTEM 7.0 - MIGRATION GUIDE Manual

Hide thumbs
Table of Contents

Advertisement

Quick Links

Download this manual
Red Hat Certificate System
Migration Guide: 7.x to 7.3
7.0
Matthew Harmsen
ISBN: N/A
Publication date: March 12, 2008

Advertisement

Table of Contents
loading

Related Manuals for Red Hat CERTIFICATE SYSTEM 7.0 - MIGRATION GUIDE

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

  • Page 1 Red Hat Certificate System Migration Guide: 7.x to 7.3 Matthew Harmsen ISBN: N/A Publication date: March 12, 2008...
  • Page 2 Red Hat Certificate System This migration guide provides in-depth procedures to migrate subsystems, user information, and certificate and key materials from Netscape Certificate Management System 7.0 and Red Hat Certificate System 7.1 and 7.2 to Red Hat Certificate System 7.3.
  • Page 3 All other trademarks referenced herein are the property of their respective owners. The GPG fingerprint of the security@redhat.com key is: CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E...
  • Page 4 Red Hat Certificate System...

  • Page 5: Table Of Contents

    1. Introduction to Red Hat Certificate System Migration ..........1 1. Certificate System Migration Overview ............1 1.1. Migration Scripts ................. 2 1.2. Certificate System Subsystems ............3 2. Considerations before Migration ..............4 2. Step 1: Preparing the Older Server Instance for Migration ......... 7 3.

  • Page 7: Introduction To Red Hat Certificate System Migration

    Chapter 1. Introduction to Red Hat Certificate System Migration Netscape Certificate Management System (CMS) versions 7.0, 7.1, and 7.2 can be migrated to Red Hat Certificate System version 7.3 using the Red Hat Certificate System migration utility. Certificate System has the ability to extract data from the installation of a previous version and migrate this data to 7.3.

  • Page 8: Migration Scripts

    Chapter 1. Introduction to Red Hat Certificate System Migration 6. Renew all migrated certificates. 1.1. Migration Scripts The Certificate System migration utility contains several separate platform-independent tools, but only two are required for migrating a Certificate System installation: one program to convert all of the data in an LDIF that was exported from the 7.x installation into a normalized LDIF text file, and another program to convert the normalized LDIF text file into an LDIF data file that can be imported into the newer Certificate System.

  • Page 9: Certificate System Subsystems

    Certificate System Subsystems Certificate Management System 7.x servers to Certificate System 7.3, use the script. TxtTo73 The import tool contains the following files: • Three precompiled Java™ classes • An tool shell script • An tool batch script • The Java™ source file that produced the precompiled Java™ classes •...

  • Page 10: Considerations Before Migration

    Chapter 1. Introduction to Red Hat Certificate System Migration Product (including service Subsystems Platforms packs and hot-fixes) Red Hat Certificate System Red Hat Enterprise Linux AS/ES 3 OCSP Red Hat Enterprise Linux AS/ES 4 Solaris 9 Red Hat Certificate System Red Hat Enterprise Linux AS/ES 4 (i386) OCSP...
  • Page 11 Considerations before Migration • On Linux and UNIX systems, make sure that the file owner (user and group) and the file permissions are correct when the file is copied between two instances. Also make sure that the target machine allows the file transfer. •...

  • Page 13: Step 1: Preparing The Older Server Instance For Migration

    Chapter 2. 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 complete, then make sure that the old Certificate System, Directory Server, and Administration Server instances have been stopped. For commercial backup programs, do the following: 1.
  • Page 14 Chapter 2. Step 1: Preparing the Older Server Instance for Migration System Command-Line Tools Guide. 2. Stop all server instances running in the Certificate System, including all Certificate System subsystems; the Directory Server, including all internal databases; and the Administration Server instances on the local machine.

  • Page 15: Step 2: Installing The New Certificate System

    Chapter 3. Step 2: Installing the New Certificate System Install a new Certificate System 7.3 instance. All subsystem instances are installed separately; make sure that every subsystem type which will be migrated has a corresponding new subsystem instance. 1. Obtain the appropriate packages either through the command or by downloading up2date the ISO image from the Certificate System 7.3 Red Hat Network channel.

  • Page 17: Step 3: Stopping The New Certificate System Servers

    Chapter 4. Step 3: Stopping the New Certificate System Servers 1. First, stop all new Certificate System instances. /etc/init.d/instance_ID stop 2. Then stop the Directory Server instance used by the Certificate System 7.3 servers. cd /opt/redhat-ds/slapd-DS-instance ./stop-slapd...

  • Page 19: Step 4: Migrating Security Databases

    Chapter 5. Step 4: Migrating Security Databases For every Red Hat Certificate System subsystem instance migration, the data from the certificate ( ) and key ( ) security databases for the Netscape Certificate cert8.db key3.db Management System 7.0 or Red Hat Certificate System 7.1 or 7.2 instances must be extracted and copied into the Red Hat Certificate System 7.3 subsystem's directory.
  • Page 20 Chapter 5. Step 4: Migrating Security Databases 2. Copy the certificate and key security databases from the 7.x server to the 7.3 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 3. Open the Certificate System directory. /alias cd /var/lib/instance_ID/alias/ 4. Log into the 7.3 server as root 5.

  • Page 21: Option 2: Security Databases To Hsm Migration

    Option 2: Security Databases to HSM 11. I f there is CA-DRM connectivity, then also modify the ca.connector.KRA.nickname attribute. ca.connector.KRA.nickname=caSigningCert cert-old_CA_instance 12. I n the same directory, edit the file to contain the old certificate serverCertNick.conf nickname. For example: Server-Cert cert-old_CA_instance 1.2.
  • Page 22 Chapter 5. Step 4: Migrating Security Databases chmod 00600 key3.db 7. List the certificates stored in the 7.x security databases by using the command; certutil lists the certificates. certutil -L -d . Server-Cert cert-old_CA_instance cu,cu,cu caSigningCert cert-old_CA_instance cu,cu,cu ocspSigningCert cert-old_CA_instance CTu,Cu,Cu subsystemCert cert-old_CA_instance cu,cu,cu 8.
  • Page 23 Migration 9. Delete the 7.x security databases. rm cert8.db rm key3.db 10. R egister the new HSM in the 7.3 token database. modutil -nocertdb -dbdir . -add new_HSM_token_name -libfile new_HSM_library_path/new_HSM_library 11. I dentify the new HSM slot name. modutil -dbdir . -nocertdb -list 12.
  • Page 24 Chapter 5. Step 4: Migrating Security Databases rm subsystemCert.p12 15. S et 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 25 Option 3: HSM to Security Databases tool provided by Certificate System cannot extract public/private key pairs pk12util from an HSM because of requirements in the FIPS 140-1 standard which protect the private key. To extract this information, contact the HSM vendor. The extracted keys should not have any dependencies, such as nickname prefixes, on the HSM.
  • Page 26 Chapter 5. Step 4: Migrating Security Databases databases. 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 pk12util -i ocspSigningCert.p12 -d .

  • Page 27: Option 4: Hsm To Hsm Migration

    Migration 13. I f there is CA-DRM connectivity, then also modify the ca.connector.KRA.nickname attribute. ca.connector.KRA.nickname=caSigningCert cert-old_CA_instance 14. I n the same directory, edit the file to contain the old certificate serverCertNick.conf nickname. For example: Server-Cert cert-old_CA_instance 1.4. Option 4: HSM to HSM Migration 1.
  • Page 28 Chapter 5. Step 4: Migrating Security Databases # chown user:group ocspSigningCert.p12 6. Log out as , and log back into the system as the Certificate System user. root 7. Set the file permissions. chmod 00600 ServerCert.p12 chmod 00600 caSigningCert.p12 chmod 00600 ocspSigningCert.p12 chmod 00600 subsystemCert.p12 8.

  • Page 29: Data Recovery Manager (Drm) Migration

    Data Recovery Manager (DRM) Migration rm ServerCert.p12 rm caSigningCert.p12 rm ocspSigningCert.p12 rm subsystemCert.p12 12. S et 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"...

  • Page 30: Option 1: Security Databases To Security Databases Migration

    Chapter 5. Step 4: Migrating Security Databases Determine if the migration to be performed involves software security databases, an HSM, or both, and follow the appropriate process for the deployment scenario being migrated. • Section 2.1, “Option 1: Security Databases to Security Databases Migration” •...

  • Page 31: Option 2: Security Databases To Hsm Migration

    Option 2: Security Databases to HSM 5. Set the file user and group to the Certificate System user and group. # chown user:group cert8.db # chown user:group key3.db 6. Log out as , and log back into the system as the Certificate System user. root 7.
  • Page 32 Chapter 5. Step 4: Migrating Security Databases 1. Remove all the security databases in the Certificate System 7.3 which will receive migrated data. rm /var/lib/instance_ID/alias/cert8.db rm /var/lib/instance_ID/alias/key3.db 2. Copy the certificate and key security databases from the 7.x server to the 7.3 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 33 Migration tool; exports the key pairs to a PKCS #12 file, and sets the name of the pk12util certificate and the old database prefix. 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...
  • Page 34 Chapter 5. Step 4: Migrating Security Databases 12. R egister the new HSM in the 7.3 token database. modutil -nocertdb -dbdir . -add new_HSM_token_name -libfile new_HSM_library_path/new_HSM_library 13. I dentify the new HSM slot name. modutil -dbdir . -nocertdb -list 14. C reate new security databases. certutil -N -d .

  • Page 35: Option 3: Hsm To Security Databases Migration

    Option 3: HSM to Security Databases 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 18. I mport 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 36 Chapter 5. Step 4: Migrating Security Databases key. To extract this information, contact the HSM vendor. The extracted keys should not have any dependencies, such as nickname prefixes, on the HSM. 2. Copy the extracted key pairs from the 7.x server to the 7.3 server. cp old_server_root/alias/ServerCert.p12 /var/lib/instance_ID/alias/ServerCert.p12 cp old_server_root/alias/kraStorageCert.p12...
  • Page 37 Migration 4. Open the Certificate System directory. /alias cd /var/lib/instance_ID/alias/ 5. Log in as root 6. 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 7.
  • Page 38 Chapter 5. Step 4: Migrating Security Databases rm kraStorageCert.p12 rm kraTransportCert.p12 11. S et the trust bits on the public/private key pairs that were imported into the 7.3 security databases. certutil -M -n "Server-Cert cert-old_DRM_instance" -t "cu,cu,cu" -d . certutil -M -n "kraStorageCert cert-old_DRM_instance" -t "u,u,u" -d . certutil -M -n "kraTransportCert cert-old_DRM_instance"...

  • Page 39: Option 4: Hsm To Hsm Migration

    Option 4: HSM to HSM Migration 2.4. Option 4: HSM to HSM Migration 1. Extract the public/private key pairs from the HSM. The format for the extracted key pairs should be portable, such as a PKCS #12 file. tool provided by Certificate System cannot extract public/private key pairs pk12util from an HSM because of requirements in the FIPS 140-1 standard which protect the private key.
  • Page 40 Chapter 5. Step 4: Migrating Security Databases e. Copy the key information from the 7.x server to the 7.3 server. cp old_server_root/alias/caSigningCert.b64 /var/lib/instance_ID/alias/caSigningCert.b64 4. Open the Certificate System directory. /alias cd /var/lib/instance_ID/alias/ 5. Log in as root 6. 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...
  • Page 41 Option 4: HSM to HSM 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 42: Online Certificate Status Protocol Manager (Ocsp) Migration

    Chapter 5. Step 4: Migrating Security Databases kra.storageUnit.nickname=new_HSM_slot_name:kraStorageCert cert-old_DRM_instance kra.transportUnit.nickname=new_HSM_slot_name:kraTransportCert cert-old_DRM_instance NOTE is not referenced in the file. caSigningCert CS.cfg 18. I n the same directory, edit the file to contain the old certificate serverCertNick.conf nickname. For example: new_HSM_slot_name:Server-Cert cert-old_DRM_instance 3.
  • Page 43 Option 1: Security Databases to Security 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 3. Open the Certificate System directory. /alias cd /var/lib/instance_ID/alias/ 4. Log in as root 5. Set the file user and group to the Certificate System user and group. # chown user:group cert8.db # chown user:group key3.db 6.

  • Page 44: Option 2: Security Databases To Hsm Migration

    Chapter 5. Step 4: Migrating Security Databases 10. I n the same directory, edit the file to contain the old certificate serverCertNick.conf nickname. For example: Server-Cert cert-old_OCSP_instance 3.2. Option 2: Security Databases to HSM Migration 1. Remove all the security databases in the Certificate System 7.3 server which will receive migrated data.
  • Page 45 Databases Migration 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 8. Export the public/private key pairs of each entry in the Certificate System databases using tool; exports the key pairs to a PKCS #12 file, and sets the name of the pk12util certificate and the old database prefix.
  • Page 46 Chapter 5. Step 4: Migrating Security Databases rm key3.db 11. R egister the new HSM in the 7.3 token database. modutil -nocertdb -dbdir . -add new_HSM_token_name -libfile new_HSM_library_path/new_HSM_library 12. I dentify the new HSM slot name. modutil -dbdir . -nocertdb -list 13.

  • Page 47: Option 3: Hsm To Security Databases Migration

    Option 3: HSM to Security Databases 17. I mport 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_OCSP_instance" -t "CT,c," -d . -h new_HSM_token_name -i caSigningCert.b64 18. O ptionally, delete the base-64 file. rm caSigningCert.b64 19.
  • Page 48 Chapter 5. Step 4: Migrating Security Databases 3. Extract the public key of the CA signing certificate from the 7.x security databases and save the base-64 encoded output to a file called caSigningCert.b64 a. Open the Certificate Management System 7.x directory.
  • Page 49 Migration # chown user:group caSigningCert.b64 7. Log out as . As the Certificate System user, set the file permissions. root chmod 00600 ServerCert.p12 chmod 00600 ocspSigningCert.p12 chmod 00600 caSigningCert.b64 8. Import the public/private key pairs of each entry from the PKCS #12 files into the 7.3 security databases.

  • Page 50: Option 4: Hsm To Hsm Migration

    Chapter 5. Step 4: Migrating Security Databases 13. O pen the configuration file in the instance_ID directory. CS.cfg /var/lib/ /conf/ 14. E dit the attribute to reflect the 7.3 OCSP instance. ocsp.signing.certnickname ocsp.signing.certnickname=ocspSigningCert cert-old_OCSP_instance NOTE is not referenced in the file.
  • Page 51 Option 4: HSM to HSM Migration b. Set the environment variable to search the Certificate System libraries. LD_LIBRARY_PATH LD_LIBRARY_PATH=old_server_root/bin/cert/lib export LD_LIBRARY_PATH c. Use the Certificate Management System 7.x tool to identify the old HSM slot certutil name. old_server_root/bin/cert/tools/certutil -U -d . d.
  • Page 52 Chapter 5. Step 4: Migrating Security Databases chmod 00600 caSigningCert.b64 8. 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 9. Identify the new HSM slot name. modutil -dbdir . -nocertdb -list 10.

  • Page 53: Token Key Service (Tks) Migration

    Token Key Service (TKS) Migration rm caSigningCert.b64 15. O pen the configuration file in the instance_ID directory. CS.cfg /var/lib/ /conf/ 16. E dit the attribute to reflect the 7.3 subsystem information. ocsp.signing.certnickname ocsp.signing.certnickname=new_HSM_slot_name:ocspSigningCert cert-old_OCSP_instance NOTE is not referenced in the file.
  • Page 54 Chapter 5. Step 4: Migrating Security Databases 2. Log into the 7.x server as the Certificate System user for that machine. 3. Migrate the master key from the 7.x TKS instance. (Depending on your installation, there may not be any master key information stored in the 7.x TKS instance.) a.

  • Page 55: Option 2: Security Databases To Hsm Migration

    Option 2: Security Databases to HSM # chown user:group key3.db 8. Log out as . As the Certificate System user, change the permissions on the files. root chmod 00600 cert8.db chmod 00600 key3.db 9. List the certificates in the security databases using the command.
  • Page 56 Chapter 5. Step 4: Migrating Security Databases 1. Remove all the security databases in the new Certificate System which will receive migrated data. rm /var/lib/instance_ID/alias/cert8.db rm /var/lib/instance_ID/alias/key3.db 2. Log into the 7.x server as the Certificate System user for that machine. 3.
  • Page 57 Migration 5. Copy the certificate and key security databases from the 7.x server to the 7.3 server. cp old_server_root/alias/cert-old_TKS_instance-cert8.db /var/lib/instance_ID/alias/cert8.db cp old_server_root/alias/cert-old_TKS_instance-key3.db /var/lib/instance_ID/alias/key3.db 6. Log into the new server as the Certificate System user, and open the Certificate System directory. alias/ cd /var/lib/instance_ID/alias/ 7.
  • Page 58 Chapter 5. Step 4: Migrating Security Databases 12. E xport the public key using the tool; lists the named certificate, sets the certutil name of the file and the old prefix, and outputs the information to a base-64 file. certutil -L -n "caSigningCert cert-old_TKS_instance" -d . -a > caSigningCert.b64 certutil -L -n "tksTransportCert cert-old_TKS_instance"...
  • Page 59 Option 2: Security Databases to HSM 20. I mport the public keys from the base-64 files into the new HSM, and set the trust bits. certutil -A -n "new_HSM_slot_name:caSigningCert cert-old_TKS_instance" -t "CT,c," -d . -h new_HSM_token_name -i caSigningCert.b64 certutil -A -n "new_HSM_slot_name:tksTransportCert cert-old_TKS_instance" -t "CT,C,C"...

  • Page 60: Option 3: Hsm To Security Databases Migration

    Chapter 5. Step 4: Migrating Security Databases and tks_master_key_version_name are set. NOTE is not referenced in the file. caSigningCert CS.cfg 30. I n the same directory, edit the file to contain the old certificate serverCertNick.conf nickname. For example: new_HSM_slot_name:Server-Cert cert-old_TKS_instance 4.3.
  • Page 61 Migration In this example, is the tks_master_key_version_ number, is the old_HSM_slot_name, and is the tks_master_key_version_name. tks_master_key_v2 4. Migrate symmetric keys from the 7.x TKS instance. Two things are required: • A written copy of the original three session key shares to reproduce the symmetric transport key on the 7.x TKS instance.
  • Page 62 Chapter 5. Step 4: Migrating Security Databases -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 e. Copy the key data from the 7.x server to the 7.3 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...
  • Page 63 Option 3: HSM to Security Databases rm ServerCert.p12 13. S et the trust bits on the public/private key pairs that were imported into the new security databases. certutil -M -n "Server-Cert cert-old_TKS_instance" -t "cu,cu,cu" -d . 14. I mport the public keys from the base-64 files, and set the trust bits. certutil -A -n "caSigningCert cert-old_TKS_instance"...

  • Page 64: Option 4: Hsm To Hsm Migration

    Chapter 5. Step 4: Migrating Security Databases tks.drm_transport_cert_nickname=tksTransportCert cert-old_TKS_instance 23. I f a master key has been migrated from the 7.x TKS instance, insert the tks_master_key_version_number "tks.mk_mappings.# #01=internal: tks_master_key_version_name" line at the end of the . Be certain to use the proper CS.cfg values for tks_master_key_version_number, and tks_master_key_version_name.
  • Page 65 Migration tks_master_key_version_number #01= old_HSM_slot_name:tks_master_key_version_name line. A value looks tks.mk_mappings like the following: tks.mk_mappings.#02#01=mu:tks_master_key_v2 In this example, is the tks_master_key_version_ number, is the old_HSM_slot_name, and is the tks_master_key_version_name. tks_master_key_v2 4. Migrate symmetric keys from the 7.x TKS instance. Two things are required: •...
  • Page 66 Chapter 5. Step 4: Migrating Security Databases old_server_root/bin/cert/tools/certutil -U -d . d. Use the Certificate System 7.x tool to extract the public key of the following certutil entries from the security databases and save each base-64 output to a separate file. old_server_root/bin/cert/tools/certutil -L -n "old_HSM_slot_name:caSigningCert cert-old_TKS_instance"...
  • Page 67 Option 4: HSM to HSM Migration 11. R egister the new HSM in the new token database. modutil -nocertdb -dbdir . -add new_HSM_token_name -libfile new_HSM_library_path/new_HSM_library 12. I dentify the new HSM slot name. modutil -dbdir . -nocertdb -list 13. I mport the public/private key pair from the PKCS #12 file into the new HSM. pk12util -i ServerCert.p12 -d .
  • Page 68 Chapter 5. Step 4: Migrating Security Databases 19. T ype in the original three key session key shares (as prompted) to recreate the original transport key on the new HSM. 20. L og in as root 21. S et the file user and group to the Certificate System user and group for each file.

  • Page 69: Step 5: Migrating Password Cache Data

    Chapter 6. Step 5: Migrating Password Cache Data The password information for the Certificate System subsystems are saved in a special password file. In Certificate System 7.0 and 7.1, these were kept in the file. The pwcache.db contents of the password file must be decrypted and listed using the tool in the PasswordCache 7.x subsystem instance.
  • Page 70 Chapter 6. Step 5: Migrating Password Cache Data 3. Use the listed tags and passwords to create the file. For example: password.conf internal=password Internal LDAP Database=passwordldap 4. If the 7.x server instance used the file to start the server instance password.conf automatically, then this file must also be migrated to the 7.3 server instance.

  • Page 71: Step 6: Migrating Internal Databases

    Chapter 7. Step 6: Migrating Internal Databases Every Red Hat Certificate System 7.x subsystem contains LDIF data in an associated internal database which must be migrated to the corresponding Red Hat Certificate System 7.3 subsystem internal database. The procedure is the same for each subsystem type. The only difference between Certificate System 7.x versions is which import and export utility to use;...
  • Page 72 Name the output file internaldb.database CS.cfg new.ldif For example: /opt/redhat-ds/slapd-DS-instance/db/db2ldif -n server.example.com-rhpki-ca -a /opt/redhat-ds/slapd-DS-instance/ldif/new.ldif 3. Log into the 7.x Certificate System instance, and export the database contents to LDIF. Name the output file old.ldif For example: cd old_server_root/slapd-old_instance-db/db/db2ldif -n userRoot -a old_server_root/slapd-old_instance-db/ldif/old.ldif...
  • Page 73 NOTE When using a text editor to perform the substitution instead of a script, use an editor that supports file sizes greater than 4 gigabytes, such as vim, because the LDIF files may be larger than 2 gigabytes and even 4 gigabytes in some deployments.
  • Page 74 Chapter 7. Step 6: Migrating Internal Databases dn: cn=Enterprise CA Administrators,ou=groups,basedn description: People who are the administrators for the security domain for objectClass: top objectClass: groupOfUniqueNames cn: Enterprise CA Administrators uniqueMember: uid=admin,ou=People,basedn dn: cn=Enterprise KRA Administrators,ou=groups,basedn description: People who are the administrators for the security domain for objectClass: top objectClass: groupOfUniqueNames cn: Enterprise KRA Administrators...
  • Page 75 7. Log into the 7.3 server as the Certificate System user, and open the Certificate System directory. ldif/ cd /opt/redhat-ds/slapd-DS-instance/ldif 8. Log in as , and set the file user and group to the Certificate System user and group. root # chown user:group old.txt...
  • Page 76 INSTANCE c. Run to use to create an LDIF file. run.sh old.txt run.sh /opt/redhat-ds/slapd-DS-instance/ldif/old.txt > /opt/redhat-ds/slapd-DS-instance/ldif/old.ldif 11. I mport the LDIF file into the Certificate System 7.3 server instance's internal old.ldif database. a. Open the Certificate System 7.3 database directory.

  • Page 77: Step 7: Customizing User Data (Non-Console)

    Chapter 8. Step 7: Customizing User Data (Non-Console) Copy all customized plug-ins, profiles, and forms to the Certificate System 7.3 server, and apply any hand-edited changes to the Certificate System 7.3 file. CS.cfg In this example, the profile configuration in the old_CA_instance has been changed to enable S/MIME support.
  • Page 78 Chapter 8. Step 7: Customizing User Data (Non-Console) OU=Engineering,O=Example policyset.set1.p1.default.params.ldap.enable=true policyset.set1.p1.default.params.ldap.searchName=uid policyset.set1.p1.default.params.ldapStringAttributes=uid,mail policyset.set1.p1.default.params.ldap.basedn=dc=example,dc=com policyset.set1.p1.default.params.ldap.maxConns=4 policyset.set1.p1.default.params.ldap.minConns=1 policyset.set1.p1.default.params.ldap.ldapconn.Version=2 policyset.set1.p1.default.params.ldap.ldapconn.host=ldaphostA.example.com policyset.set1.p1.default.params.ldap.ldapconn.port=389 policyset.set1.p1.default.params.ldap.ldapconn.secureConn=false The altered profile serves certificate requests with S/MIME support enabled.

  • Page 79: Step 8: Starting All Certificate System 7.3 Instances

    Chapter 9. Step 8: Starting All Certificate System 7.3 Instances 1. Restart the Directory Server for the Certificate System 7.3 instance. cd /opt/redhat-ds/slapd-DS-instance ./start-slapd 2. Start all of the Certificate System 7.3 instances. /etc/init.d/instance_ID start...

  • Page 81: Step 9: Generate New Certificate System Server Certificates

    Chapter 10. Step 9: Generate New Certificate System Server Certificates If the Certificate System 7.3 server is on a different machine than the Certificate Management System 7.x server, then an SSL server certificate associated with each newly-migrated Certificate System server instance must be created. There are three procedures to generate new server certificates, depending on the subsystem: generating self-signed CA server certificates;...

  • Page 82: Requesting A New Ssl Server Certificate From A Third-Party Ca

    Chapter 10. Step 9: Generate New Certificate System Server Certificates Algorithm panel. e. The next panel is Subject Name for the SSL Certificate. For the component, enter the fully qualified domain name, such as , of the Certificate System 7.3 CA zeta.example.com instance machine.

  • Page 83: Generating A New Drm, Ocsp, Or Tks Ssl Server Certificate

    Generating a New DRM, OCSP, or TKS SSL . Fill in information in the other fields on this panel; it is strongly omega.example.com recommended that the components also be filled in. e. Go through the remaining panels in the Certificate Setup Wizard, and fill in the different fields or use the defaults.
  • Page 84 Chapter 10. Step 9: Generate New Certificate System Server Certificates a. In the Type of Operation panel, select the Request a certificate option (the default). b. In the Certificate Selection panel, select SSL Server Certificate from the pull-down menu. An SSL server certificate request is generated, which can be submitted to a CA for approval.

  • Page 85: Step 10: Customizing User Data (Console)

    Chapter 11. 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.

  • Page 87: Step 11: Verifying Migration

    Chapter 12. Step 11: Verifying Migration After migrating all Certificate Management System 7.x subsystems to the corresponding Certificate System 7.3 subsystem instances, open the CA end-entities services page and each subsystem agent services pages for the Certificate System 7.3 server to ensure that everything is working properly.

This manual is also suitable for:

Certificate system 7.1Certificate system 7.2Certificate system 7.3 - administration

Table of Contents