- EJBCA Introduction
- Installation Prerequisites
- Managing EJBCA Configurations
- Creating the Database
- Application Servers
- Deploying EJBCA
- Installing EJBCA
- Finalizing the Installation
- High Availability (HA), a.k.a Clustering
- Maximizing Performance
- EJBCA Security
- Deployment Reference
- Upgrading EJBCA
EJBCA CA Concept Guide
Certificate Authority Overview
- CA Fields
- ePassport PKI
- ECDSA Keys and Signatures
- CVC CA
- Partitioned CRLs
- Crypto Tokens Overview
- End Entities Overview
- Active Directory Publisher
- Custom Publishers
- LDAP Publisher/LDAP Search Publisher
- Multi Group Publisher
- SCP Publisher
- Validation Authority Peer Publisher
- Validation Authority Publisher (Legacy)
- AWS S3 Publisher
- Validators Overview
- Certificate Profiles Overview
- Approval Profiles
- Peer Systems
- Internal Key Bindings Overview
- Roles and Access Rules
- Character Limitations
- User Data Sources
- Certificate Authority Overview
- EJBCA RA Concept Guide
EJBCA Operations Guide
CA Operations Guide
- Approving Actions
- CA UI Overview
- Configure EJBCA for Public Access
- CRL Generation
- EJBCA Configuration Checker
- EJBCA Maintenance
- End Entities
- End Entity Profile Operations
- Exporting and Importing Profiles
- Importing Certificates
- Key Recovery
- Managing CAs
- Managing Certificate Profiles
- Managing Crypto Tokens
- Managing Internal Keybindings
- Modular Protocol Configuration
- OCSP Management
- Peer Systems Operations
- Roles and Access Rules Operations
- RA Operations Guide
- Command Line Interfaces
- EJBCA Batch Enrollment GUI
- ConfigDump Export and Audit Tool
- CA Operations Guide
- EJBCA CA Concept Guide
Integrating with Third-Party Applications
- Access EJBCA using USB Tokens and Smart Cards
- Native Certificate Autoenrollment for Windows
- Microsoft Intune Device Certificate Enrollment
- Script based Autoenrollment for Windows clients with EJBCA
- Integrating EJBCA with GreyLog
- Versasec Card Management System Integration
- Ciphermail Email Gateway and EJBCA Integration
- Microsoft Smart Card Logon
- EJBCA and Cisco IOS
- OpenSSH and X509 Authentication
- Configure EJBCA with OpenSSO
- Setting up an Apache Web Server as a Proxy
- Setting up an Apache Web Server with mod_jk
- Setting up a HA Proxy in front of EJBCA
- EJBCA with GemSAFE Toolbox
- SensorNet PKI
- Issuing Certificates to Kubernetes Services using cert-manager
- Hardware Security Modules (HSM)
- Integrating with Third-Party Applications
- Troubleshooting Guide
Tutorials and Guides
- Quick Install Guide
- Migrating from other CAs to EJBCA
- Modifying EJBCA
- Enabling Debug Logging
- Creating a custom RA application using EJBCA Web Services and Java
- Using EJBCA as a Certificate Management System (CMS)
- Batch Creating Certificates
- Making an ASN.1 Dump of a Certificate
- Using the Demo Servlet
EJBCA Release Information
EJBCA Release Notes
- EJBCA 184.108.40.206 Release Notes
- EJBCA 7.2.1 Release Notes
- EJBCA 7.2 Release Notes
- EJBCA 7.1 Release Notes
- EJBCA 7.0.1 Release Notes
- EJBCA 7.0.0 Release Notes
- EJBCA 6.15.2 Release Notes
- EJBCA 6.15.1 Release Notes
- EJBCA 6.15 Release Notes
- EJBCA 6.14.1 Release Notes
- EJBCA 6.14 Release Notes
- EJBCA 6.13 Release Notes
- EJBCA 6.12 Release Notes
- EJBCA 6.11 Release Notes
- EJBCA 6.10 Release Notes
- EJBCA 6.9 Release Notes
- EJBCA 6.8 Release Notes
- EJBCA 6.7 Release Notes
- EJBCA 6.6 Release Notes
- EJBCA 6.5 Release Notes
- EJBCA 6.4 Release Notes
- EJBCA 6.3 Release Notes
- EJBCA 6.2 Release Notes
- EJBCA 6.1 Release Notes
- EJBCA 6.0 Release Notes
- EJBCA Release Notes Summary
- EJBCA Change Log Summary
EJBCA Upgrade Notes
- EJBCA 7.2.1 Upgrade Notes
- EJBCA 7.2 Upgrade Notes
- EJBCA 7.1 Upgrade Notes
- EJBCA 7.0.1 Upgrade Notes
- EJBCA 7.0 Upgrade Notes
- EJBCA 6.15 Upgrade Notes
- EJBCA 6.14 Upgrade Notes
- EJBCA 6.13 Upgrade Notes
- EJBCA 6.12 Upgrade Notes
- EJBCA 6.11 Upgrade Notes
- EJBCA 6.10 Upgrade Notes
- EJBCA 6.9 Upgrade Notes
- EJBCA 6.8 Upgrade Notes
- EJBCA 6.7 Upgrade Notes
- EJBCA 6.6 Upgrade Notes
- EJBCA 6.5 Upgrade Notes
- EJBCA 6.4 Upgrade Notes
- EJBCA 6.3 Upgrade Notes
- EJBCA 6.2 Upgrade Notes
- EJBCA 6.1 Upgrade Notes
- EJBCA 6.0 Upgrade Notes
- EJBCA Upgrade Notes Summary
- EJBCA Release Notes
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 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.
- 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.
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 CAs.
Import end entity certificates.
After testing, the system should be validated and test certificates issued.