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 sections describe case-specific information on how to migrate from other CAs to EJBCA:
Migrating an OpenSSL based CA: A Csita guide with information on how to migrate an OpenSSL-based CA 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.
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.
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
End entity certificates
A complete migration involves a number of steps. The following displays an overview of the steps involved, followed by some more details.
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.
Once everything is tested, the import process involves the following steps:
Get production data
Validate production data
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.
Once the configuration has been verified, the EJBCA system can be run in production.
The following requirements should be checked in order to migrate successfully.
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.
Certificates and CRLs Delivered
The following must be downloaded and made available:
All certificate 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
Only standard certificate extensions. RFC5280.
The following special characters are not allowed to be used in the subject or issuer DN.
\r (carriage return)
CRLs and Revocation Information
CRLs are used to transfer the revocation information.
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.
The uid can be any identifier used as 'username' in EJBCA if such information exists.
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 end entity certificates.
After testing, the system should be validated and test certificates issued.