Migrating from other CAs to EJBCA

This section includes information on CA migration and outlines a general migration procedure as well as case-specific information on migrating from different CAs to EJBCA.

CA Specific Migration Procedures

The following describe case-specific information on how to migrate from other CAs to EJBCA:

Migrating RSA Keon CA with nCipher: Describes how to migrate an RSA Keon CA using nCipher HSM to EJBCA and covers migrating the CA signing keys, importing the CAs to EJBCA and importing issued certificates to EJBCA. The result is a setup in EJBCA that can continue operation transparently.
Migrating Microsoft CA to EJBCA
Migrating OpenSSL CA to EJBCA

Generic Migration Procedure

The following outlines a generic process when migrating a CA to EJBCA. The actual migration may hit roadblocks such as non-supported certificate contents. Such issues are often found during a test migration, performed in order to solve similar issues prior to a final migration in production.

Migration Plan

This generic migration plan can be used as a base for migrating any CA to EJBCA.

Transferring data from another CA involves four different types of data:

HSM key material
CA certificates
End entity certificates
Revocation information

Migration Steps

A complete migration involves a number of steps. The following displays an overview of the steps involved, followed by more detailed information.

Configure Profiles

Before the certificates are imported, all the End Entity Profiles and Certificate Profiles used by the imported CAs and End Entities should be configured.

CA and Certificate Import

Once the key material is on the HSM and ready to be used, the CAs can be imported. Thus importing CA certificates and creating the CA objects in EJBCA, including Crypto Tokens. The import of CAs is performed using command line scripts, requiring information of the HSM slot, the HSM key labels, and the CA certificate.
When the CAs are created, the End Entity certificates and CRL can be imported. The import of End Entity certificates is performed using command line scripts, requiring information of the certificate, the issuing CA, and the 'username' to be used in EJBCA.

Import Process

Once everything is tested, the import process involves the following steps:

Get production data
Validate production data
Import

Configuration After Transfer

Validate the configuration of the following CA Configuration, Certificate Profiles, and End Entity Profiles fields after the transfer:

Set up CDP and AIA in Profiles.
Set CRL validity.
Set CA Certificate Profiles and configure CA settings.
Issue OCSP certificates.
Revoke old OCSP certificates.
Publish to OCSP.
Issue CRL.

Once the configuration has been verified, the EJBCA system can be run in production.

Migration Prerequisites

The following requirements should be checked in order to migrate successfully.

HSM Requirements

Labels on the private keys in the HSM must be used and should have a sane value. The following pattern format is recommended:

<caname>SignKey<date> for example, rootCAG3SignKey20160226 or highAssuranceCASignKey20160226

Do not use special or internalized characters in the labels.

Certificate Requirements

Certificates and CRLs Delivered

The following must be downloaded and made available:

All certificates in the whole CA chain (in PEM or DER format), including external CA certificates, i.e. CA certificates of the previous solution.
All issued certificates (in PEM or DER format).
CRLs, per CA. Only the latest CRL is required unless the revocation history of expired certificates are also needed.

Certificate Technical Requirements

The following are requirements on the certificate content:

Only standard subject DN attributes. RFC5280 and CABForum.
Only standard subject altNames. RFC5280 with the additional restrictions.
- No OtherName, except MS UPN, as these are usually custom
- No x400Address
- No ediPartyName
- No registeredID
Only standard certificate extensions. RFC5280.
The following special characters are not allowed to be used in the subject or issuer DN.
- \n (newline)
- \r (carriage return)
- \0 (null)
- ;
- !
- %
- ` (backtick)
- ?
- $
- ~

CRLs and Revocation Information

CRLs are used to transfer the revocation information.

Expired Certificates

Expired certificates can be imported and CRLs are used for revocation information. If only the latest CRL is downloaded, expired certificates may not be marked as revoked, even if they were., since expired certificates are not included in CRLs (following RFC5280).

Certificate Delivery Format

Certificates should be downloaded and made available in a directory layout, per CA, per certificate profile.

CAName/CertificateProfileName/uid.pem (…)

The uid can be any identifier used as 'username' in EJBCA if such information exists.

Audit Logs

Audit logs should be exported securely and stored off-line to be available in an audit.

Questions and Notes

Questions to consider prior to a migration:

Expected certificate volumes?
Consider exporting data from the old CA in order to test validity.
Will the migration be the first CAs created (except for the Management CA)? i.e. the CA import will be the “key ceremony”.
Will the systems be running in parallel? If so, it is necessary to do a kind of “delta migration”.
What will be used as 'username' in EJBCA?

A rather extensive testing of import can be performed without private keys (provided we have all the certs/CRLs). The CAs will all get imported as externals and the profile conformance of provided data can be validated.

Test Migration Process

The process should be tested thoroughly before migration.

Get test data.
Validate test data.
If using an HSM, make an HSM slot plan, which slot is used for which CA.
Import HSM slots according to the slot plan.
Generate new keys for a Management CA and install EJBCA. Now a Management CA is created.
Import CAs.
Import end entity certificates.
Import CRLs.

After testing, the system should be validated and test certificates issued.