- 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 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 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
CRL partitioning allows CRLs to be partitioned in several smaller CRLs, instead of one large CRL. This enables you to verify portions of very large CRLs without spending the time to access and validate one large CRL.
CRL partitioning works by assigning each certificate to a random-generated CRL partition number upon issuance. The relying party can map the certificate to the correct partition via the CRL Distribution Point extension, and the CRL can be verified to be the correct CRL from the right partition, by checking its Issuing Distribution Point extension. The functionality is compliant with RFC 5280.
Please verify that your relying parties' software support CRL partitioning before using it. Both the CRL Distribution Point and the Issuing Distribution Point extension must be supported, in the certificate and the CRL respectively. For most use cases, OCSP is a better option.
The following tables list configurations required for the CA and Certificate Profile respectively.
To use partitioned CRLs, the CA must be configured according to the following. For information on all available CA fields, see CA Fields.
|CRL Specific Data|
|Issuing Distribution Point on CRLs|
Must be enabled. Setting it to critical is strongly recommended for security reasons.
This extension is needed so client can check that a CRL belongs to the correct partition. Without this extension (or if non-critical, and not understood by the client), it would be possible to send the wrong CRL to a client, which would then consider all certificates to be not revoked.
|Use CRL partitions||Must be enabled for partitioned CRLs to work.|
|Number of CRL partitions|
Total number of partitions, and the number of CRLs to generate. This is the highest partition number that will be used in new certificates. Must be at least 1.
This value can be increased to scale up with more partitions. Do not decrease this value, unless you are sure there are no certificates in existence with a higher CRL partition.
|Number of suspended partitions|
Normally this should be 0, which means there will be no suspended partitions. A suspended partition will not receive new certificates. This value can be temporarily increased to balance the partitions, if the low numbered partitions are larger than the high numbered ones. Since certificates are randomly assigned to a CRL partition, there should be no need to balance the partitions unless the number of partitions has been increased.
New certificates will be assigned a partition between (number of suspended partitions + 1) and (number of CRL partitions), inclusive. CRLs are always generated for all partitions, regardless of this setting.
|Default CA defined validation data|
|Default CRL Distribution Point|
Certificates must have a CRL Distribution Point (DP) URL which points to the correct partition. The CRL DP URL affects the CRL scope (see RFC 5280, section 5), and must match exactly between the certificate and the CRL.
Asterisks "*" are replaced with the partition number (except for partition 0, where the asterisks are removed without replacing). The URL must contain at least one asterisk.
If you use the built-in "certdist" URL, all you need to do is to add ¶m=* to the URL. This is done automatically if you click Generate button after enabling the Use CRL partitions option.
|Default Freshest CRL Distribution Point||If using Delta CRLs (also known as the "Freshest CRL" extension), you need to specify an URL with an asterisk for the partition number, in the same way as in the "Default CRL Distribution Point" field.|
Certificate Profile Configuration
The Certificate Profile for issued certificates must be configured according to the following. For information on all available Certificate Profile fields, see Certificate Profile Fields.
|Certificate Profile Setting||Requirements|
|CRL Distribution Points||Must be enabled|
|Use CA defined CRL Distribution Point||Must be enabled|
Certificates that are issued with certificate profiles not configured as above, and any pre-existing certificates prior to activating partitioned CRLs, will have partition number 0.
Let's assume you have the following settings for your CA:
If you then issue a certificate with a certificate profile configured as in the Configuration section, it would be assigned a partition number between 21 and 30, inclusive. The certificate will point to the correct CRL partition using the CRL Distribution Point extension in the certificate. For example, if the certificate was assigned partition 25, then the URL
would be included in the certificate at issuance. Relying parties would then use this URL to check for revocation.
When you revoke the certificate it would go to that CRL partition, and would be included on the CRL the next time it is generated. If the certificate in this example was revoked, then the next time CRLs were generated for the CA, the CRL for partition 25 would contain the serial number of the revoked certificate.
After a CA has been configured with partitioned CRLs, then requesting creation of a new CRL will generate CRLs for all partitions.
This applies to the CRL Update Worker, CLI, the WebService, the AdminWeb, as well as all operations that indirectly trigger CRL generation, such as CA import or renewal.
CRL Partitioning and Publishing
Certificate publishers and CRL publishers may or may not support partitioned CRLs. Publisher support is shown in the following table:
|Publisher||Type||CRL Partitioning Support|
|Active Directory Publisher||Certificate/CRL|
Yes, for certificates.
|LDAP V3 Publisher||Certificate/CRL|
Yes, for certificates.No, for CRLs.
|LDAP V3 Search Publisher||Certificate/CRL|
Yes, for certificates.No, for CRLs.
|Multi Group Publisher||Certificate/CRL||Yes (if publishers in groups support partitioned CRLs).|
|Validation Authority Peer Publisher||Certificate/CRL|
Yes.For certificates, the VA does not need to know the partition (it does not issue CRLs), so the CRL partition number will be NULL in the CertificateData table on the VA.
|Validation Authority Publisher||Certificate/CRL|
Fetching CRL Partitions
EJBCA supports fetching CRL partitions by specifying a parameter in the URL. By default, if no parameter is given, it will return CRL partition 0 (which will contain any existing certificates, see Configuration).
The following servlets support retrieving CRL partitions. In the example URLs, the partition number is 123.
|Servlet name||Parameter name||Example URL|
Requires client certificate.
Non-existing partitions are handled the same way as a non-existing CA would be handled. For example, search.cgi will give the HTTP response "204 No Content".
EJBCA supports import of certificates to a CA with partitioned CRLs, as long as the CRL Distribution Point extension is present and exactly matches the value configured in the CA setting Default CRL Distribution Point. The CRL partition number will be extracted from the CRL DP URL.
Certificates that do not meet the requirement above will be imported into partition 0.