- 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 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 22.214.171.124 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 126.96.36.199 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
Integrity Protected Security Audit Log
ENTERPRISE This is an EJBCA Enterprise feature.
There are many ways to fulfill requirements on Log Signing, also known as Signed Log Files.
- The built in EJBCA Database Integrity Protection (described here).
- Sign logs with external tools as they are being rotated. For more information, see External Log Signing section in EJBCA Security.
The IntegrityProtectedDevice Security Audit Log implementation stores the log entries to the database and relies on the Database Integrity Protection in EJBCA for protecting the authenticity of the log events. Each log event is given an identifier consisting of a "nodeId" and a "sequenceNumber" that is part of the integrity protected data. The nodeId is configurable and must be unique for each JVM in a cluster with shared database access. The "sequenceNumber" is unique per nodeId and starts with 0. The sequenceNumber for a node (JVM) is read when the first log entry is written to this device and then kept in memory for the duration of the JVM's lifetime.
For more technical details, see the Database Integrity Protection in EJBCA Security.
The security of this implementation relies on:
- Database integrity protection token.
- The sequence number in memory for each node (JVM).
Using a sequence number will prevent that a single log entry is removed without detection being possible. Keeping the sequence number in the JVM will prevent that all log entries up to a previous point in time is removed without detection being possible.
This implementation cannot detect:
- Removal of all the latest log entries for a node up to a previous point in time if the node's JVM is not running.
- Forged log entries if the database integrity protection token is compromised.
The motivation for this design is that each node (JVM) does not have to wait for other nodes in a (shared database only) cluster. Internally in each JVM the only locking between threads happens when the sequence number is atomically updated. This will allow horizontal scaling to a very high degree without any JVM-to-JVM communication when the shared database supports row-locking.
When using this implementation, the integrity of each fetched log entry is always validated when loaded from the database, but full validation with checks for missing sequenceNumbers are not performed.
Configuration of integrity protected log device is in the files:
It is possible to verify a whole table with the Local Database CLI tool. If any row in the table can't be verified the tool will show it. For the AuditRecordData table it will also be checked with the sequence number that no row is missing.
Verifying Integrity Protected Security Audit Logs
The Local Database CLI can be used to verify database protection both in an online EJBCA instance and in a database where only a Security Audit Log has been exported.
For more information on the Local Database CLI, see Command Line Interfaces.
Repairing Sequence Gaps
The Security Audit Log sequence number per node is a counter. Whenever there is a need to write an Security Audit Log entry, the counter is fetched and incremented (as an atomic operation). If the write to the database fails:
- The counter will not be decreased (since multiple threads might be operating on it there is no way of knowing what the missing entry is).
- There will be a sequence gap in the log
This could also happen in the case where an attacker has removed certain entries in the database to cover his or her tracks. Since failing to write audit log to the database will roll back the transaction that initiated the security event, the security event will not be performed. Most likely you could correlate this with server logs from the time this happen to find that the database was unavailable for technical reasons. For example, a MariaDB+Galera cluster that is in the process of reforming a quorum could experience a few failed transactions before being operational again.
There is currently no user-friendly way to "repair" such sequence, but it should rather be documented why this happened (or rather that the cause was technical and not malicious).
A non-user-friendly way to repair sequence gaps follows this principle:
- In a copy of the database, delete all records except 1 (or as many as you have holes)
- Update the record(s), using sql to change sequenceNumber to the ones missing, and primaryKey to something unique
- Run ejbca-db-cli export from the copy database. This will result in a dump with only these records, matching the holes in the original database
- Run ejbca-db-cli import to import this dump in the original database. This will insert the missing sequenceNumbers, using databaseprotection as configured in your ejbca-db-cli
Starting a Fresh Audit Log
If the audit log gets too large or damaged, you can start a fresh new audit log instead of trying to repair an old one. Since the Audit Log is controlled per EJBCA node, you can do this either globally (for all nodes) or for a single node.
To start a fresh audit log globally, for all nodes, do the following:
- Stop all EJBCA nodes.
- Archive/Export the existing AuditRecordData table, in order to have the old audit log available off-line (you do not want to just delete it without keeping a copy).
- Truncate the AuditRecordData table, removing all existing records.
- Start EJBCA nodes again. With AuditRecordData empty, each node will start a fresh new audit log.
Exporting Security Audit Logs
All installations have their specific requirements how audit logs should be handled. There are several ways to export Security Audit Logs.
- Rotate system log files (including the audit log) and archive/process the rotated log files
- Use a SYSLOG appended to send the System log (including the Audit log) to a central log server that performs monitoring functions.
- Export the database audit log using the Local Database CLI
- Export the database audit log using database tools
- Export a specific view from the Audit Log page in CA UI to an XML file
- Export a specific view from the Audit Log page in CA UI to a signed CMS (Cryptographic Message Syntax)