- 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 Web 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 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 22.214.171.124 Release Notes
- EJBCA 7.3.1 Release Notes
- EJBCA 7.3 Release Notes
- EJBCA 126.96.36.199 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 188.8.131.52 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 184.108.40.206 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 220.127.116.11 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
Certificate Authority Overview
A Certificate Authority (CA) instance is the basic building block of a PKI installation, and can in an instance be described as the basic building block. The primary role of a CA is to handle issuance and revocation of certificates, and secondarily to validate, publish and provide workflows for effective certificate management. If you scale it down, a CA could simply consist of a keypair and a script, but in EJBCA we try to provide far more than that.
This Certificate Authority Overview covers conceptual information on CAs.
Certificate Authority Type
The first question to take into account when creating CA is the type. EJBCA currently supports two types:
- X509: The most common CA type for secure email, login, web authentication, VPN and so on as defined in RFC 5280.
- CVC: A CA issuing CV certificates, which are special certificates for EU EAC ePassports. For more information on CVC CAs, see CVC CA.
Crypto Tokens in CA contexts have historically been called CA Tokens. While this term is purely historical, it may still be referenced in older documentation and configuration files. The two terms can be considered equivalent.
The basis of a CA will always be centered around one or more key pairs. From a CA's point of view, these are stored in a crypto token and need to be signed before they can be of any use. For information on types of crypto tokens available and where the private keys are stored, see Crypto Tokens Overview.
A CA is defined to use several key pairs which are mapped to a purpose. In the following example, the purpose mapping can be seen on the left while the key pair alias is on the right. Note that the same alias can be used for several mappings.
- defaultKey: The key to use if no specific key is selected.
- certSignKey: The key to use for certificate issuance. Must comply with the signing algorithm chosen (see below).
- crlSignKey: The key to use for CRL signing. Even though it could theoretically be separate from the certSignKey according to the RFCs, client support is rare and the certSignKey will always be used.
- keyEncryptKey: Key to use for key recovery (if enabled) and decrypts escrowed keys. This key pair must be RSA as EC is not capable of encryption.
- hardTokenEncrypt: Deprecated functionality, do not use.
- testKey: Key used by health-check to verify that the crypto token is usable. Usually a short key for speedy connection checks.
The signing algorithm to use for issuing certificates, signing CRLs etc. The choice of algorithm must correspond to the key pair types available in the crypto token. Thus SHA256WithRSA can only be used in conjunction with RSA keys.
The keys associated with a CA are of no use unless they've been signed, and the result of this signature is the CA Certificate. The certificate can be self-signed (a Root CA), signed by another local CA (making it a Sub CA or Intermediate CA), or signed externally (requiring the generation and signature of a CSR before the CA can be made active). Choosing a certificate profile for the CA will not affect the certificates issued by this CA, but rather the certificates for this CA.
In addition to the above, there are a number of CA-specific settings and values to configure for a CA in order to comply with various RFCs and specifications. Besides those mentioned in detail below, all CA fields are defined and described on CA Fields.
Approvals and Workflows
For more information on Approvals and workflows, see Approvals Overview.
Some CA operations can be set up to require additional approvals, to allow lower level administrators to request that certain operations be performed and to require several individuals to sanction an action. The following actions can be configured for approval:
- Adding and editing End Entities
- Performing Key Recovery operations
- Revoking certificates
- Activating CA Services
Approvals are configured using Approval Profiles, which act as general approval workflow templates.
For more information on existing publishers and how to configure them, see Publishers Overview.
Signing and storing certificates is often not enough, they need to be published to various locations as well.
Common Publishing Operations
Publishers can come in various shapes and sizes, but common applications for publishers are:
- Publishing certificates and CRLs from the CA to a VA.
- Publishing certificates into an LDAP structure.
- Publishing certificates into a
- Various Custom Publishers.
Certificate Authorities can be set to either direct publishing (which is instant, and which may cause the complete certificate issuance to fail if it fails in turn) or queued publishing, which is asynchronous but far more robust. Queued publishing is selected by marking a publisher to use the queue, and then setting up a Service Worker to process that queue.
For more information on validators, what they do and how to extend them, see Validators Overview.
A common requirement among Certificate Authorities is the ability to validate certificates or their contents prior to, during or after the signing process and before they're stored and published. For this reason, EJBCA provides the Validator construct, where Validators can be instanced and configured based on templates and configured to have various effect on the issuance process, varying from just warning to outright rejecting the certificate being issued. Examples of validation operations are:
- Checking that the size and security of submitted public keys align to predefined constraints.
- Checking submitted public keys against a known black list of weak keys.
- Performing online checks, such as Certificate Authority Authorization.
Validators can be created and edited in the CA UI and are chosen per CA for use.
All good things come to an end, certificate validities notwithstanding. All certificates should expire within a reasonable date, if for no other reason to enforce that security fixed and updated algorithms are universally rolled out. EJBCA provides full support for renewing Certificate Authority certificates and rolling those out, including the use of rollover certificates. For more information on the process of renewal, see Managing CAs.