CA SiteMinder® Federation Standalone Installation and Upgrade Guide › Migrate to CA SiteMinder® Federation Standalone 12.52 › How to Migrate to 12.52 › Migrate the Key Database to the Certificate Data Store

Migrate the Key Database to the Certificate Data Store

If your environment contains one or more key databases (smkeydatabase), migrate the contents to the 12.52 certificate data store.

Note: To migrate SSL keys and certificates, review the SSL migration procedure.

The certificate data store is replacing the key database. If you have one or more smkeydatabases deployed in your environment, consider the following items:

• The certificate data store is collocated with the data server. A single certificate data store replaces the need for an individual smkeydatabase instance on each host system.
• As part of the upgrade, all smkeydatabase content is automatically backed up and migrated to the certificate data store.
• The federation system can only communicate with a certificate data store. A smkeydatabase does not operate in compatibility mode.

  Important! If the migration of the smkeydatabase fails, do not return the federation system into the environment. Returning the system after a failed migration causes all transactions that require the certificate data to fail.

• Synchronize all smkeydatabase instances before beginning the migration. Synchronizing all instances helps avoid data collisions. Data collisions prevent a successful migration.
• All federation systems share a common view into the same database server and have access to the same keys, certificates, and certificate revocation lists (CRL).
• The purpose of the certificate data store remains unchanged from the purpose of the smkeydatabase. This store makes the following available to the CA SiteMinder® environment:
  • Certificate authority (CA) certificates
  • Public and private keys
  • Certificate revocation lists
• If a CRL is stored in an LDAP directory service, consider the following items:
  • The federation system no longer requires that the issuer of the CRL is the same CA that issued the corresponding root certificate.
  • The federation system no longer performs this check. This behavior is consistent with the requirements for a text–based CRL.