- EJBCA Introduction
- Installation Prerequisites
- Managing EJBCA Configurations
- Creating the Database
- Application Servers
- Deploying EJBCA
- Installing EJBCA
- Finalizing the Installation
- High Availability and Clustering
- Maximizing Performance
- EJBCA Security
- Deployment Reference
- Upgrading EJBCA
- EJBCA Software Appliance
EJBCA CA Concept Guide
- Certificate Authority Overview
- 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
- Certificate and CRL Reader Service
- Certificate Expiration Check Service
- CRL Download and CRL Update Service
- CRL Updater Service
- HSM Keepalive Service
- Publisher Queue Process Service
- Remote Internal Key Binding Updater
- Renew CA Service
- User Password Expire Service
- OCSP Response Pre-Signer
- Rollover Service
- Peer Systems
- Internal Key Bindings Overview
- Roles and Access Rules
- Character Limitations
- User Data Sources
- EJBCA RA Concept Guide
EJBCA Operations Guide
CA Operations Guide
- Approving Actions
- 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
- Enrollment Protocol Configuration
- Roles and Access Rules Operations
- Managing CVC CAs
- RA Operations Guide
- Command Line Interfaces
- EJBCA Batch Enrollment GUI
- ConfigDump Tool
- CA Operations Guide
- EJBCA CA Concept Guide
Integrating with Third-Party Applications
- Access EJBCA using USB Tokens and Smart Cards
Auto Enrollment Configuration Guide
- Auto Enrollment Requirements
- Part 1: Active Directory Domain Services
- Part 2: MS Certification Authority and Group Policies
- Part 3: EJBCA Administration
- Part 4: EJBCA Certificate Chain Deployment to Clients
- Part 5a: Configure Microsoft Auto Enrollment Servlet on Windows
- Part 5b: Configure Microsoft Auto Enrollment Servlet on Linux
- Part 6: Prevent Duplicate Certificates
- Auto Enrollment Troubleshooting
- Microsoft Intune Device Certificate Enrollment
- Script based Autoenrollment for Windows clients with EJBCA
- Subordinate HashiCorp Vault CA to EJBCA Root
- Integrating EJBCA with Graylog
- Issuing Certificates to Kubernetes Services using cert-manager
- Using CertBot to Issue Certificates with ACME to an Apache Web Server
- Versasec Card Management System Integration
- Ciphermail Email Gateway and EJBCA Integration
- Microsoft Smart Card Logon
- 3Key Dashboarding, Monitoring and Reporting Add-on
- 3Key RA Profiles Add-on
- EJBCA and Cisco ISE
- 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
Hardware Security Modules (HSM)
- Generic PKCS#11 Provider
- AEP Keyper
- ARX CoSign
- AWS CloudHSM
- AWS KMS
- Azure Key Vault
- Bull Trustway PCI Crypto Card
- Bull Trustway Proteccio
- Google KMS
- nCipher nShield/netHSM
- Nitrokey HSM
- SafeNet AT Luna
- SafeNet Luna
- SafeNet ProtectServer
- Unbound Key Control
- Utimaco CryptoServer
- Utimaco CryptoServer CP5
- YubiHSM 2
- 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
- Setting up Peer Connectors and OCSP
- Uncommon CA Workflows
EJBCA Release Information
EJBCA Release Notes
- EJBCA 7.4.2 Release Notes
- EJBCA 7.4.1 Release Notes
- EJBCA 7.4 Release Notes
- EJBCA 22.214.171.124 Release Notes
- EJBCA 126.96.36.199 Release Notes
- EJBCA 188.8.131.52 Release Notes
- EJBCA 184.108.40.206 Release Notes
- EJBCA 7.3.1 Release Notes
- EJBCA 7.3 Release Notes
- EJBCA 220.127.116.11 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 18.104.22.168 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.4.2 Upgrade Notes
- EJBCA 7.4.1 Upgrade Notes
- EJBCA 7.4 Upgrade Notes
- EJBCA 22.214.171.124 Upgrade Notes
- EJBCA 126.96.36.199 Upgrade Notes
- EJBCA 188.8.131.52 Upgrade Notes
- EJBCA 7.3.1 Upgrade Notes
- EJBCA 7.3 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 184.108.40.206 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 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.
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 more detailed information.
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 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
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.