- 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
- 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 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
The EJBCA framework for timer services handles procedures that run on a timely basis, performing various background tasks.
The following services types are available:
|CRL Updater Service||Checks if any of the configured CAs need a new CRL and generates it if necessary|
|Certificate Expiration Check Service||Checks if a CA has certificates about to expire and sends an email notification to the end user and/or the administrator.|
|User Password Expire Service||Checks if a user has not enrolled for a new certificate within a specified amount of time after the user was last edited. If the user has not enrolled within this time, the user's status is set to Generated and the user will not be able to enroll.|
|Renew CA Service||Checks if CA certificates are about to expire and automatically renews them.|
|Publisher Queue Process Service||Maintains a queue of publishing operations, periodically retrying any that have failed.|
|HSM Keepalive Service||The PKCS#11 protocol is fragile in terms of timeouts, so this service will periodically test all available crypto tokens by performing a test signing in order to avoid session timeouts to the HSM.|
|Remote Internal Key Binding Updater||Automatically renews expiring OCSP signing certificates and keys at a connected VA.|
|CRL Download and CRL Update Service||Periodically downloads a CRL from the provided URL and imports it into EJBCA, also updating any revocation information for the certificates.|
|Certificate and CRL Reader Service||Populates a VA with certificates and CRLs sent from a CA using the SCP Publisher.|
EJBCA also allows you to write plug-ins for customized services. For more information, see Writing Customized Services.
A service consists of the following components: a worker doing the actual work, an interval determining the time to the next time the service should run, and an optional action of what should be performed if a certain condition occurs.
The worker is the class that will be executed when the service runs. Each worker can have different worker specific configuration.
Defines in days/hours/minutes/seconds of how often the worker will be run.
Action that sends an email notification when the service is executed and has the following settings:
- Sender Address: The from-address used in the email.
- Receiver Address: The to-address of the email of not specified by the worker.
Pin to Specific Node(s)
Allows choosing on which nodes the service is allowed to execute. By not choosing any nodes in the list, the service can be executed on any of the nodes.
On EJBCA startup, each node adds its hostname to the list of nodes. The list can also be manually edited on the System Configuration page.
Run on all Nodes
By default, services execute on only one node in a cluster, or one of the pinned nodes. However, certain services like the HSM Keepalive service should be run on all nodes.
Selecting Run on all nodes disables checking if a service has been running on another node and executes the service on all nodes.
The Run on all nodes option should normally only be enabled for the HSM Keepalive service. Do not select the option for any other service unless you are absolutely sure you know what you are doing.
Multiple Services and Clustering
A service worker, except the HSM Keepalive service, should never run simultaneously on two nodes (or more than one instance of a worker running at a time on one node for that matter). To avoid running more than one instance on a single node there is a semaphore that inhibits more than one instance of the worker to run in a single JVM. If a worker starts and another worker is already running the worker is rescheduled to run on the next planned interval, and immediately terminated. To avoid running any two services on two nodes simultaneously, the service has a time stamp that is set when it runs and schedules the next run before the actual work is started. This time stamp makes it possible for another node to determine if the service is already running on another node and if so, does not start running.
In practice what this leads to is that a service will always run on a single node, the same node every time, but the running node may switch at times.
For most cases you do not have to pin a service to a specific node. Some reasons to pin nodes are:
- HSM Keepalive services: This service should have one service running on each node, since it should keep the local PKCS#11 session alive.
- External RA service: If having multiple RAs and running very often there may be a race condition with services competing to run. Pinning services to run on different cluster nodes towards different External RAs can increase performance and enhance simplicity.
Writing Customized Services
It is possible to write customized component plug-ins that can be used with other standards (or customized plug-ins) and this section explains the steps necessary.
Common for all the components is that it is required to create a class implementing the components interface. Then you have to create a special jar containing the necessary plug-in classes and meta-data (described below) and deploy it to the application server so it is included in the class-path. The next step is to create a service using the custom class and optionally the custom properties used by the component. The properties field has the same syntax as a regular Java property file.
The Jar must contain meta-data that describes which classes implement which interfaces. This is necessary since EJBCA enumerates all implementations using the ServiceLoader facility of Java. For each implemented interface the Jar must contain a file named META-INF/services/name.of.interface, for example META-INF/services/org.ejbca.core.model.services.IWorker. Each such file should contain a list of implementing classes, one per line. For example:
# Example file. Should be named META-INF/services/org.ejbca.core.model.services.IWorker com.example.ejbca.MyWorker com.example.ejbca.MyOtherWorker
It is not possible to hot-deploy EJBCA when customized services are used.
A Custom worker must implement the org.ejbca.core.model.services.IWorker interface. But a simpler way is to inherit the BaseWorker class. Then you have to implement one method 'void work()' doing the actual work every time the service framework decides it is time. The work method can make a call to the action (optional) component by 'getAction().performAction(someActionInfo);' The action info can vary depending on the action component, but it must implement the ActionInfo interface.CustomWorker
If something goes wrong during the work should a ServiceExecutionFailedException be thrown with a good error message.
See org.ejbca.core.model.services.workers.DummyWorker for an example implementation.
A Custom Interval must implement the org.ejbca.core.model.services.IInterval interface. But a simpler way is to inherit the BaseInterval class. You then have to implement one method 'public long getTimeToExecution();' which should return the time in seconds until the next time the service is run. Or it should return DONT_EXECUTE if the service should stop running.
See org.ejbca.core.model.services.intervals.DummyInterval for an example implementation.
A Custom Action must implement the org.ejbca.core.model.services.IAction interface.
A simpler way is to inherit the BaseAction class. Then only the method 'performAction(ActionInfo actionInfo)' needs to be implemented. The methods should perform the action according to the defined properties and the ActionInfo (all optional). If something goes wrong during the processing of the action should a ActionException be thrown.
See org.ejbca.core.model.services.actions.DummyAction for an example implementation.
For information on how to make sure that your plugin service gets deployed with EJBCA, see Modifying EJBCA