Considerations Before Migration - Red Hat CERTIFICATE SYSTEM 7.2 - MIGRATION GUIDE Manual

Chapter
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.
• Perform all steps in the migration procedure for every instance of each subsystem being migrated. Always follow the
steps for migration in the order which they are presented in the manual, even if not every step needs to be performed.
• Perform each subsystem migration as a separate migration. Wait until one subsystem migration is complete before
starting the migration of the next subsystem.
• 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.
• While the migration procedure refers to extracting data from a hardware security module (HSM), no Certificate System
tool can extract public/private key pairs from an HSM because of Federal Information Processing Standard (FIPS)
140-1, which protects the private key portion of an entry. Contact the HSM vendor for information on how to extract
data from an old HSM. Extracted keys should not have any dependencies, such as nickname prefixes, upon the old
HSM.
• It is possible to change the names of migrated Certificate System subsystem instances, but greater care must be taken
when extracting and renaming certain portions of the data. Because port numbers are stored in the server.xml file,
which is unaffected by subsystem migration, port numbers can be changed between instances without difficulty.
• All examples assume that the new passwords are the same as the old passwords.
• The chmod command used in the examples have the permissions 00600 (octal, no sticky bit permissions, user read/
write permissions, no group permissions, no other permissions). These are the recommended permissions, but are not
required.
The following considerations apply to a specific subsystem or a specific version of Certificate System:
• It is not possible to migrate TPS data from Netscape Certificate Management System 7.0 to Red Hat Certificate System
version 7.1 or later.
• The default key-splitting scheme used by the DRM subsystem in Certificate System 7.1 and later is not the scheme re-
quired by the DRM subsystem key recovery feature in previous versions. Currently, there is no way to migrate from
the old key-splitting scheme to the new scheme. Therefore, DRM instances in Certificate System versions older than
7.1 cannot be successfully migrated to versions 7.1 or later.
• In Certificate Management System 7.0, the RA subsystem was deprecated and replaced by the TPS subsystem, so it is
not possible to migrate RA subsystems into Certificate System versions 7.0 or later. All RA request queues should be
processed by the older-version servers into their existing CAs before beginning any CA migrations.
• Certificate Management System 4.2 contained a third-party OCSP responder called ValiCert Certificate Validation Au-
thority (VATM). It is not possible to migrate data in this component.
• Certificate Management System versions 4.1 and 4.2 contained platform-dependent migration utilities to extract Certi-
ficate Server 1.0 data from AIX, HP-UX, Solaris, and Windows NT [Intel] platforms. No migration utilities are avail-
able to migrate data from Digital UNIX, IRIX, or Windows NT [alpha] platforms.
3. Considerations
7
before
Chapter 3. Considerations before