EJBCA Release Notes Summary

The following lists release notes for all EJBCA versions released.

For information on features and improvements implemented per release, see the EJBCA Release Notes. The EJBCA Release Notes also include a change log, listing all issues resolved in the release and a cross-reference to our JIRA Issue Tracker for full details on issues resolved in the release.

EJBCA 8.3 Release Notes

EJBCA 8.3.2

JUNE 2024

The EJBCA 8.3 maintenance release includes error corrections for Microsoft Auto-enrollment through a peer connected RA, and for using RSASSA-PSS on Windows deployments. This release also brings additional improvements and vulnerability upgrades.

EJBCA 8.3

MAY 2024

The following lists highlights in EJBCA 8.3.1 and EJBCA 8.3.0. (EJBCA 8.3.0 was an internal release, not available for customers). 

EJBCA Container Set

EJBCA introduces the EJBCA Container Set, enabling customers to deploy EJBCA on Kubernetes using Helm charts included in this release. The EJBCA Container Set provides separate container variants for Certificate Authority (CA), Registration Authority (RA), and Validation Authority (VA). Customer deployments are designed to utilize a setup where RA(s) and VA(s) are distinct EJBCA instances from the CA(s), connected via the Peers protocol.

For Hardware Security Module (HSM) integration in a container-based deployment, the EJBCA Container Set includes sidecar containers tailored to each supported HSM type. Alternatively, an EJBCA container-based deployment may integrate with HSMs using REST API integrations, which do not require a sidecar container.

Hybrid Certificates

EJBCA 8.3 introduces support for hybrid certificates, enabling the use of multiple signing keys in a single hybrid CA. Certificates issued by this CA will have signatures and public keys of two different algorithms. Typically, the system is set up to use a quantum-safe algorithm as the alternative algorithm. This setup allows parts of the ecosystem to validate the certificate using both keys and algorithms, while other parts may ignore the non-critical extensions and alternative algorithm, treating the certificate as a traditional RSA/ECC X.509 certificate.

Note that the quantum-safe algorithms currently implemented in EJBCA are NIST draft algorithms and not for production use, see Hybrid CA.

Microsoft Auto-Enrollment Improvements

Microsoft Auto-enrollment support has been significantly improved. It is recommended to configure auto-enrollment aliases on the CA(s) rather than the RA(s) in distributed deployments, enhancing operations in multi-domain and multi-RA deployments. Additionally, ECDSA is now supported as an algorithm in Microsoft auto-enrollment. EJBCA 8.3 also introduces the "supply in the request" option for Subject Name. For more information, see Microsoft Auto-enrollment Overview.

EJBCA updated with top-level menu

EJBCA now has a top-level menu, relocated from the left side to align with other Keyfactor products. The menu structure remains the same, ensuring that existing users can find previous menu items under the corresponding top-level categories.

Documentation on Keyfactor Docs

As of EJBCA 8.3, the EJBCA product documentation is available at docs.keyfactor.com.

EJBCA RA Web Translated to French

The EJBCA RA user interface is now available in French. A huge thank you goes out to David Carella from Linagora who made this possible.

Announcements

Upcoming Technology Stack upgrade in EJBCA 9

As a Java application running on an application server, EJBCA 8.3 runs on WildFly 24/26 or JBoss EAP 7.4 and supports running on Java 11 or Java 17. Due to changes in recent WildFly versions and JBoss EAP 8 that are not backward compatible with WildFly 26 and JBoss 7.4, the upgrade from EJBCA 8 to the upcoming new major version EJBCA 9 will require a complete tech stack upgrade. 

EJBCA customers with software-based deployments are advised to plan for an upgrade to the EJBCA 9 tech stack once EJBCA 9 is released during the second half of 2024.

Security Issue

EJBCA 8.3 resolves a security issue affecting the CMP CLI client bundled with EJBCA. The issue does not affect EJBCAs server-side CMP implementation.

We rate the issue as having a severity level of medium. Once EJBCA 8.3 has been generally available across all platforms for at least two weeks, a CVE with the identifier CVE-2024-36066 will be published.

Removal of legacy OCSP key renewal mechanism

A legacy key renewal mechanism (using the SOAP API) has been removed, as it has been made redundant by automated key renewal over Peers for a few years. With this, properties matching ocsp.rekeying.* in ocsp.properties are no longer used and can be removed.

Deprecation of Certificate Profile and revocation status specific OCSP Response validities

Response validities (and Max-Age for the HTTP header) can be configured to be specially handled per certificate profile or if the status is revoked by setting them in ocsp.properties. This functionality has been redundant for the last few years by instead configuring the values in the OCSP Responder, and will be removed in the next release of EJBCA. The properties that will be removed are:

• ocsp.999.untilNextUpdate
• ocsp.999.revoked.untilNextUpdate
• ocsp.999.maxAge
• ocsp.999.revoked.maxAge

In addition, the following properties were unused and have been removed in this release:

• ocsp.revoked.untilNextUpdate
• ocsp.revoked.maxAge

Deprecation of DSTU and GOST algorithms

As of EJBCA 8.3, support for the DSTU and GOST algorithms is deprecated and will be removed in the next release.

Removal of DSA algorithm

Support for the DSA algorithm has been removed in EJBCA 8.3, following its deprecation in EJBCA 8.2. Users of this algorithm must migrate to other algorithms.

Note that if you have used ConfigDump in earlier versions to export Certificate Profiles with all key algorithms selected (per default behavior), you must remove DSA from the list before importing the profiles into EJBCA 8.3.

Removal of Configuration Checker

The experimental user interface tool Configuration Checker is removed in EJBCA 8.3, since support and development have been dropped.

Removal of ca.keystorepass property from cesecore.properties

The ca.keystorepass property, declared in cesecore.properties, and its associated functionality has been removed. The property enabled the setting of a default keystore password for soft crypto tokens, and only when created from the CLI. Besides being of questionable functionality, its use would at best be considered poor security practice and has thus been removed.

Microsoft Auto-Enrollment via RA in EJBCA 8.3.1

Customers using Microsoft Auto-enrollment via the RA will face an issue in EJBCA 8.3.1, causing enrollment to fail. Affected customers are advised to upgrade to EJBCA 8.3.2, where this issue has been corrected.

Before upgrading to EJBCA 8.3.2, customers using EJBCA 8.3.1 and Microsoft Auto-enrollment via the RA can manually export the certificate profiles used by the MSAE aliases from the CA side using either the GUI or the EJBCA ConfigDump tool. Importing the profiles on the RA will then make the RA accept Microsoft Auto-enrollment requests successfully.

EJBCA 8.2 Release Notes

DECEMBER 2023

Post-Quantum Certificate Issuance with HSM Support

EJBCA supports the Dilithium and Falcon NIST candidate post-quantum algorithms since EJBCA 8.0. EJBCA 8.2 now introduces support for the use of a hardware security module (HSM) with support for the Dilithium algorithm.

Since Dilithium is not part of the PKCS11 standard, it requires an HSM vendor-defined extension in the PKCS11 interface. For information about supported HSM vendors and models, contact Keyfactor.

Note that the Dilithium algorithm is suitable for non-production use only. NIST standardization is planned for completion in 2024 and the Dilithium algorithm can be used for proof-of-concept (PoC) and post-quantum transition preparation activities until then. For more information, see Post-Quantum Cryptography Keys and Signatures.

Microsoft Auto-Enrollment Key Archival

EJBCA 8.2 introduces a new option in Microsoft auto-enrollment enabling administrators to configure key archival in the EJBCA setup for MSAE. Key archival is typically used in use cases like certificates for Encrypted File Systems (EFS) and encrypted e-mails using S/MIME certificates.

Key Archival can be enabled per end entity profile. For profiles with key archival enabled, the private keys corresponding to issued certificates will be encrypted and stored in EJBCA. If a private key is lost, EJBCA allows a CA administrator to recover the key for a user.

For information on how to set up EJBCA for key archival in Microsoft Auto-enrollment, refer to EJBCA Administration.

RA Chaining

EJBCA 8.2 implements RA chaining support to enable zero trust hybrid and multi-cloud PKI deployments based on extended flexibility in distributed EJBCA deployments. The established EJBCA security model for separating the Registration Authority (RA) and Validation Authority (VA) from the Certificate Authority (CA) in EJBCA deployments is based on setting up mTLS-secured peer connections initiated from the CA to the RA and the VA. The associated network setup will normally not accept any incoming connections to the CA. Instead, all external communication is targeting the RA and VA and these communicate with the CA through the mTLS peer connections.

For certain deployment scenarios, customers want to deploy an EJBCA RA in a network environment that is set up not to accept incoming connections from where the EJBCA CA is deployed. The RA chaining feature is introduced to support such deployments. An RA chaining-based setup uses the same principles for the separation of CA, RA, and VA as described above. One or more additional RAs are then deployed in an external environment. These additional EJBCA RAs use outgoing mTLS-secured peer connections to an EJBCA RA traditionally connected to the EJBCA CA. For details on how to set up EJBCA instances in your PKI infrastructure as described above, see RA Chaining. 

Announcements

Deprecation of DSA Algorithm

The use of the DSA algorithm in EJBCA is deprecated as of EJBCA 8.2. DSA algorithm support is scheduled to be removed in an upcoming release, and users are advised to use other algorithms in its place.

EJBCA 8.1 Release Notes

SEPTEMBER 2023

Subject Name Log Redaction

Using the Subject Name Log Redaction feature in EJBCA 8.1, EJBCA administrators can set up the system to redact Subject Distinguished Name (SubjectDN) and Subject Alternate Name (SAN) from the audit log and trace logs for configured end entities. Subject Name Log Redaction can be used to set up EJBCA for compliance with data privacy regulations relating to the content of the SubjectDN and SAN fields. For more information, see Subject Name Log Redaction.

Expired Certificate Cleanup

A new service has been added in EJBCA 8.1 to enable automated cleanup of expired certificates and Certificate Revocation Lists (CRLs). The interval used by the service to check for expired certificates and CRLs is configurable as well as the time period to keep certificates and CRLs in the system once expired. For more information, see Database Maintenance Service.

EJBCA 8.0 Release Notes

JUNE 2023

SSH certificates

EJBCA 8 includes the new Certificate Authority (CA) type SSH CA capable of issuing Secure Shell Protocol (SSH) certificates. The use of SSH certificates for certificate-based authentication in SSH rather than SSH key distribution and management allows organizations to both increase productivity and improve security. Enabling SSH servers and clients to trust the CA means that SSH can leverage the power of PKI.

With EJBCA you can now issue SSH certificates in addition to X.509 certificates, Card Verifiable certificates, and C-ITS certificates. SSH certificate enrollment is supported through the EJBCA REST API and the EJBCA RA user interface. For more information, see SSH CA.

EST over CoAP in EJBCA LRA Software Appliance

In order to extend deployment flexibility EJBCA 8 enables the deployment of a Local Registration Authority (LRA) to issue birth certificates or operational certificates in IIoT and IoT use cases. Resource-constrained devices can enroll for certificates using EST over CoAP. Running EST over CoAP in EJBCA 8 requires using an EJBCA LRA Software Appliance connected to an EJBCA Certificate Authority (CA). 

General EST support in EJBCA 8 has also been extended to support server-side key generation. Server-side key generation may be used regardless of whether EST is carried over HTTP or CoAP.

Post-Quantum Readiness

EJBCA 8 includes support for creating CAs using the NIST round 3 candidate post-quantum signature algorithms Dilithium and Falcon. The standardization of these algorithms is planned to be finalized by INST in 2024. These algorithms are not for production use but are well suited for post-quantum preparation activities and proof of concept usage. For more information on post-quantum algorithm support in EJBCA, see Post-Quantum Cryptography Keys and Signatures.

Matter Smart Home support

Matter is a new standard for interoperable and secure smart home devices. Matter security is based on certificates and the required certificates can be issued by EJBCA using new subject DN attributes as specified in the Matter standard. For more information, see Create CAs for Matter IoT.

Fortanix DSM support

EJBCA 8 includes a new crypto token type enabling integration with Fortanix Data Security Manager (DSM) Cloud HSM through the Fortanix REST API. For more information on the REST integration and creating the Fortanix crypto token in EJBCA, see Fortanix Data Security Manager.

ACME improvements

EJBCA 8 adds support for DNS Identifier Validation using the tis-alpn-01 Challenge. ACME has also been extended to support HS384 and HS512 MAC algorithms.

ISO 15118-20 (EV charging) support

Extended EJBCA functionality related to SubjectKeyIdentifier and AuthorityKeyIdentifier enables setting up EJBCA 8 to issue certificates according to the requirements specified in ISO 11518-20.

Certificate Counting

A new REST endpoint enables counting the number of issued and active certificates.

Technology upgrades

As a new major version the technology stack supported by EJBCA 8 includes some important updates compared to EJBCA 7. EJBCA 8 supports running on Java 17 in addition to Java 11. Running on Wildfly 26 as application server is also supported and the EJBCA use of application server is based on JEE8. Bouncy Castle has been upgraded to version 1.73.

Announcements

Security Issue

EJBCA 8.0 resolves an authentication issue discovered in EJBCA 7.12.0 that allowed the EJBCA RA user interface certificate distribution servlet to allow partial denial of service.

We rate the issue as having a severity level of medium. Once EJBCA 8.0 has been generally available across all platforms for at least two weeks, a CVE with the identifier CVE-2023-34196 will be published.

Public Web not supported

EJBCA Public Web has been deprecated since EJBCA 7.9 and is no longer supported in EJBCA 8. Customers are advised to use the functionality available in the EJBCA RA user interface.

Running on Java 8 not supported

Running on Java 8 has previously been deprecated and EJBCA 8 does not support running on Java 8.

Old application servers not supported

Running EJBCA 8 on WildFly 10-22 as well as JBoss EAP 7.0-7.3 is not supported. WildFly 26 and JBoss EAP 7.4 are currently the recommended application servers for running EJBCA 8.

Removal of End Entity Printing Functionality

As of this version of EJBCA, we have removed the functionality to print End Entities using SVG templates, as this feature was rarely used and not maintained. 

Removal of cesecore-p11.jar and CKA_MODIFIABLE=false

This feature was added a while back to provide a workaround for a vulnerability that has long since been patched by HSM vendors. This workaround does not work in JDK11 and above, so has been removed. 

Removal of CMS Signing for Audit Logs

CMS signing was rarely used and required signatures from a soft key stored on the CA. This functionality has been removed from the audit log pages, as well as the accompanying CA settings. 

Removal of the legacy asynchronous CMP Proxy

The legacy CMP Proxy, which allowed the CA to poll a database for incoming CMP requests, has been retired and removed. The main purpose of acting as a proxied CMP endpoint has been redundant for some time by the EJBCA RA, and the last remaining functionality that was available on the proxy has now been rolled into the RA as well. 

Removal of the legacy asynchronous SCEP Proxy

Like the CMP proxy above, the SCEP proxy has been redundant for quite some years by EJBCA acting as RA. It has now been fully removed. 

Removal of ECDSA ImplicitlyCA

The ECDSA ImplicitlyCA functionality has long been discouraged from use, and support has now been entirely removed from EJBCA. Note that ImplicitlyCA has nothing to do with explicit ECDSA parameters.  

EJBCA 7.12 Release Notes

EJBCA 7.12.0.3

This maintenance release includes important corrections and additional improvements for EJBCA 7.x customers. All EJBCA 7 customers are advised to upgrade to EJBCA 8.

This release also resolves a security authentication issue (ECA-11478) discovered in EJBCA 7.12.0 that allowed the EJBCA RA user interface certificate distribution servlet to allow partial denial of service. This issue is rated as medium severity and has been assigned CVE-2023-34196. It is recommended that customers upgrade to EJBCA 8 in order to resolve the issue. While EJBCA 7 is still supported, customers may choose to upgrade to EJBCA 7.12.0.3 as an intermediate step.

EJBCA 7.12.0.1

This maintenance release addresses an issue with key generation on Utimaco CP5 HSM. Use of EJBCA releases between 7.10.0 and 7.12.0 for integration with Utimaco CP5 HSM is impacted by this issue that is corrected in EJBCA 7.12.0.1. 

EJBCA 7.12.0

CRL Invalidity Date

EJBCA now supports CRL Invalidity Date, a non-critical extension for CRL entries that allows administrators to specify a date for CRL entries on which it is known or suspected that the private key was compromised.

For more information on the CRL Invalidity Date extension, see CRL Generation or refer to RFC 5280: Internet X. 509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (section 5.3.2).

Announcements

Deprecations

The following legacy functionality in EJBCA is now deprecated and will be removed in the next major release:

• Asynchronous CMP Proxy - Customers previously using the CMP Proxy are advised to migrate to RA Validation of CMP messages in a peer-connected CA/RA setup. For more information, see CMP Proxy.
  
• Asynchronous SCEP Proxy - The external RA SCEP server functionality is deprecated and we recommend proxying SCEP requests synchronously through an RA using Peers instead, see Legacy External RA SCEP Server.
• End Entity printing functionality - For more information, see Printing of User Data.
• CMS signing for Audit Logs - Customers are recommended to use the built-in Integrity Protected Security Audit Log or external tools for audit log signing. For more information, see Signing Exported Log Files.
• ECDSA Implicitly CA - Implicitly CA parameters are not the same as explicit parameters and using implicit CA parameters is rare and not useful in practice. For more information, see ECDSA Keys and Signatures.

EJBCA 7.11 Release Notes

EJBCA 7.11.0.1

Key recovery data not persisted using P11NG

An issue introduced in EJBCA 7.10 prevented the storage of key recovery data when utilizing the EJBCA key recovery functionality with the P11NG crypto token. If the system was configured to use key recovery with P11NG, a certificate would be issued but the key recovery data would be missing. This issue has been corrected in EJBCA 7.11.0.1. 

Customers not using key recovery with P11NG or running earlier versions of EJBCA than 7.10 are not affected. 

EJBCA 7.11.0

Revocation Reason Change

Addressing Mozilla's Root Store Policy, this release introduces the ability to change the revocation reasons for previously revoked certificates. Changing revocation reason is enabled at the Certificate Authority level, and backdating is allowed if set in the relevant Certificate Profile. The new revocation reason can only be Key Compromise. The revocation reason can be changed through the EJBCA REST API, RA Web UI, and Web Services. For more information, see Allow Changing Revocation Reason in CA Fields and Allow Backdated Revocation in Certificate Profile Fields.

RA Validation of CMP Messages

For EJBCA deployments with a peer-connected RA separate from the CA where the CMP protocol is used for enrollment, EJBCA 7.11 now provides a new option in which the CMP messages are validated on the RA before being forwarded to the CA. The validation applies to signature-protected messages as well as to HMAC-protected messages. Aside from providing enhanced security in deployments using CMP for enrollment, it allows customers to migrate to a standard peer-connected EJBCA CA/RA configuration following the deprecation of the CMP Proxy and External RA in EJBCA 7.11. For more information, see CMP.

Partial Support for CMP Lightweight Profile

With EJBCA 7.11, a subset of the CMP Lightweight Profile is available for use with CMP in EJBCA. CMP Lightweight profile defines a specified subset of CMP operations and functionality, mainly targeting industrial and IoT use cases including resource-constrained devices. With this release, support has been added for message protection with PBMAC-1 as well as the P10CR message body. For more information, see CMP.

Separation of Keybindings into OCSP Responders and Remote Authentication

To improve usability, the OCSP Key Bindings and Authentication Key Bindings configurations have been replaced with new OCSP Responders and Remote Authenticators pages in the EJBCA CA UI. User input for OCSP Responder and Remote Authenticator configuration is now tailored to each use case, while the Internal Keybindings concept is still used internally. The behavior of existing key bindings is not affected by this usability change. For more information, see Remote Authenticators Overview.

Announcements

Validation CLI Tool Removed

As announced in previous upgrade notes, the legacy CLI-based Validation Tool has now been removed from EJBCA.

Deprecation of External RA and CMP Proxy

As of EJBCA 7.11, the use of External RA and CMP Proxy is deprecated. Customers previously using the CMP Proxy are advised to migrate to RA Validation of CMP messages in a peer-connected CA/RA setup.

EJBCA 7.10 Release Notes

EJBCA 7.10.0.1

EJBCA 7.10.0 was an internal release, not generally available for customers). 

REST API Improvements

Expansion of the EJBCA REST API has been a top wish list item for some time and with this release, we have added new endpoints to make it easier to determine available profiles and manage CRLs. Several existing endpoints have also been improved to facilitate integration and you can expect further REST API expansion down the road. For details, see EJBCA 7.10.0.1 Release Notes.

ECCDH Support for Key Recovery

We have added support for using EC keys to encrypt archived keys using ECCDH. For more information, see Encryption Keys in Key Recovery.

Certificate Self-Renewal

An updated version of the old self-renewal feature in the Public Web has been brought to the RA. Clients can now authenticate themselves to the RA Web using a client certificate and renew their own (and only their own) certificate without the intervention of an RA administrator. Administrators can enable this feature per end entity profile to specify a minimum amount of time before expiration that the renewal should be allowed. For more information, see the end entity profile field Allow Renewal Before Expiration, and to learn more about EJBCA RA operations, see the RA Operations Guide.

Security Issues

EJBCA 7.10 includes fixes for the following security issues.

Microsoft ADCS Vulnerability

Addressing a recent vulnerability discovered for Microsoft Certificate-Based Authentication, EJBCA now supports the new Extension szOID_NTDS_CA_SECURITY_EXT that maps the certificate to an Active Directory user/computer object. The extension will be allowed by default for all certificate profiles and included in certificates enrolled via EJBCA's Microsoft Auto-enrollment integration. For more information, see Microsoft ObjectSid Security Extension in Certificate Profile Fields.

XSS Vulnerability in CA UI

This release resolves a stored XSS vulnerability discovered in the EJBCA Admin Web. An authenticated administrator with sufficient access could compromise other administrators using the AdminWeb, via script injection. The injection could be done via addendentity.jsp for end entity profiles that have Number of allowed requests configured. Triggering occurred when viewendentity.jsp was rendered. An attacker would need administrator access, with access to the access rules /administrator, /ra_functionality/create_end_entity or /ra_functionality/edit_end_entity, and access to at least one End Entity Profile and at least one CA.

We rate the issue as having high impact and medium probability. This issue has been submitted as a CVE, see CVE-2022-39834.

XSS Vulnerability in RA Web

During internal testing, a stored XSS vulnerability was discovered in the RA Web end entity and certificate search pages, caused by subject fields not being escaped properly. This affects installations that allow subject fields to be specified by untrusted clients, for example, via protocols configured in RA mode,  and profiles configured to allow subject DN override by CSR.

We rate the issue as having medium impact and medium probability. This issue has been submitted as a CVE, see CVE-2022-42954.

EJBCA 7.9 Release Notes

EJBCA 7.9.1

Improvements to Microsoft Auto-enrollment Integration

We have resolved a couple of issues related to concurrent requests to EJBCA's auto-enrollment servlets. The improvements ensure proper handling of parallel requests, even under heavy loads.

New OAuth Key Updater Service

To better support OAuth providers' key rollover process, a new service worker has been added which automatically polls the provider for new public keys. See OAuth Key Update Worker for more details.

EJBCA 7.9.0

Log4j Upgrade

As has been stated before, EJBCA was never vulnerable to CVE-2021-44228 nor the subsequent findings due to the fact that EJBCA handles logging through JBoss EAP/Wildfly, merely facilitated by the Log4j API. Log4j version 1 has been included in the source mainly as a building block and not used in the main deployment, and is only ever directly referenced from the CLI, but will hence still trip automatic vulnerability scanners. As we understand that many of our customers need to comply with auditors and other regulatory authorities, we have decided to accelerate the planned upgrade of Log4j to the latest release in order to dissolve any questions about EJBCA being vulnerable. 

Use of Microsoft Graph API in EJBCA Intune Integrations

Previous versions of EJBCA use the Azure AD Graph API for Intune integrations. Microsoft has announced that Azure AD Graph API will be deprecated as of June 2022 and Intune integrations need to use Microsoft Graph API instead. EJBCA 7.9.0 uses Microsoft Graph API for Intune integrations making it an important upgrade for EJBCA customers using Intune.

Support for acting as Enrollment Authority in C-ITS PKI

Cooperative Intelligent Transport Systems (C-ITS) is an ecosystem facilitating communication between vehicles and between vehicles and infrastructure, jointly known as vehicle-to-everything (V2X). EJBCA 7.9.0 introduces functionality allowing EJBCA to act as an Enrollment Authority (EA) in a C-ITS PKI, registering ITS entities and issuing enrollment credentials. While not including every component of the C-ITS PKI, this release marks our first effort toward supporting the C-ITS PKI lifecycle with EJBCA. For more information, see C-ITS ECA Overview.

Announcements

Public Web Deprecated

Since the launch of EJBCA, the Public Web has been used for common operations such as enrollment, CRL and CA certificate download, etc. EJBCA 6.6 introduced the new RA Web along with a new RA architecture, enabling more efficient RA workflows that also overlapped many functionalities of the Public Web. Throughout recent releases including this one, we have added additional features to the RA Web in an effort to allow all RA operations to be managed from the location. RA Web enhancements have made the Public Web increasingly redundant and Public Web is therefore deprecated as of EJBCA 7.9.

Public Web is still available in EJBCA 7.9.0 but will no longer be supported as of the next major version of EJBCA. We recommend migrating your workflows to the RA Web in preparation for the future removal of the Public Web. Certain use cases might not be fully replaceable by the RA Web yet but we will be putting the last pieces together to support them in upcoming releases. Endpoints for CA/CRL distribution located under the Public Web URL will remain available.

CMP over TCP no longer Supported

Use of CMP over TCP has been discouraged per our documentation since EJBCA 6.5. The plan was to end support of CMP over TCP in the next major version but due to incompatibilities with the Log4J upgrade, we have accelerated the schedule. As of EJBCA 7.9.0, CMP over TCP is no longer supported by EJBCA or by the legacy CMP Proxy. Support for CMP over HTTP is unaffected. 

SaferDailyRollingFileAppender no longer Supported

The SaferDailyRollingFileAppender (enabled by settingocsp.log-safer=true in the ocsp.properties configuration file) has been deprecated and removed due to incompatibilities with the Log4J upgrade. Enabling the setting caused a transaction rollback in case the server logs could not be written to and was a corner case for certain VAs with legal requirements to register all OCSP traffic to log. This setting is no longer supported by EJBCA. 

EJBCA 7.8 Release Notes

EJBCA 7.8.2.1

EJBCA 7.8.2.1 was an internal release, not generally available for customers.

EJBCA 7.8.2

EJBCA 7.8.2 was an internal release, not generally available for customers.

EJBCA 7.8.1

REST API Improvements

ConfigDump over REST

Our ConfigDump tool, used to manage and audit EJBCA configurations through human-readable YAML, can now be accessed over REST, both for export and import. This allows easy use of the ConfigDump tool for the Hardware and Software Appliances, Cloud and other platforms without command-line interface access. 

New REST calls and improvements

• End Entity Search extended with MODIFIED_DATE.
• Added pagination to certificate search endpoint.
• Added a new certificate enrollment endpoint that prioritizes predefined end entity values over values defined in the CSR.
• Added End Entity Profile and Certificate Profile names to the search results of certificate searches.

For more information, see EJBCA REST Interface.

Microsoft Integration

EJBCA Roles can be populated through Azure Active Directory

EJBCA's roles can now have its members populated by corresponding Active Directory Groups through Azure Role Based Authentication (RBAC). What this means is that when using Azure as an OAuth provider for authenticating to EJBCA, role members don't need to be manually populated but can instead be automatically read from existing AD Groups. For more information, see Integrating EJBCA with Azure AD Role Based Authentication (RBAC).

Integration with Microsoft Application Insights

Application Insights is an Application Performance Management (APM) service hosted in the Azure cloud platform that allows DevOps professionals to monitor live applications. By integrating Application Insights and EJBCA, administrators can monitor the performance and availability of their EJBCA servers. For more information, see Integrating EJBCA with Azure Application Insights.

Domain Allow List Validator

By popular request, we've added a companion Domain Allow List Validator to the existing Domain Block List Validator. Performing the exact opposite role, this new validator restricts dnsName field domains to whatever subset is defined. For more information, see Certificate Field Validators.

URIs Added as Name Constraints 

In addition to constraints on DNS Name and IP Address, we've added name constraints for URIs. For more information on name constraints, see CA Fields.

Sunset of ejbca-setup.sh Script

We are sunsetting the ejbca-setup.sh quick installation script and associated documentation to decrease the maintenance load and consolidate the installation paths. If you're currently relying on this script, we recommend you migrate your workflows. 

Basic HTTP Authentication for EST

When using EST in client mode, it's now possible to authenticate over HTTP with username/password. 

Bouncy Castle Upgraded to Version 1.70

Just in time to make this release, we upgraded Bouncy Castle to the latest version. 

Support for Oracle19C

We have implemented support for the Oracle 19C database.

Compliance

Added Granularity to Certificate Transparency Configuration

Due to CT Policy Updates in Apple's Root Program, the configuration of the number of required Signed Certificate Timestamps (SCTs) per time interval has been made fully granular.

Possible to add empty dnsName values and URIs as Name Constraints

As per name constraints discussions in the CA/Browser Forum Validation Working Group, we've added the ability to add an empty DNS name to name constraints. Adding this value constrains a Sub CA from issuing any certificates containing dnsName SAN values. For more information on name constraints, see CA Fields. We've also taken the chance to add URIs as possible Name Constraint values.

EJBCA 7.8.0.3

This maintenance release includes a fix allowing the SCEP configuration field Application API Secret from Azure to contain special characters.

EJBCA 7.8.0.2

EJBCA 7.8.0.2 was an internal EJBCA SaaS specific release

EJBCA 7.8.0.1

EJBCA 7.8.0 was an internal release, not generally available for customers

Transaction Handling for Publishers Improved 

An issue was brought to our attention in regards to transaction handling during publishing operations. The previous behavior was that errors that occur in connection with direct publishing cause an immediate rollback of the entire issuance operation. Normally this behavior is desired, but it has come to light that this may cause compliance issues when also writing pre-certificates to a Certificate Transparency log, due to that action being an "intent to issue".

Transaction handling has thus been improved to ensure that a failure in direct publishing does not lead to a complete rollback, but the certificate is still issued and can be managed accordingly. 

Compliance

CRL and OCSP Validity Compliance

It was brought to our attention by a customer that EJBCA adds a second of validity to CRLs and OCSP replies to what is intended in RFC 5280. This issue has been addressed in EJBCA 7.8.0.1 by reducing the validity of CRLs and OCSP responses by 1 second.

ACME Redirect Ports updated to comply with CA/Browser Forum Baseline Requirements 1.7.6

BR 1.7.6, as defined in SC44, clarified the validity of redirect ports if followed by the CA. It was found that EJBCA follows a 302 status code on port 8080, which is not in the list of approved ports. This has been fixed in EJBCA 7.8.0.

Security Issues 

Audience Claims not required by default 

Upon review of our OAuth implementation, it was found that not requiring the aud claim to be defined provides potential for known users to access EJBCA using a valid claim meant for a different audience. A new field has been added to the OAuth configuration, where the aud claim must be filled in for each defined provider. Upon upgrading, you will be prompted to fill in this field before performing post-upgrade. Two weeks after the release of EJBCA 7.8.0 this issue will be reported as a CVE. 

Severity

• Medium – an attacker would still need to have a valid OAuth token with other claims valid for a defined role, but intended for a different audience. 

EJBCA 7.7 Release Notes

EJBCA 7.7.0

Microsoft Windows Compatible CA Key Updates

Due to some differences in how Microsoft Windows handles CRLs, we've introduced a Microsoft Compatibility mode that changes the CA's behavior when the CA is rekeyed. The commonly expected behavior when a CA is rekeyed, is that all future CRLs and OCSP responder certificates are signed by the new key pair after the rollover. Instead, Microsoft environments expect each generation of CA key pairs to continue signing CRLs for those certificates which were issued by that particular key pair. Likewise, OCSP responses are expected to be continued to be signed with an OCSP responder certificate signed by the original key pair. 

The end result of Microsoft Compatibility mode is that:

• The CA will produce as many CRLs as there are generations of CA keys.
• OCSP responses will have different signing keys, depending on which generation of CA keys signed the relevant certificate.

Microsoft Compatibility mode comes with some caveats:

• It's not possible to switch between the two modes, so Microsoft Compatibility Mode must be enabled upon CA creation if required.
• Microsoft Compatibility Mode is mutually exclusive with the use of Partitioned CRLs.

For more information about EJBCA's Microsoft Compatibility mode, see Microsoft Compatible CA Key Updates.

Approvals in ACME Workflow

Upon popular demand, we have implemented Approvals for the ACME workflow. Configuring Approvals for a CA or Certificate Profiles and enrolling over ACME will now trigger an approval event for the account and subsequent end entity creation. For more information, see ACME.

Azure Blob CRL Publisher

To further increase compatibility with the Microsoft space, we have introduced a CRL publisher to Azure Blob. For more information, see Azure Blob Storage Publisher.

Announcements

Sunset of JDK8 support

With JDK8 seeing the end of its official support window from Oracle, we will towards the end of this year sunset support for JDK8 ourselves to be able to take advantage of the many features in JDK11 and later. We want to recommend all customers to upgrade their JDKs to JDK11. With the coming release of JDK17 as the next LTS release from Oracle, we will be implementing full support towards the autumn. 

EJBCA 7.6 Release Notes

EJBCA 7.6.0

Included in this release are also the changes made in EJBCA 7.5.1, which was only released internally. 

External Account Bindings

Inspired by the concept of External Account Bindings in ACME (supported since EJBCA 7.5), we've extended the concept globally across EJBCA to provide a quick and easy way to link any certificate enrolled via the RA, REST, or ACME with an external identifier, to affiliate certificates to identities.

Subsets of allowed values can be pre-configured in the certificate profiles to ensure that only valid identities can be submitted, as well as providing content assistance in the RA. 

Microsoft Intune Revocation and Other Improvements

Published and documented as recently as May of this year, Microsoft Intune now provides the ability to request revocation of certificates from Azure. EJBCA 7.6.0 has full support for this API in the form of a Service Worker which will periodically poll Azure for new revocation requests.

In addition, the following improvements have been made to our Intune support:

• AD Authentication to Azure can now be made with a certificate instead of a username/password.
• The connection between the CA and Azure can now be piped through an EJBCA RA, doing away with any requirements on the CA to have a direct connection to Azure. 

Microsoft Azure Managed HSM (MHSM)

In addition to supporting Azure Key Vault, EJBCA now supports the new Managed HSM (MHSM) which offers FIPS 140-3 for a higher assurance level to protect your keys in the cloud. Using the same REST API as Key Vault, you can add an MSHM instance as an Azure Key Vault Crypto Token (or several instances as separate crypto tokens).

Testing Baseline raised to JDK11

While JDK11 has been in use for some years among customers, we have internally raised the baseline from JDK8 to JDK11, which is now the recommended JDK to use with EJBCA. We will in the coming months be announcing the sunset of JDK8 support, and are looking forward to supporting JDK17 as soon as it's been released by Oracle. 

Compliance

Compliance with CA/Browser Forum Ballot SC44

CA/Browser Forum ballot SC44 redefined some return codes for ACME, to which EJBCA 7.6.0 is now fully compliant. 

Security

EJBCA 7.6.0 comes with fixes for a few minor security issues, as well as additional security hardening.

General Purpose Custom Publisher able to Run Despite External Scripts Being Disabled

It was found during testing that the General Purpose Custom Publisher, which is normally run to invoke a local script upon a publishing operation, was still able to run if the System Configuration setting Enable External Script Access was disabled. With this setting disabled it's not possible to create new such publishers, but existing publishers would continue to run. Two weeks after the release of EJBCA 7.6.0 this issue will be reported as a CVE. 

Severity

• Low – creating and changing a publisher would still require super admin access to EJBCA, and modifying any existing scripts would require operating system access. 

Enrollment Secrets Logged in Audit Log

When audit logging changes to the alias configurations of various protocols that use an enrollment secret, any modifications to the secret were logged in cleartext in the audit log. Two weeks after the release of EJBCA 7.6.0 this issue will be reported as a CVE. 

Severity

• Low – enrollment secrets are already by definition known among system administrators and only trusted users should have audit log access.

Enrollment Secrets Reflected in UI

As part of the configuration of the aliases for SCEP, CMP, EST, and Auto-enrollment, the enrollment secret was reflected on the page. While hidden from direct view, checking the page source would reveal the secret. Two weeks after the release of EJBCA 7.6.0 this issue will be reported as a CVE. 

Severity

• Low – anybody with access to the configuration page likely has access to the secret as well, and is authorized to change the secret.

CMP Revocation Ignores Multi Tenancy Constraints

CMP RA Mode can be configured to use a known client certificate to authenticate enrolling clients. The same RA client certificate is used for revocation requests as well. While enrollment enforces multi tenancy constraints (by verifying that the client certificate has access to the CA and Profiles being enrolled against), this check was not performed when authenticating revocation operations, allowing a known tenant to revoke a certificate belonging to another tenant.

Severity

• Medium – while not as serious as ignoring multi tenancy constraints for enrollment, this allowed tenants to perform DoS attacks on each other. The attacking party still needed to be a known and trusted entity. 

EJBCA 7.5 Release Notes

EJBCA 7.5.0.1

EJBCA 7.5.0 was an internal release, not generally available for customers

Microsoft Auto-enrollment Integration

Until now PrimeKey has supplied an Auto-enrollment proxy in order to allow customers to integrate single domain Microsoft PKIs with EJBCA as a backend.

From version 7.5, EJBCA now has Microsoft Auto-enrollment support fully integrated, not only transcending the need for a proxy but also eliminating the need for a Certificate Enrollment Policy server or Certificate Enrollment Server, with the EJBCA RA being the point of first contact for enrolling clients. EJBCA 7.5 also allows for multi forest support, letting all your domains integrate into a single PKI through the same endpoint. For more information, see Microsoft Auto-enrollment Overview.

OAuth Authentication to the EJBCA CA and RA UIs and REST API

Moving on from the classic support for client certificates to access the CA and RA UIs, and the REST API, EJBCA 7.5 now supports access using an OAuth provider over OpenID. So far we've tested and confirmed authentication using KeyCloak and Azure Active Directory. 

ACME External Account Bindings

Long requested, we've implemented ACME External Account Bindings in accordance with RFC 8555 section 7.3.4. External Account Bindings allows the client to specify a unique ID number that is associated with that ACME account, and in our implementation we've associated the ID with each issued certificate for easy lookup later. In addition to being able to authenticate the ID using a MAC as per the RFC, we've also allowed for using a signature from a locally issued certificate instead. For more information on managing ACME External Account Bindings in EJBCA, see ACME.

EST Client Mode

We've added Client Mode to EST as with CMP and SCEP. Unlike RA mode, Client Mode only allows issuance against previously created end entities and does not automatically enroll new ones. This workflow is optimal for IOT use cases, where a limited set of devices need to enroll to your PKI. 

HSM support for Ed25519 and support for AWS Cloud HSM

Apart from earlier software support for the signature algorithms Ed25519 and Ed448, support has been added for using Ed25519 with selected HSMs which support Ed25519, starting with nCipher nShield, Thales Luna and SoftHSMv2. This support is only available when using P11-NG Crypto Tokens in EJBCA. In conjunction with this, EJBCA is now fully compatible with the AWS Cloud HSM.

Compliance 

OCSP Support Updated to Conform to RFC 8954

We have updated our OCSP responder to conform with the clarifications specified in RFC 8954, specifically to how EJBCA handles client generated nonces. 

eIDAS Compliance

• Support has been added in the CA UI for easy editing of the new Legislation Country QC Statement as specified in ETSI EN 319 412-5 v2.3.1 section 4.2.4.
• Support for multiple SemanticIdentifier to a single certificate, i.e. to specify both EN 319 412-1 Natural Person and Legal Person at the same time.
• CAs can now be configured to automatically generate a CRL upon revocation.

EJBCA 7.4 Release Notes

EJBCA 7.4.3.3

Intune Support Regression

A library issue was discovered in EJBCA's Intune support, which has now been fixed.

Signing with RSASSA-PSS not working in OpenJDK 8u272/11.0.6 without Java patch

While this issue was believed to be fixed in EJBCA 7.4.3.2, a remaining library issue remained which has now been solved.

EJBCA 7.4.3.2

Vulnerability in underlying Apache Batik Library 

CVE-2019-17566 has been reported for Apache Batik, which constitutes an exploitable vulnerability for EJBCA. EJBCA 7.4.3.2 includes an upgrade of this library to version 1.13, and as this constitutes a vulnerability in EJBCA we will be submitting our own CVE two weeks after the release of this version. 

Upgrade of underlying XStream Library

CVE-2020-26217 has been reported for Xstream, so it has been upgraded as a result. The vulnerability in this library does not constitute a security risk for EJBCA.

Invalid storage of SIM value (RFC4683) in the Subject Alternative Name of a Certificate

As reported to support, EJBCA did not store the SIM Subject Alternative Name value correctly. 

AWS KMS Request Throttling when reading Public Keys results in Unusable Keys

It was found that due to request throttling, AWS KMS crypto tokens with more than five keys were left with some keys unusable. 

Signing with RSASSA-PSS not working in OpenJDK 8u272/11.0.6 without Java patch

It has been reported that a backport to OpenJDK 8u272 broke handling of RSASSA-PSS. To avoid issues we have built around this bug in EJBCA. This bug does not affect Appliance customers, as the PrimeKey Appliance runs a patched version of OpenJDK. 

EJBCA 7.4.3

REST Endpoints for End Entity Management

We've added new commands for end entity management to our REST API with contributions from Roman Cinkais at 3Key Company. If you'd like to try them out, take a look at our Swagger UI which is automatically deployed on non-production instances.  

Plugin for Hashicorp Vault

As part of a greater effort to extend interoperability and a serve as an integral part of any PKI ecosystem, we've released a plugin for Hashicorp Vault on GitHub. HashiCorp Vault is a product to manage secrets and when using microservices at scale, there are many services and secrets to manage. The plugin allows you to use EJBCA instead of the built-in Vault's CA in order to combine the usability and dynamics of the Vault with the compliance, scalability, and performance of EJBCA.

CVC Enrollment in EJBCA RA

It's now possible to enroll for Card Verifiable Certificates in the EJBCA RA UI. This improvement is part of our continued effort to deprecate the old Public Web.

Trident HSM Support

We've added some default properties to our configuration files to allow for easy configuration if the HSM driver is installed on the system.

Root Program Compliance Issues

Two issues have been reported that may cause incidents with CAs that conform to the Browser Root program and CA/Browser-Forum requirements.

1. In previous releases, OCSP responses without extensions were sent with an empty singleExtensions list, while the proper behavior is to omit the list entirely. The issue is now resolved and we recommend that all root program compliant customers upgrade to EJBCA 7.4.3 or later.
2. It has been found that EJBCA does not calculate the time between notBefore and notAfter correctly, adding an extra second to validity of certificates and OCSP responses than intended by the RFC. While we recommend customers to keep well within any required limits, this issue has been solved in EJBCA 7.4.3. 

Security Issue - Domain Security over EST

As a part of our penetration testing, a security issue was found when enrolling with EST while proxied through an RA over the Peers protocol. As a part of EJBCA's domain security model, the peer connector allows the restriction of client certificates (for the RA, not the end user) to a limited set of allowed CAs, thus restricting the accessibility of that RA to the rights it has within a specific role. While this works for other protocols such as CMP, it was found that the EJBCA enrollment over EST implementation bypasses this check, allowing enrollment with a valid client certificate through any functioning and authenticated RA connected to the CA. We consider this issue minor as it does not bypass any of the many other security checks in place, but as per our common policy this issue will be submitted as a CVE two weeks from the release of EJBCA 7.4.3.

EJBCA 7.4.2

CertBot 1.4.0 through 1.6.0 supported

EJBCA support for ACME CertBot was limited to version 1.3.0. From this release, EJBCA also supports versions 1.4.0 through 1.6.0. 

OCSP Responses no longer include Unspecified reason code

Due to changes in the CA/B Forum Baseline Requirements version 1.7.1, effective as of 2020-09-30, the behavior of the VA has been changed so that OCSP responses where the certificate is revoked with the "Unspecified" reason code, the reply will no longer include the reason code attribute.

Additional RDNs allowed in ACME Requests

In our initial implementation of the ACME protocol, only the CN field and dnsName SANs were processed. In order to allow for the issuance of other types of certificates from ACME, we now allow the inclusion of additional fields by enabling Allow subject DN override using CSR in the certificate profile.

EJBCA 7.4.1

Microsoft Intune Device Enrollment

Intune is Microsoft's cloud-based device management solution, and EJBCA can be configured as the CA backend to allow devices to enroll for certificates. Intune support has previously been provided through a 3rd party connector, but from EJBCA 7.4.1 devices can be set up to directly request certificates from the EJBCA RA. This is set up using SCEP aliases, and we provide a guide for setting up your enterprise for Intune Device Enrollment from start to finish. 

Ability to have Multiple DVCAs with the same Holder Country and Mnemonic

In the context of CV certificates, EJBCA has traditionally used the holder mnemonic and requesting country code to build the Subject DN, causing a uniqueness constraint. EJBCA 7.4.1 allows multiple DVCAs to share the same country and mnemonic fields. For more information, see Managing CVC CAs.

Security Issue

As a part of standard testing, we found a minor security issue which has been fixed in this version of EJBCA. When employing a client certificate to authenticate an EST client, we've discovered that no check is performed on the status of this certificate, allowing a revoked client to still request certificates over EST. The vulnerability only affects EST, and can be mitigated by removing the affected client certificate from the roles which allows it to perform enrollments. This vulnerability will be published as a CVE two weeks following the release of EJBCA 7.4.1 and the distribution of security announcements to customers. 

EJBCA 7.4.0

Pre-produced OCSP Responses 

A commonly requested feature through the years, the EJBCA VA can now produce pre-produced OCSP responses in accordance with RFC6960. This feature has two potential benefits for your VA infrastructure - it allows you to pre-sign OCSP responses during low times for use during peaks, and CAs under requirement to do so can be set to produce responses valid after the CA's expiration.

Ed25519 and Ed448 Support

EdDSA is now supported for software crypto tokens, with support for both Ed25519 and Ed448.

Approvals added to SCEP

When using SCEP in RA mode, it's now possible to use approvals during enrollment.

Google Safe Browsing Validator

We've added a new validator type to check against the Google Safe Browsing API.

Cloud PKI Support

EJBCA 7.4.0 has added encryption for SCEP with Azure Key Vaults and support for AWS Key Management Service (KMS).

EJBCA 7.3 Release Notes

EJBCA 7.3.1.4

This patch release fixes regressions that were discovered as a result of the security fixes done in EJBCA 7.3.1.2.

Upgrade Information

Review the EJBCA 7.3.1.4 Upgrade Notes for important information about this release.

EJBCA 7.3.1.3

This maintenance release contains a fix for Elliptic Curve (EC) keys wrongly being generated with explicit EC parameters by default while using the "P11NG" provider. The issue only affects users of the EJBCA eIDAS edition.

EJBCA 7.3.1.2

This maintenance release resolves several vulnerabilities found in EJBCA during penetration testing, and we recommend that all customers upgrade their installations if they are affected and cannot otherwise mitigate.

EJBCA 7.3.1.1

This maintenance release fixes a security issue when SCEP enrollment is used.

EJBCA 7.3.1

View Queued Publisher Item Information

Items published with a publisher in EJBCA can be placed in a queue if direct publishing fails or because the publisher is configured to only use a queue for publishing.

The Publisher Queue Status table on the EJBCA CA Web home page has up until now only listed the number of queued events per publisher. Under certain circumstances, entries in the queue may not be able to publish for example, due to a network outage or denied authorization from the target.

As of EJBCA 7.3.1, you can view status information about the queued events indicating why they are still queued, information on the latest updates and links to the relevant object. For more information, see CA Operations Guide.

Persistence of Precertificate

Following a discussion in the mozilla.dev.security.policy group it has been determined that CAs using Certificate Transparency (typically applicable for public CAs) should be able to respond with proper status for CT precertificates. EJBCA has previously been able to partly do this by having the OCSP reply 'good' for non-existing certificates. However, this doesn't entirely meet the new requirements.

With EJBCA 7.3.1, precertificates will be stored in the database and published to configured VA databases. This allows for better control, history, and most importantly, OCSP lookup for precertificates. Specifically in cases where a precertificate has been generated and no final certificate was issued, which for example may occur if an insufficient number of signed certificate timestamps (SCTs) were received from the configured CT logs.

For more information, see Persisting Precertificates and OCSP in Certificate Transparency.

EJBCA 7.3.0

ACME RFC Support

Up until now, EJBCA has supported IETF draft 12 of ACME. As of March 2019, IETF standardized the ACME protocol as RFC 8555. We are happy to announce that EJBCA now complies with the RFC standard. Having the standardized protocol supported will facilitate usage from an integration point of view as more ACME clients will work "out of the box" and the uncertainty whether the protocol will change again in the future is mitigated.

For a complete list of supported ACME operations and workflow examples, see the latest EJBCA ACME documentation.

ConfigDump Import

You may be familiar with our ConfigDump export tool, used for exporting the current state of your installation in a human-readable (YAML) format. The export tool is useful for auditing purposes and comparing configuration changes made in EJBCA.

The new ConfigDump import feature enables the reversed functionality, importing parts of or a complete configuration from an existing configuration dump.

The provided CLI tool allows you to target a configuration for import into EJBCA whether it contains a set of profiles, CAs, a complete configuration, or any other previously exported object. Since the configuration dump itself is human-readable, you can edit the fields in each object (for example, change the subject DN of an end entity profile) before import.

For more information on using the tool, see the ConfigDump documentation.

OCSP Archive Cutoff

The OCSP archive cutoff extension (RFC 6960 section 4.4.4.) was previously configured per EJBCA instance in ocsp.properties, by setting the property ocsp.expiredcert.retentionperiod to the retention period in seconds.

This setting is now configured per CA, by editing the corresponding OCSP key binding. This allows for different archive cutoff settings being used for different CAs. We have also added a setting to base the archive cutoff date on the issuer's notBefore date (instead of the retention period and the producedAt date of the OCSP response) as mandated by ETSI EN 319 411-2, CSS-6.3.10-08.

For more information, see Archive Cutoff and for important notes to be aware of when upgrading, see EJBCA 7.3 Upgrade Notes.

Certificate Transparency Sharding

It is now also possible to define a validity interval accepted by Certificate Transparency (CT) log servers. The new setting allows limiting the scope of acceptable certificates to a date range and is configured in the CA Web, under System Configuration > Certificate Transparency Logs, by editing an existing CT log.

For more information on Sharded CT logs, see Certificate Transparency.

Azure Key Vault Crypto Token

Microsoft Azure provides a cloud "Key Vault" for HSM storage of cryptographic keys. As of EJBCA 7.3.0, Azure Key Vault can be set up as a Crypto Token in EJBCA, leveraging the advantages of cloud-stored keys. For detailed information and configuration instructions, see the EJBCA Cloud Documentation.

EJBCA 7.2 Release Notes

EJBCA 7.2.1.1

This patch release contains fixes for two issues:

1. An issue that prevented upgrades from 7.1.x and older when using database protection.
2. An error when EST name generation was set to USERNAME.

EJBCA 7.2.1

AWS S3 Publisher

The AWS S3 (Amazon Simple Storage Service) Publisher allows for publishing certificates and CRL files to an AWS S3 bucket.

The publisher uses the AWS CLI to perform the S3 bucket operations. The AWS CLI is installed by default on the AWS EJBCA Cloud instance, and may be installed separately on other EJBCA software installations.

You will find it among the other Publisher types in EJBCA Admin Web. For more information regarding the AWS S3 Publisher, refer to the EJBCA Cloud documentation.

EST Name Generation Enhancements

Up until now, End Entity username has been randomly generated for every 'simpleenroll' request using EST, making certificate life cycle management slightly challenging using the protocol. This has been addressed by introducing a configurable name generation scheme for EST, similar to how CMP aliases can be configured. The name generation scheme may be configured as follows:

• DN: Use the desired part of DN (CN, SN etc.) from the CSR as End Entity username.
• RANDOM: Generates a random username for each request. (Default behavior. Enforced in previous versions of EJBCA).
• FIXED: Username pre-defined for all requests using the EST alias.
• USERNAME: Uses entire request DN as End Entity username.

Renewal

End Entity username can now be determined using EST, an authenticated 'simpleenroll' request matching an already existing username (e.g. CN part of DN) and will be treated as certificate renewal. Requests matching an existing End Entity will result in a new certificate issued for it.

For more information, see EST.

IPv6 Support

Though EJBCA has supported IPv6 up until now, there has been a few limitations to it. As of EJBCA 7.2.1, IPv6 has been thoroughly tested and improved for certain use cases.

EJBCA 7.2.0

Persistent Storage of Certificate Transparency SCT Responses

Persistent caching of Certificate Transparency SCTs (Signed Certificate Timestamps), in the form of a database-backed storage, has been added in addition to the existing in-memory caching. This reduces the number of requests to the CT log server and increases the performance. Additionally, the default configuration was changed to rate-limit connections to logs that are down or return error codes. This reduces the load on both log servers and EJBCA. For example, if a CT log rate-limits EJBCA, then EJBCA will back off for 1 second by default. For more information, see Certificate Transparency.

Crypto Token and CA Management REST API

The EJBCA REST API has so far been limited to Certificate Management operations. We've now extended the REST API, adding resources for CA administration as well. This allows simpler remote integration and management as an option to the GUI.

The new endpoints are disabled by default, requiring activation via Protocol Configuration before use. For more details and endpoint documentation, see EJBCA REST Interface.

EJBCA 7.1 Release Notes

EJBCA 7.1.0

Partitioned CRLs

Long and enduringly requested, EJBCA 7.1 is now capable of producing partitioned CRLs. Activated under the CA configuration, the number of partitions per CRL is dynamically configurable, allowing new partitions to be added as the CRL grows, and assignment to older partitions to be suspended in order to allow for future growth. CDP partition assignment is random in order to allow for even distribution of certificates, and partition definition can be looked up in the CDP extension as defined in RFC5280.

For those of you not wishing to use partitioned CRLs life will mostly move on as usual while for those of you applying partitioned CRLs to existing installations you will retain a legacy CRL for pre-existing certificates (as the CDP can't be changed retroactively) while newly issued certificates will be issued to partitions. 

Deprecation and Removal of Hard Token Support

In an effort to relieve ourselves of maintaining little-used features we have chosen in this release to deprecate and remove support of hard tokens, after analyzing that it has little to no use among PrimeKey customers. Naturally this will have no impact on existing installations, but we have provided scripts for those of you wishing to remove the relevant tables from the database. See the upgrade notes for more details.

VA and RA Specific Distributions 

As a response to market interest, we've enhanced our build process and modularization in order to produce VA and RA specific builds of EJBCA, each capable of acting in their specific roles but not as a CA. This allows PrimeKey to offer a more dynamic model for Appliance and Cloud users who would like to add RA and VA instances to their PKIs but find it prohibitive to pay for the full fee for the complete distribution. The standard CA distribution still retains the full VA and RA capabilities as before. If you're interested in finding out more, please contact sales@primekey.com 

EJBCA 6.15.2 CE Available on Docker Hub

As some of you already know, as part of our ongoing containerization project we've added a docker container to Docker Hub, built on a sneak-peek of the coming release of EJBCA 6.15.2 Community Edition.

If you're interested in moving your PKI towards containerization, please go ahead and have a look, and feel free to give us any feedback!

EJBCA 7.0 Release Notes

EJBCA 7.0.1

Full PSD2 Support

EJBCA 7.0.1 provides full support for the Payment Services Directive as defined by EU Directive 2015/2366. PSD2 allows eIDAS Trusted Certificate Providers to issue PSD2 QWAC certificates to third party FinTech companies, which in turn gives them access to financial APIs hosted by European banks. To enable PSD2 in your instance of EJBCA, scroll down to the QC Statements extension of your certificate profile and enable the PSD2 option. When enabled, three PSD2 fields will be made in the RA UI during enrollment.

For more information about PSD2, refer to our blog post about it on the PrimeKey's blog and our own development blog.  

Domain Blacklist Validator

We've implemented a Domain Blacklist Validator. The new Validator takes a list of partial and complete domain names, and can be configured to either block them outright (if run during the data phase) or cause an approval action to be triggered in the final approval step (if approvals are activated). All of the approving RA administrators in the final approval step will be shown a warning before the approval passes.

dnsName SAN can be Automatically Populated by the CN

We've added a setting to End Entity Profiles to allow the dnsName Subject Alternative Name field in a certificate to be filled in by the Common Name (CN) value in the Subject DN.

Configurable SN Entropy, Default Value Raised to 20 Octets

CA/B Forum requires the use of 64 bit entropy when generating serial numbers (see CABF Ballot 164[external link]). Due to only positive values being valid serial numbers, 8 octets will only result in 63 bit entropy as the most-significant-bit will always be 0, hence we recommend larger sizes than 8 octets. Previously this was set using the property ca.serialnumberoctetsize in cesecore.properties, which has now been dropped and the value is instead set directly in the CA.

Possible values may range between 4 and 20 octets, and the default for all new CAs is 20 while upgraded CA's will retain whatever value was set in ca.serialnumberoctetsize, or 8 if none was set. 

Downloadable CSRs

In EJBCA 7.0.1 we've started storing CSRs along with the associated certificate (instead of only the last submitted CSR as it was earlier), so you now have access to download and review all CSRs submitted and processed in the past. 

URL Metadata Type Added to Approvals

We've added a URL metadata type to the partitioned approval profiles. It allows the approving RA administrator to enter a URL while performing the approval, e.g pointing to a file upload at an external location.

Upon later review of the approval, the specified External URL will show up as a hyperlink.

Experimental: Configuration Checker

Lastly, we're trying out an experimental new feature in EJBCA 7.0.1, the Configuration Checker. It displays an (incomplete) list of common configuration issues on the front page. 

If you'd like to try it out, it can be activated in its own tab under the System Configuration.

Appliance Release

EJBCA 7.0.1 will be available on Appliance 3.3.0, due at the end of March/beginning of April.

EJBCA 7.0.0

Technology Leap to JDK8/JEE7

Probably the most impactful change of upgrading to EJBCA 7 is that we're dropping support of JDK7, and by extension JEE6 reliant application servers. In essence, from here on in that means that the minimum supported application server is JBoss EAP7/Wildfly 10. If your current installation is running on an earlier JDK or application server we recommend upgrading those first, going through an intermediate release of EJBCA if necessary. The EJBCA Upgrade guide has detailed instructions for which workflow to follow if this applies to you. 

This leap is partly motivated by the end of professional support for JDK7 from Oracle coming this summer, but also because it both allows us to upgrade older libraries (which have long since ceased receiving security updates) and to be able to make use of much of the newer technology which has been developed in the intervening years in order to improve your user experience. 

JDK11 Support

While not completely tried and tested yet, we've begun implementing support for JDK11, and have it working in our test environment. For production environments, we recommend sticking to JDK8 for the time being, but for the adventurous among you, we would by all means appreciate any feedback. 

Appliance Release

EJBCA 7 (or a later minor release) will be included in Appliance version 3.3.0 and is scheduled towards the end of Q1. 

EJBCA 6.15 Release Notes

EJBCA 6.15.1

Multi Group Publishing 

 In order to facilitate for users administrating large numbers of publishers referenced in multiple certificate profiles, we've implemented the Multi Group Publisher. 

By referencing Multi Group Publishers instead of the affected publishers directly, actions such as adding or removing VAs can quickly permeate throughout all affected certificate profiles. The publisher also allows splitting referenced publishers into groups, which establishes parallel publishing queues. 

SCP Publishing and VA Population

Due to popular demand for an alternative to the Peer Publisher in environments where establishing a Peer Connection between CA and VA isn't an option, we've created the SCP Publisher, which publishes certificates and CRLs to a remote location over SCP.

Conversely, in order to import certificates and CRLs exported by the SCP Publisher a VA, we've implemented the Certificate and CRL Reader Service. 

GDPR Adapted Legacy VA Publisher

Just like we did for the Peer VA Publisher back in EJBCA 6.13, we've GDPR adapted the Legacy VA Publisher.

By enabling the new Don't store certificate meta data option at the bottom, VA publishing can be performed without writing any identifying information to the VA. 

Revocation Time added to CertSafe Publisher

The output of the CertSafe Publisher has been amended to include revocation time. 

EJBCA 6.15.0

Version 6 of EJBCA is beginning to near its end, and the team are looking forward with great anticipation to be able to give you all a look at what's coming with EJBCA 7. That said, we're sending off the last feature release of EJBCA 6 with a helluva bang: full support for the ACME REST protocol!

ACME Support

Nearly done by the release of 6.14 but not quite there, EJBCA 6.15's main feature is our support for the ACME protocol, up unto and including all mandatory features in draft 12. Naturally we've implemented it with full support for proxying communications over Peers through our RA, and support for multiple configurations using aliases as we do with other protocols.

Our implementation has been verified against Certbot, PJAC and ACME Tiny, and our ACME documentation describes how to configure them. 

Wildcards for Custom Certificate Extensions 

We've added two minor features to Custom Certificate Extensions. Firstly, we've added wildcards (identified by an '*') to the OID field, which allows a defined extension to match against any array of extensions defined in an incoming request (e.g. in the above example, any request containing an extension ending in .123. The second addition is the Required property, which is by default checked. Unchecking this property makes an extension available to be requested in the enrollment request but not necessary.

EJBCA 6.14 Release Notes

EJBCA 6.14.1

This minor EJBCA 6.14.1 release primarily fixes some issues that some users reported when running EJBCA 6.14 on JBoss 7.1.1GA, due to some race conditions and library collisions in that particular version that didn't come up during testing. We also took the chance to fix some other minor issues that came up late during QA that we believe should hold you over for the time being. For a full list of new features and implemented improvements in EJBCA 6.14, see the EJBCA 6.14 Release Notes.

EJBCA 6.14.0

It's with no small amount of pride that we'd like to announce the release of EJBCA 6.14, one of the most feature rich releases to come out in a long while.

The Certificate Management REST API

A long requested and requested feature is for EJBCA to support a spick and span new REST API, and EJBCA 6.14 introduces the first iteration of our Certificate Management REST Interface.

So far we've only implemented basic certificate management methods, and we'll be slowly moving on with implementing more powerful features in the near future. You'll find the complete offline API as a part of our documentation here, or deployed locally with your EJBCA installation. For those of you wishing to integrate with EJBCA using REST we deploy Swagger on non-production installations in order to expose the API. Just like with all new protocols added to EJBCA, the REST API is disabled by default and needs to be manually activated.

Complete Proxification of the EJBCA Web Services API 

A huge milestone for the EJBCA, we put in a huge effort into providing proxification for nearly all EJBCA WS calls. This means that CAs relying on communication with 3rd party applications can now be placed behind an outgoing-only firewall, with communications being relayed through an EJBCA RA.

EJBCA 6.13 Release Notes

EJBCA 6.13.0

What now, another feature release so soon? Fear not, all is well  - instead we felt that some of the work we've put in to the trunk should be made available as soon as possible.

We hope that as many of you as possible have had a chance to check out the ConfigDump tool we released with EJBCA 6.12, please give us any available feedback that we can plug in to future versions.

The EJBCA VA is GDPR Ready

We've added an option to the VA Peer Publisher restrict publishing identifying certificate metadata from the CA to VA, such as subject DN, SAN or usernames. 

Key Ceremony Utilities added to the RA Web 

During key ceremonies, auditors typically require a copy of all CA Certificate fingerprints. To spare you the process of downloading CA certificates and computing the fingerprints manually using a third-party tool, we've added the following functionality to the RA Web:

• Download Fingerprints: Downloads a YAML text document with the CA Certificate fingerprints of all CAs you have access to.
• Download Certificate Bundle: Downloads a compressed zip file containing the CA certificates of all CAs you have access to.

For more information, see RA Web CA Certificates and CRLs.

EJBCA 6.12 Release Notes

EJBCA 6.12.0

The PrimeKey EJBCA team is pleased to announce the feature release EJBCA 6.12, and a small step but important step forward in the development of EJBCA.

Revamped Documentation

We have shifted the documentation over to Confluence instead of the ancient xdoc format as a first step towards a far more organized, updated and user friendly documentation.

Major changes to take notice to are that the Release Notes (this document), Change Log and Upgrade Notes have all been moved in here as well. They're still available offline from within the doc folder in the release zip, but are now also published both online and deployed with EJBCA to the application server.

Configurable OCSP Extensions

The OCSP Extensions configuration is now configured in the UI instead of in the ocsp.properties configuration file, and is set up to act per keybinding. Any existing extensions defined in the configuration files will automatically be added to existing OCSP keybinding configurations, but please read more about that and more in the EJBCA 6.12 Upgrade Notes.

ConfigDump Export and Audit Tool

Our StateDump tool for exporting and importing installations has been remade from the ground up, and the first iteration of the tool is now publicly available. The new ConfigDump Export and Audit tool is useful for change handling and auditing and is built and run from the command line using ant configdump.

The export files are sorted by type and are serialized and normalized as yaml objects. Any UID references are replaced with their human-readable names.

Additional Proxying Capabilities in the RA

As response to external demand, we've added two new features to the RA:

1. The ability to proxy SCEP requests, much as is done with CMP and EST already 
2. We added forwarding of revocation and revocation status requests over SOAP. The full list of methods in the EJBCA WS that can be proxied via the RA are:

• certificateRequest

• checkRevokationStatus

• getLastCertChain

• keyRecover

• keyRecoverEnroll

• revokeCert

EJBCA 6.11 Release Notes

EJBCA 6.11.1

Now is the winter of our new content, made glorious summer by our developers' hard work. EJBCA 6.11.1 is a brand new minor release containing some cool new features. We've upgraded the underlying BouncyCastle library version 1.59, which adds support for SHA3 signature algorithms.

The main feature of this release is a modification of how vendor certificates are handled in CMP. Previously we restricted CMP clients to enroll to the same subject DN and issuer as specified in the vendor certificate, while we now allow enrolling to a number of different certificates based on the same vendor certificate. The purpose of this change is to be able to use the same vendor certificate to enroll a device with several keys with different purposes.

We've fixed a few neat bugs, amongst which being a performance sink in the display of crypto tokens in the CA GUI, some minor issues related to EST and a case where a CA might incorrectly fail a CAA issuance check for some corner cases.

Being a minor release, this release involves no upgrade steps or notable database changes.

EJBCA 6.11.0.1

Patch release with some last minute fixes before the release of Appliance 2.7.2. Found issues include:

• A couple of minor regressions in relation to handling Approval Profiles in the CA and RA GUIs
• Improved re-authentication checks in the CA and RA GUIs
• Allowing the EC Key Validator to pass keys encoded with algorithm name "EC", as well as "ECDSA"

EJBCA 6.11.0

First and foremost, EJBCA 6.11 introduces a long awaited feature: support for the EST protocol. For those of you now in the know, EST is an enrollment protocol similar to SCEP. Much like CMP and SCEP, EST can be configured through multiple aliases, and can like CMP also have calls proxied from an RA up a CA using the Peers Protocol.

The second main feature of this release is the concept of External Validators, a feature which has been widely requested by quite a few of our enterprise users. An External Validator functions much like the existing validators (RSA, CAA, etc), but it runs on either a certificate or pre-certificate object and calls on local script on the local system.

We've also added a few of features to make VA/RA installations more secure in the DMZ. In order to guard against possible 0-days or protocol vulnerabilities we've added the Protocol Configuration-tab to System Configuration. Through this tab all incoming protocols or servlets can be disabled. Additionally, we've added access rules to allow prohibiting CMP and WS calls being sent from the RA/VA to the CA via Peers in case the RA/VA runs the risk of being compromised. The second security feature is connected to the External Validator, adding a configuration value under System Configuration that disables both it and the General Purpose Custom Publisher. This configuration value is set to be disabled by default unless you're currently running a GeneralPurpose Custom Publisher in your installation.

Lastly, we've updated the VA so that SHA1WithRSA and SHA1WithECDSA are no longer acceptable signature algorithms for an OCSP responder, see the UPGRADE document for more information.

EJBCA 6.10 Release Notes

EJBCA 6.10.1.1

Patch release for ECA-6426, in which the database version was set incorrectly for fresh installations.

EJBCA 6.10.1

This minor release introduces a couple of cool new features and above all a big performance improvement. We've added certificate extensions to CV certificates; these can be managed just like standard custom certificate extensions under System Configuration.

We've made a big change to how we handle CT logs. In 6.10.0 we added the option to make certain logs mandatory in anticipation to Google's enforcement of their updated CT specification in April 2018. Looking back we weren't entirely satisfied with our design, so have instead introduced the concept of CT Log Labels in order to group sets of logs. Instead of choosing a series of logs in the Certificate Profile you may choose a series of labels. Upon issuance all logs from those labels will be queried to, and the first n SCTs will be written to the certificate, where n is the max number of SCTs allowed and there will be at least one SCT per label. For those of you using the 'Mandatory'-option since 6.10, your logs will be automatically upgraded, which is documented further in the UPGRADE document.

Speaking of upgrading, you may have caught the EJBCA 6.3.2.6 Intermediate Release issued recently in order to facilitate upgrades from versions of EJBCA earlier than 5.0. In this release we've ironed out the last remaining upgrade bugs, as well as forbidding upgrades from versions of EJBCA prior to 5.0 in order to avoid errors in the future.

Lastly, we've put some time into optimizing certificate issuance in EJBCA. In comparison to 6.10, EJBCA 6.10.1 has about twice the throughput and half the latency in our benchmark environment for high volumes of certificate issuance.

EJBCA 6.10.0.2/6.10.0.3

Patch release covering one issue where an issuewild record on a DNS would cause checks for non-wildcard domains to fail.

EJBCA 6.10.0.1

This patch release fixes several corner cases in CAA issuing, a regression in the CMP Proxy where we forgot to update the name of an upgraded library, as well as a minor regression where a newly created Role doesn't show up as 'Custom' by default.

EJBCA 6.10.0

Happy Halloween to all, we the Plucky Khobolds of PKI have been toiling away at another release.

Speaking of costumes and dressing up, EJBCA 6.10 introduces an extremely neat feature to the RA web: not only the ability to upload custom stylesheets and logos on the CA web to be used in the RA, and not only setting these per role, but having these transmitted to a remote RA over the Peers protocol. This means that the look-and-feel of an RA placed in an entirely different country than the CA can be modified CA-side without even requiring a restart of the RA, and it can be done for multiple users depending on their role.

On the theme of scares and frights, we're sure that nobody missed the ROCA vulnerability that was made public this month. While EJBCA has never used Infineon libraries for key generation (and to the best of our knowledge, none of our supported HSM vendors do either), we've still been capable of signing weak keys submitted from other sources. Fortunately since we introduced the RSA Key Validator back in EJBCA 6.9, adding a ROCA check there as well was trivial. For those of you running or planning on running RSA Key validation, we strongly recommend activating checking for ROCA weak keys.

On the CMP side we've added the concept of Central Key Generation which allows for a request for a keypair generated CA side to be transmitted and returned over CMP. Certificate Transparency has been given the ability to specify, apart from the minimum number of required logs, which logs which are considered mandatory to write to - this in anticipation of new requirements from Chrome coming in 2018. We've also kept working on our CAA validator, hammering out various corner cases and parallelizing DNS lookups for certificates containing multiple DNSNames.

From an upgrade perspective we're happy to see many legacy installations (EJBCA 4.0 and older) beginning to upgrade towards more modern versions of EJBCA, and have received some bug reports specific to older deployments which we've fixed in this release. Currently we support upgrading directly from EJBCA 5.0.16 or later. EJBCA 6.10 introduces no database changes, so upgrading from 6.9.x doesn't involve any automatic or manual upgrade steps.

EJBCA 6.9 Release Notes

EJBCA 6.9.1

For the first time in a while we're releasing a standard minor release, mainly concentrating on bug fixes and feedback from implements of our CAA Validator. All in all we've made the CAA Validator far more configurable, allowing features such as whitelisting some domains (excluding them from CAA checks), allowing the validator to ignore specific Top Level Domains and making recursion depth configurable. We've also added caching and robustness to DNS lookups in order to deal with the results query throttling from the resolvers. Add to that, we've also included a couple of minor performance improvements in connection to certificate issuance.

As the CAA standard is still involving we're not counting on our work in this field being finished quite yet, but for the moment we're hoping that you're all looking forward to all the neat new features coming in EJBCA 6.10 in a few weeks.

EJBCA 6.9.0.6

Patch release fixing issues with CAA.

EJBCA 6.9.0.5

Patch release for ECA-6107, which fixed an issue in which CAA lookups weren't properly handled for wildcarded domains with subdomains.

EJBCA 6.9.0.4

Patch release for ECA-6106, which allows a CAA lookup to continue up the domain tree even if the lookup for a subdomain failed.

EJBCA 6.9.0.3

Patch release for ECA-6099, where adding an EE from the Admin Web or WS and then enrolling using the RA would lead to an NPE.

EJBCA 6.9.0.2

Database creation scripts referred to PublicKeyBlacklistData instead of BlacklistData.

EJBCA 6.9.0.1

In the final stages of testing of 6.9.0 we found ECA-6088, which could potentially lead to caching issues for installations running clusters. Was fixed before EJBCA 6.9.0 was released to the wild.

EJBCA 6.9.0

Greetings to all, and welcome back after a long summer. Just in time for CAA to go live on September 8th, we'd like to present to you all the release of EJBCA 6.9.0. All in all we've fixes about 90 issues during the summer, but we'd like to highlight the four major features of this release:

• Delegated Keypair Generation: As requested by some customers running EJBCA instances as RAs over Peers, this feature is similar to the key recovery feature long used in EJBCA in that it stores generated soft keys encrypted in the database, but with the purpose that the soft keys are generated on the RA (instead of on the CA). The purpose of this is security - where the owner of the RA doesn't wish for the keys to ever be transmitted to the CA but merely be signed. Since this feature requires an EJBCA instance running as RA, it only applies to Enterprise customers.

• RSA/ECC Key Validation: A long requested feature, we've now created an API for running validators during certificate creation. Foremost we've implemented Key Validators, which can be applied to a CA to reject incoming signing requests based on inadequate key length or poorly chosen exponents.

• BlackList Validators: We've also developed an API for blacklisting signing requests based on known information. In EJBCA 6.9.0 we've implemented a Key Blacklist Validator, which will check incoming certificate requests against a user defined blacklist of known bad keys.

• CAA: Last and absolutely not least, EJBCA 6.9.0 can perform CAA checks during or after certificate issuance. This has partly been implemented as a Validator (which is run during certificate issuance) or as a manual CLI tool which can be used by an RA administrator after issuance. CAA support is an Enterprise only feature.

EJBCA 6.8 Release Notes

EJBCA 6.8.0.1

This is a patch release for ECA-6056, where Certificate Profiles using Approval Profiles would cease working if database protection was activated for the CertificateProfileData table.

EJBCA 6.8.0

Just in time for the Swedish summer (all three days of it), we here at PrimeKey Solutions are very proud to release EJBCA 6.8.0, with a bunch of new features that we sincerely hope you'll enjoy. All in all, 190 issues that have been fixed for this release.

First and foremost, we've made some changes to Roles and Access Rules (see the UPGRADE document for technical details). Among these changes and improvements, we'd like to highlight the following:

• Managing rules in the Admin UI has been simplified, with a simpler Allow/Deny/Inherit-from-previous structure that we feel is way more intuitive and easy to overview. Rules are now normalized, meaning that when saved the rule set is simplified to the most simple common structure.

• The Advanced Rules page now has an Summary screen, which displays only the set rules for a Role

• Setting Role Members has been simplified. Match Operators have been hard coded for different value types in order to make the process less error prone.

• We have introduced the concept of Role Namespaces, allowing administrators to sort Roles into groups. An logged in administrator may thus only see the Roles in the namespace in which they themselves belong, while being a member of a Role belonging to the "blank" namespace gives access to all. The purpose of this is to allow several different organizational units to be using their own CA, each creating their own Roles with similar names, but without interfering with each other.

• Last but not least, roles management has been built into the EJBCA RA as well, allowing RA users working on a proxy RA to administrate their own roles without needing access to the CA.

Speaking of the EJBCA RA, we have added API calls for proxying CMP requests and a limited subset of the WS interface to it. This allows the RA to act as a proxy for both CMP calls far more efficiently than the old asynchronous CMP Proxy, as well as act as a proxy for the MS Autoenrollment Gateway which was released with EJBCA 6.7.0.

Approval profiles in CAs and Certificate Profiles can now be set per action, allowing one approval profile to be used for e.g. Adding/Editing end entities and another for revoking.

Some passwords can be configured to be stored in an encrypted form in the database. From EJBCA 6.8.0 and on encryption can be configured with a stronger setting than the default by modifying the password.encryption.key in cesecore.properties. Only change this value when you are sure that all nodes that will store passwords (end entity clear text passwords and crypto token auto activation codes) are upgraded and can read the new format.

EJBCA 6.7 Release Notes

EJBCA 6.7.0.1

This is a patch release for ECA-5853, where upgrade to 6.7.0 from certain versions of EJBCA failed due to an NullPointerException in Certificate Profiles.

EJBCA 6.7.0

We are pleased to release EJBCA 6.7.0. This release adds official support for MS Autoenrollment, implemented as an enrollment Proxy/Gateway, which is delivered as a separate component. In addition to this, there are many security fixes and enhancements in this release, plugging a few holes and making it harder than ever to misuse EJBCA. All in all, 82 issues that have been fixed for this release The most notable changes are:

Features

• Native Windows Autoenrollment, using a separate autoenrollment proxy component.
• Support for CT logs that use RSA instead of ECC.
• Ability to search for approval requests in the new RA interface.
• Ability to limit which Extension OIDs are acceptable to Override, gives better control over RAs.

Improvements

• Ordering of configured CT logs is now kept, and there is a possibility to re-order them.
• Additional security hardening, including updated library dependencies.
• Not requiring '@' in rfc822Name improves integration with Cisco ISE.
• Allowing native CAs to be Vendor CAs for CMP testing.
• A new field for "Default CA issuer URI" in the CA configuration makes some use cases more efficient.

Bug Fixes

• Security fixes
• Lots of minor usability issues fixed.

EJBCA 6.6 Release Notes

EJBCA 6.6.4

This release of EJBCA fixes two issues related to upgrades in specific cases.

EJBCA 6.6.3

PrimeKey Solutions is very proud to present the final EJBCA release for 2016: EJBCA 6.6.3. This release fixes nine minor issues which we were dying to make live before our next feature release due for Q1, and primarily fixes issues which cropped up when using ExternalRA since 6.6.0, a bug in the upgrade script for Oracle databases and a bug which caused an inability to create CRLs on MSSQL.

As with all minor releases, no upgrade steps are required.

EJBCA 6.6.2

This release of EJBCA fixes one single issue to improve stability of submissions for Certificate Transparency logs.

This feature is only related to issuance of publicly trusted TLS certificates.

Bugfixes:

• CT Log submission could fail in certain circumstances when it should not

EJBCA 6.6.1

The first patch release in the 6.6 branch, EJBCA 6.6.1 brings a few bugfixes and several improvements, both in functionality and in performance.

The most notable changes are:

Features

• New features related to Validity. You can now configure certificate validity down to minutes and seconds, and certificate start offset which was previously default to -10 minutes is now configurable. There are many new options related to validity, check the documentation.
• Certificate expiration can now be configured to prevent expiration on specific week days.
• Added an option to keep expired certificates on the CRL instead of removing them, which is the default and still recommended behavior.
• Added a new CLI command to change crypto token for a CA.

Improvements

• When CA certificates are revoked, OCSP responder will respond revoked for leaf certificates only if CA revocation reason indicates a CA compromise (from EJBCA 6.5.4).
• Several performance optimizations has been done to boost issuing speed.
• You can now add multiple PDS URIs in the Admin GUI, for Qualified Certificate statement
• EJB timers are now non-persistent, no need to clean JBoss timer directory on restart anymore.

Bugfixes

• CT log timeout are configurable again
• Legacy OCSP signer renewal is now prevented from from processing the same entry twice
• Prevent change, triggered by changing hostname while running, of audit log node id once sequence is initialized
• Updates to imported CA certificates is now persisted properly in the CertificateData table.

Documentation

• Updated Quick Start documentation

EJBCA 6.6.0

PrimeKey Solutions is very pleased to release EJBCA 6.6.0. Being the release with the most number of issue fixed ever, this release of EJBCA 6.6.0 adds a completely new RA architecture, including a brand new RA GUI.

Together with all other improvements, bugfixes and security enhancements, this is a leap forward for EJBCA and many man years of work has gone into making this release.

• New RA GUI with configurable approval work-flow and administrator edit capabilities.
• The RA can work as an integrated RA or as a standalone external RA (EJBCA Enterprise only subject to separate license).
• Running as an External RA there are only outgoing network connections from the CA, using Peer Connectors.
• User friendly Certificate search in the new RA GUI with free text search on both subject DN and altName (see note below regarding altName search).
• Location based access control for the new RA, different RAs can have different access combined with the administrators access.
• Easy to configure user and administrator privileges for the RA during the Peer Connector setup.
• Full GUI support for the new eIDAS standard (QC statement extension in certificates)
• Completely reworked Approvals with multiple approvals, ordered or not, with flexible approval notifications.
• Support for RegisteredID (rfc5280), xmppName (rfc6120) and srvName (rfc4985) subject alternative names.
• Now allows longer subject DN and altName by default in new installations.
• Additional CVC OIDs for SHA512 and SHA384
• Add support for Services that run on all hosts to enable HSM Keepalive Service to run on all nodes in a cluster
• Additional security hardening and improvements
• Lots of bug fixes and improvements

During issuance of X.509 certificates, the Subject Alternative Name can be stored in a searchable database column. This is enabled for all new Certificate Profiles, but not for existing profiles.

The CertificateData table has three new columns "notBefore", "endEntityProfileId" and "subjectAltName". A CA upgrade using direct database publishing to VA also requires schema changes on the connected VAs. Please see the UPGRADE document for details.

EJBCA 6.5 Release Notes

EJBCA 6.5.5

EJBCA 6.5.5 is a patch release fixing one bug and making one improvement. These fixes mostly facilitates OCSP operations under certain circumstances.

• Update of imported CA certificate is not persisted to the CertificateData table
• Internal Key Binding: certificate import should not use the current CA certificate if public key does not match

EJBCA 6.5.4

An autumn patch release to the so far stable EJBCA 6.5 branch, EJBCA 6.5.4 adds a few fixes to issues that showed up during production, as well as two new features and a couple of improvements.

All in all, this release contains 10 bug fixes and improvements.

Features

• Support for RegisteredID in subject alternative name.
• Ability to use variables in email subject for email expiration services.

Improvement: ICAO CSCA

• Issuer altName is now automatically set when creating a new Root CA.

Improvement: OCSP

• When CA certificates are revoked, OCSP responder will respond revoked for leaf certificates only if CA revocation reason indicates a CA compromise.

Bugs

• CMP revocation requests failed CA authorization, if issuer CA had X.500 ordering.
• clientToolbox did not start when using PKCS#11 and there was no JAVA_HOME set.
• Verification of database integrity protection did not work for custom certificate extensions.

EJBCA 6.5.3

Just in time for Midsummer in Sweden, what's better on a holiday than deploying a new version of EJBCA? This release of EJBCA 6.5.3 adds a couple of security fixes, corrects a few bugs that hit a couple of rare cases, and improves the EJBCA Database CLI. Not to mention an updated Japanese translation. All in all, this release contains 14 bug fixes and improvements.

Security

• Fix two security issues, and tighten a couple of cases that could cause unnecessary load.

CMP

• If issuing using CMP, using the Single Active Certificate Constraint, and OCSP publishing, the revocations were not published to OCSP.

CLI

• Improve the ejbca-db-cli verify command to be more flexible and powerful, and fix a small documentation flaw in the regular EJBCA cli.

Administration UI

• Update Japanese translation.

EJBCA 6.5.2

Winter is coming they say, but in the PrimeKey offices in Stockholm it seems to be a far way away. While we're busy toiling away at our new feature set for this autumn, we're ever intent on making sure that the 6.5 branch of EJBCA is the best it can be in terms of stability and performance. This release makes EJBCA 6.5.2 fully eIDAS compliant, fixes a breakage in CMP introduced in 6.5.1, patches one minor security issue and fixes a slew of user input handling improvements in the UI. All in all, this release contains 18 bug fixes, features and improvements.

Administration UI

• A minor script injection vector has been plugged.
• Administrators attempting to log in without having access to a Role (but having a valid certificate) will be audit logged as failed attempts.

CMP

• A bug fix in 6.5.1 caused a major breakage in CMP.

eIDAS

• Added the new ETSI DN attribute "organizationIdentifier"

OCSP

• Certificates revoked by being under the Single Active Certificate Constraint certificate profile setting weren't published

Read the full change log for details, and see the UPGRADE document for all functionality changes and upgrade instructions.

A selection of known issues

• One test failure on DB2: ECA-3298
• End entity profiles can't be deleted in high volume databases: ECA-4158
• Some ECDSA key specifiers missing in drop down menu for crypto tokens using PKCS#11 after JDK update: ECA-4251
• Race condition when multiple RA threads are requesting certificates for the same user: ECA-4347
• ClientToolBox is unable to verify signature when testing more exotic EC keys in HSM: ECA-4596
• Profiles export fail if hard tokens are enabled: ECA-5003
• Root access required to save system configuration: ECA-5005
• KeyBindings do not work if there's a CVC CA or uninitialized CA available: ECA-5072

EJBCA 6.5.1

Spring is in the air, and we here at PrimeKey are busy working on a very exciting new feature to be released with EJBCA 6.6.0 in Q3 of 2016.

Meanwhile, we've also been hard at work shoring up and fixing bugs in our 6.5 branch, ever intent in making sure that bugs get squashed faster than they can appear. All in all, we've fixed 35 bugs and improvements for this minor release.

Administration UI

• A minor information leakage, to the client, of preset end entity password was patched up.
• Due to hardening implemented in 6.5.0, CertificatePolicy objects were omitted from being imported with certificate profiles. This has been rectified.
• Several pages that didn't render correctly in WildFly 10 have been fixed.

Log Export

• A regression was fixed in the CmsCaService due to the signing key alias for CA's being changed in EJBCA 6.4.1/6.5.0

CMP

• Due to a change in how End Entity Profile references to CMP aliases are saved, the deprecated method of setting the EEP to "KeyID" to support CMP Unid (which hasn't been possible since 6.0.0) is no longer supported. This will be rectified in a future release.

External RA

• A caching bug in the CMP Proxy was fixed
• The CMP Proxy message signer chain and issuer chain were mistakenly implemented as one and the same in 6.5.0.

OCSP

• The optional Nonce sent in OCSP requests has been limited to 32 bytes to counter potential future issues. A request containing a Nonce larger than 32 bytes will now result in an error returned from the OCSP server.

Read the full change log for details, and see the UPGRADE document for all functionality changes and upgrade instructions.

A selection of known issues

• One test failure on DB2: ECA-3298
• End entity profiles can't be deleted in high volume databases: ECA-4158
• Some ECDSA key specifiers missing in drop down menu for crypto tokens using PKCS#11 after JDK update: ECA-4251
• Race condition when multiple RA threads are requesting certificates for the same user: ECA-4347
• ClientToolBox is unable to verify signature when testing more exotic EC keys in HSM: ECA-4596

EJBCA 6.5.0.5

Patch release for a few issues during upgrade from EJBCA 4.0, and a contributed patch for script based auto enrollment.

EJBCA 6.5.0.4

Patch release for pages broken in WildFly 10 and post-upgrade in EJBCA Community.

EJBCA 6.5.0.3

Patch release for ECA-4931 and ECA-4955

EJBCA 6.5.0.2

Patch release for ECA-4860

EJBCA 6.5.0.1

Patch release for ECA-4862

EJBCA 6.5.0

PrimeKey Solutions is very pleased to release EJBCA 6.5.0 into the wild. This release has primarily focused on tuning up the UI and responding to security developments in the Java EE world in the last few months. We've shifted plenty of focus to QA during this period, so this version is the most stable we've released yet. All in all, we've fixed 145 new features, bugs and improvements.

Administration UI

• Certificate profiles can now be set to restrict key algorithms, curves (for EC) and key length.
• The CSCA "CA Name Change" feature from ICAO 9303 7th part 12 has been implemented.
•  Removed a possible XML exploit from the administration web.
• De-serialization has been significantly hardened.
• Fixed a possible information leakage in the administrative web in regards to certificate and end entity profiles.
• Auditor default role has been given access to additional pages in the UI.

General Cryptography

• The underlying BouncyCastle library has been upgraded to version 1.54

Documentation

• All return and error codes from the CMP servlet have been documented.

OCSP

• OCSP responder can now cache the revocation status of client certificates (used to sign requests) for limited time periods.

External RA

• CMP Proxy now checks for message signatures, HMAC and checks revocation status for signing certificates, relieving the CA of handling unauthorized messages.

Certificate Transparency

• CT logs can now be submitted to log servers in parallel.

Read the full change log for details, and see the UPGRADE document for all functionality changes and upgrade instructions.

A selection of known issues

• One test failure on DB2: ECA-3298
• End entity profiles can't be deleted in high volume databases: ECA-4158
• Some ECDSA key specifiers missing in drop down menu for crypto tokens using PKCS#11 after JDK update: ECA-4251
• Race condition when multiple RA threads are requesting certificates for the same user: ECA-4347

EJBCA 6.4 Release Notes

EJBCA 6.4.2

This maintenance release contains 4 bug fixes and improvements. Below is a selection of the most noteworthy. Upgrading to this version will require no manual upgrade steps, but some rules will automatically be added to existing Auditor roles and analogs.

GUI

• Bug: A backport introduced in 6.4.1 broke the Certificate Transparency configuration page.
• Improvement: The Auditor Role has been extended, and now has read access to End Entities, all configurations and roles.
• Bug: PKCS#11 crypto token page was incorrectly formatted

OCSP

• Improvement: X-Forwarded-For is now logged if present in OCSP requests

Read the full change log for details, and see the UPGRADE document for all functionality changes and upgrade instructions.

A selection of known issues

• One test failure on DB2: ECA-3298
• End entity profiles can't be deleted in high volume databases: ECA-4158
• Some ECDSA key specifiers missing in drop down menu for crypto tokens: ECA-4251
• Certificate profile key length restriction ignored when creating CA: ECA-4310
• Race condition when multiple RA threads are requesting certificates for the same user: ECA-4347
• Standard superadmin shows up as 'Custom' in Basic Access Rules View: ECA-4663
• Audit log conditions 'starts with'/'ends with' return no results: ECA-4677

EJBCA 6.4.1

This maintenance release contains 14 new features, bug fixes and improvements. Below is a selection of the most noteworthy. Upgrading to this version will require no manual upgrade steps.

Improvements

• Apache commons-collections library has been upgraded to version 3.2.2

Bug Fixes

• Fixed checking CA authorization in CMP RA mode when using EndEntityCertificate authentication module
• Regression: A technology upgrade cause relevant information to not be displayed in the approvals screen.
• Regression: A usability issue regarding Notifications in End Entity Profiles has been solved.

A selection of known issues

• One test failure on DB2: ECA-3298
• End entity profiles can't be deleted in high volume databases: ECA-4158
• Some ECDSA key specifier missing in drop down menu for crypto tokens: ECA-4251
• Certificate profile key length restriction ignored when creating CA: ECA-4310
• Race condition when multiple RA threads are requesting certificates for the same user: ECA-4347

EJBCA 6.4.0

Only our second major release for 2015, EJBCA 6.4.0 represents a huge step into the future for EJBCA, introducing a slew of new features and improving usability in the UI across the board. We have also ramped up QA efforts for this release, which makes us confident to the stability of this release.

This major release contains 134 new features, bug fixes and improvements. Below is a selection of the most noteworthy:

New Features

• Granular control has been added to DN and SAN elements in End Entity Profiles. Inputed values can be controlled using regular expressions.
• Most of the UI has been given read-only rights, and a new role template (named Auditor) can be created and built upon to allow an auditor to view but not modify.
• Custom Certificate Extensions and Extended Key Usages can now be added on the fly from the UI, so no longer is a JBoss restart required when new ones are added.
• WildFly8 and WildFly9 are now supported platforms.
• Upgrade procedure has been improved, and EJBCA now tracks its own version, allowing many steps that were previously performed as part of manual upgrades to be performed automatically instead. In future versions, manual upgrades will be available from the UI as well as the CLI.

Improvements

• System Configuration has been split into sections and tabs
• "Exclude Active Manually-Activated CryptoTokens" check box is checked by default in System Configuration, meaning that clearing caches won't by default deactivate all crypto tokens.

Bug Fixes

• An XSS issue
• Fixed a NullPointerException when Client Certificate Renewal was performed over SCEP under certain circumstances.
• Setting "Allow merge DN Web Services" in the End Entity Profile caused SAN to be dropped.
• Remote EJB de-serialization of collections of certificates failed on JBoss 7.1.1 GA
• SCEP Client Certificate Renewal allowed renewal of expired certificates
• Information leakage pertaining to usernames from the public web
• ExternalRA GUI password was leaked to the logs

Technology Changes

• Support for XKMS has been removed and is no longer available.
• Underlying BouncyCastle Library has been upgraded to version 1.53
• Support has been dropped for JDK6.
• Support has been dropped for JBoss5

Security notice
The Xalan 2.7.1 library previously bundled with EJBCA is subject to a potential security issue (CVE-2014-0107). EJBCA does not by itself use the vulnerable functions from Xalan and there is thus no real vulnerability in EJBCA. We have anyway chosen to remove this bundled library from EJBCA.

As the application server also uses Xalan, users are recommended to upgrade to JBoss EAP 6.3 or later which includes the newer Xalan version. Alternatively, Red Hat provides patches for earlier EAP versions. For JBoss AS 7.1.1 it is possible to follow our instructions in the installation guide for how to instead use the libraries bundled with EJBCA.

Read the full Changelog for details.

A selection of known issues

• One test failure on DB2: ECA-3298
• End entity profiles can't be deleted in high volume databases: ECA-4158
• Some ECDSA key specifier missing in drop down menu for crypto tokens: ECA-4251
• Certificate profile key length restriction ignored when creating CA: ECA-4310
• Race condition when multiple RA threads are requesting certificates for the same user: ECA-4347

EJBCA 6.3 Release Notes

EJBCA 6.3.2.5

This patch release fixes one bug and introduces a new feature

• A small bug where soft crypto tokens generated during CA creation had auto-activate set during cache reload, even if that property had been set false.
• Custom order of DN in issued certificates can now be defined in Certificate Profiles

Read the full Changelog for details.

EJBCA 6.3.2.4

This patch release fixes two bugs

• An issue in SCEP Client Certificate Renewal in regards to renewing a certificate with the same issuing date as its issuing certificate
• A change to the enforcement of Single Active Certificate Constraints, where certificates where revoked by subjectdn+issuer instead of by username

Read the full Changelog for details.

EJBCA 6.3.2.3

This patch release primarily fixes bugs and adds missing functionality with respect to Client Certificate Renewal via SCEP.

Read the full Changelog for details.

EJBCA 6.3.2.2

This patch release primarily fixes the issue of the DirectoryName component of subjectAltName not being included in certificates.

Read the full Changelog for details.

EJBCA 6.3.2.1

This patch release primarily fixes the issue of certain elliptic curves having different human readable names in the JDK vs BouncyCastle.

Read the full Changelog for details.

EJBCA 6.3.2

This maintenance release contains 23 new features, bug fixes and improvements, in addition to all fixes made in 6.2.10. Below is a selection of the most noteworthy.

Upgrading to this version will require a post-upgrade step.

New Features

• CA certificate rollover via SCEP has been implemented in accordance to draft-nourse-scep-23

Improvements

• VA Publisher and External RA have become Enterprise features
• Build times have been improved

Read the full Changelog for details.

A selection of known issues

• One test failure on DB2: ECA-3298
• CA Certificates using brainpool curves can't be imported from the ClI. GUI works though: ECA-4022
• End entity profiles can't be deleted in high volume databases: ECA-4158
• Some ECDSA key specifier missing in drop down menu for crypto tokens: ECA-4251
• No HTTP Header 'Content-Type' in the Renew public web page: ECA-2844

EJBCA 6.2 Release Notes

EJBCA 6.2.10

This maintenance release contains 32 features, bug fixes and improvements, below is a selection of the most noteworthy. This branch was released in parallel with EJBCA 6.3.2.

New Features

• Certificate Profile settings have been added for optimizing environments without certificate storage, both not storing certificates to the database at all (like the already existent CA setting) and for writing all meta data, but not the certificate itself.
• A CLI command has been added to remove publishers and all references to those publishers.

Improvements

• EJBCA was upgraded to BouncyCastle 1.52

Bug Fixes

• Security: POP was not verified properly in WebService requests
• Regression: HealthCheck can again be automatically set for new CAs
• Regression: Certificate keyUsage was invalid when using the allowKeyUsage setting in certificate profiles.
• Regression: Caching in crypto tokens could cause adhoc upgrades of OCSP responders to fail
• Fixed an issue where deleting an HSM slot rendered the GUI unusable

Read the full Changelog for details.

A selection of known issues

• One test failure on DB2: ECA-3298
• CA Certificates using brainpool curves can't be imported from the ClI. GUI works though: ECA-4022
• End entity profiles can't be deleted in high volume databases: ECA-4158
• Some ECDSA key specifier missing in drop down menu for crypto tokens: ECA-4251
• No HTTP Header 'Content-Type' in the Renew public web page: ECA-2844

EJBCA 6.3.1

This maintenance release contains 17 new features, bug fixes and improvements, in addition to all fixes made in 6.2.8 and 6.2.9.

Below is a selection of the most noteworthy.

New Features

• Now possible to create CAs and issue End Entity certificates through the Web Service API.
• SCEP Client Certificate Renewal.
• Web Service API calls for monitoring certificate expiration.
• Single Active Certificate Constraint has been added to Certificate Profiles, allowing for automatic revocation of old certificates, as new ones are issued.

Improvements

• All Audit Log messages have been properly JavaDoc:ed.

Read the full Changelog for details.

A selection of known issues

• External RA GUI cannot handle SubCA certificates with critical CDP: ECA-2138
• One test failure on DB2: ECA-3298
• Regression: Healtcheck is not enabled for new CAs by default: ECA-3999
• CA Certificates using brainpool curves can't be imported from the ClI. GUI works though: ECA-4022
• End entity profiles can't be deleted in high volume databases: ECA-4158
• JDK patches for RSAWithMGF1 is not working on newer java: ECA-4175

EJBCA 6.2.9

This maintenance release contains 18 bug fixes and improvements, below a selection of the most noteworthy.

Improvements

• The main feature of EJBCA 6.2.9 is an optimization for certificate signing that has reduced certificate signing time with approximately 10% for low workloads and 70% for intensive workloads. Numbers are compared to EJBCA 5 and EJBCA 6.

Bug Fixes

• A minor regression introduced in 6.2.7 where trying to create a Browser Certificate in the External RA GUI failed.

A selection of known issues

• External RA GUI cannot handle SubCA certificates with critical CDP: ECA-2138
• One test failure on DB2: ECA-3298
• Regression: Healtcheck is not enabled for new CAs by default: ECA-3999
• CA Certificates using brainpool curves can't be imported from the ClI. GUI works though: ECA-4022
• End entity profiles can't be deleted in high volume databases: ECA-4158
• JDK patches for RSAWithMGF1 is not working on newer java: ECA-4175

EJBCA 6.2.8

The goal of this release has primarily been optimization of our OCSP responder, fixing usability issues, tightening up security and heavy GUI testing. We've also snuck in a brand new feature which web service users may find useful.

This maintenance release contains 42 bug fixes, features and improvements, below a selection of the most noteworthy:

Read the full Changelog for details.

Improvements

• OCSP responder has been widely optimized.
• OCSP responder now caches SCTs, improving response times when using Certificate Transparency.
• EJBCA has been upgraded to use BouncyCastle 1.51
• HealthCheck memory monitor now reports on total amount of free memory instead of allocated free memory.

New Features

• Web service calls for issuing certificates can now override EJBCA's default subject DN order with their own.

Bug Fixes

• A minor security escalation issue has been fixed affecting explicit rule access denial.

A selection of known issues

• External RA GUI cannot handle SubCA certificates with critical CDP: ECA-2138
• One test failure on DB2: ECA-3298
• CA Certificates using brainpool curves can't be imported from the ClI. GUI works though: ECA-4022
• A base64 decoder exception is thrown when inspecting a specially-crafted CSR: ECA-4071

EJBCA 6.3.0 

EJBCA 6.3.0 introduces a powerful new feature for Enterprise and Appliance users: the EJBCA Peer System protocol. The purpose is to allow secure communication over TLS between peered installations of EJBCA, doing away with the need of direct database publishing in order to propagate certificates and certificate information. This means that direct and synchronous communication is now possible between a Certificate Authorities and their associated Verification Authorities, also enabling verification of synchronization status and health.

EJBCA Peer System represents a step forward in how setup up complex multi-system installations, and we have great hopes for what we will be able to make possible in EJBCA in the future.

This is a major release with new features, bug fixes and improvements. All in all, 106 issues have been fixed.

Noteworthy changes

• Introduction of the EJBCA Peer System protocol.
• Fully localized in French, thanks to David Carella of Linagora.

A selection of known issues

• External RA GUI cannot handle SubCA certificates with critical CDP ECA-2138
• One test failure on DB2: ECA-3298
• ant install is known to fail on Windows machines running JDK >= 7.21 ECA-3602
• Wrong CA key used when decrypting SCEP requests ECA-3807
• Importing an externally produced certificate with empty DN fields fails ECA-4018
• CA Certificates using brainpool curves can't be imported from the ClI. GUI works though. ECA-4022

EJBCA 6.2.7

This, the first release of 2015, is a minor release primarily geared towards optimization and stabilization of the 6.2 branch. We have primarily optimized GUI behavior in regard to cryptotokens referencing many keys, as well as sorted out some documentation issues. QA procedures have also been revised and improved, which is the "known issues" list below is longer than in previous releases.

All in all, 24 issues have been fixed or implemented for this release.

Behavior of OCSP responder has been changed slightly in order to improve performance. Status of the OCSP signing certificate's CA is now only checked when the cache is reloaded, instead of at every request. If unsure how long the timeout is set for, check the value ocsp.signingCertsValidTime in ocsp.properties.

A selection of known issues

• External RA GUI cannot handle SubCA certificates with critical CDP ECA-2138
• One test failure on DB2: ECA-3298
• ant install is known to fail on Windows machines running JDK >= 7.21 ECA-3602
• Wrong CA key used when decrypting SCEP requests ECA-3807
• Importing an externally produced certificate with empty DN fields fails ECA-4018
• CA Certificates using brainpool curves can't be imported from the ClI. GUI works though. ECA-4022

EJBCA 6.2.6.8

EJBCA 6.2.6.8 is a patch release for ECA-2842 and ECA-2843, out of the box support for the OtherNames xmppAddr and srvName in subject alternative name.

EJBCA 6.2.6.7

EJBCA 6.2.6.7 is a patch release for ECA-5322, Ability to use variables in email subject for email expiration service.

EJBCA 6.2.6.6

EJBCA 6.2.6.6 is a patch release for ECA-5279, Adding support for RegisteredID subject alternative name.

EJBCA 6.2.6.5

EJBCA 6.2.6.5 is a patch release for ECA-4947

EJBCA 6.2.6.4

EJBCA 6.2.6.4 is a patch release for ECA-4885

EJBCA 6.2.6

EJBCA 6.2.6 is a maintenance release, primarily fixing two major issues and quite a few smaller ones.

Noteworthy changes

• The OCSP default responder behavior introduced in 6.2.4 was buggy when CAs were set as the default responder. ECA-3969
• Saving symmetric keys in a crypto token cause the GUI page to crash ECA-3933
• A bug causing CertSafe publisher creation was fixed ECA-3958
• For certificate profiles only specifying a single keylength, the default keylength was used instead ECA-3935
• SSLv3 protocol has been disabled for use in JBoss7 due to the POODLE vulnerability ECA-3862

All in all, 23 issues have been fixed in this release.

Known issues

•  One test failure on DB2: ECA-3298
• ant install is known to fail on Windows machines running JDK >= 7.21 ECA-3602

EJBCA 6.2.5

This minor release mainly centers around a bug found in the upgrade procedure when automatically upgrading CATokens to modern CryptoTokens. Due to a bug in 4.0.x, working CATokens could be created even with incorrect configurations, and these were then incorrectly processed. Since 6.2.5 the upgrade procedure will fail gracefully, allowing administrators to fix the configuration before proceeding.

Also, the CT log publisher will now use the the java system settings for http_proxy, which were previously ignored.

Known issues

• One test failure on DB2: ECA-3298
• SSLv3 is still available for use, but is considered vulnerable due to the POODLE exploit

EJBCA 6.2.4

This is a maintenance release introducing two new features, foremost of which are Private Domains for the Certificate Transparency (CT) Protocol and a change in the behavior of the OCSP default responder. All in all, 19 issues have been fixed.

Noteworthy changes

• The OCSP default responder is now configurable from the GUI. Old configurations in ocsp.properties will automatically be migrated, and the configuration
  line should be removed from ocsp.properties.
• The OCSP default responder will now reply for all external CAs that don't have a specific OCSP keybinding set. See UPGRADE document and documentation for further information.
• CertSafe publisher now works in JDK6
• An annoying but harmless error message which appeared in ant install has been removed.

Known issues

• One test failure on DB2: ECA-3298
• SSLv3 is still available for use, but is considered vulnerable due to the POODLE exploit

EJBCA 6.2.3

This is a maintenance release with a new feature, a couple of major and some minor bug fixes and improvements. All in all, 8 issues have been fixed.

Noteworthy changes

• Regression: The new Certificate Profile GUI page caused information from one profile to bleed into others due to incorrect scoping
• Regression: The install command failed if a certificate profile or token properties file was specified in install.properties due to a couple of missing switches
• New functionality: A publisher for Cert-Safe has been implemented

Known issues

• One test failure on DB2: ECA-3298

EJBCA 6.2.2

This is a maintenance release with one new feature, some minor bug fixes and minor improvements. All in all, 23 issues have been fixed.

Noteworthy changes

• The OCSP responder now supports requests containing Certificate IDs hashed in SHA256
• A minor regression where Certificate and CRL caches were not automatically refilled after server restart
• CLI no longer prompts twice when asked to prompt for the CLI password
• Several issues improving the upgrade procedure
• An information leakage issue in the public web concerning end entities sharing the same keys

Known issues

• One test failure on DB2: ECA-3298

EJBCA 6.2.1

This is a maintenance release with only bug fixes and minor improvement. All in all, 40 issues have been fixed.

Noteworthy changes

• The autoactivate parameter in for the CLI command 'cryptotoken create' has been changed from "A" to the more explicit "-autoactivate".
• An XSS issue in the Public Web was patched
• Regression: CPS and User Notice defined in Certificate Policy Extensions weren't being written to the relevant certificates
• Regression: Soft keystores for CAs created using the CLI were always created with the default password

Known issues

• One test failure on DB2: ECA-3298

EJBCA 6.2.0

This is a major release with new features, bug fixes and improvements. All in all, 76 issues have been fixed.

The biggest news in this release is a rework of the local CLI (command line interface), bringing the CLI up to the most modern standard with option handling and manual pages.

Noteworthy changes

• Completely reworked command handling of local command line interface (CLI) (See note 2)
• It's now possible to import and export Certificate and End Entity Profiles from the GUI
• VA machines can be created using a CRL
• Certificate and End Entity Profiles can now be imported and exported form the Web GUI
• SCEP configuration has been implemented from the Web GUI

If you are customizing the EJBCA public web to be embedded in a frame, note that EJBCA now uses the X-FRAME-OPTIONS HTTP header, preventing web GUIs from being framed in modern browsers.

Some CLI commands have changed names, though legacy support for the old names still remains. Some commands have had to undergo syntax changes, and they are as follows:

• General - Explicit password flag for CLI user password has been changed to '--clipassword'

All CLI commands' help pages can be summoned with the '--help' switch

• CaImportCACommand - Command performs two different tasks depending on the number of arguments, which are mostly mutually exclusive and unswitched, hence impossible to identify.
• CaImportCertCommand - The optional values e-mail, cert profile and ee profile must be used with a switch.
• CaInitCommand - The catokenproperties is now optional (no need to substitute with null if unused)
• CaRenewCACommand - The <regenerate keys> argument has been turned into a flag (-R), and a switch was added for the Custom Not Before value.
• InternalKeyBindingCreateCommand - The "-property" switch is no longer needed. Instead optional properties are loaded dynamically, but must be entered with a "" preceding the property name.
• InternalKeyBindingModifyCommand - Multiple "-addtrust" and "-removetrust" are no longer allowed, instead a separator "," may be used. Also, the --property switch is no longer used, instead properties are loaded dynamically and used like with InternalKeyBindingCreateCommand
• AddEndEntityCommand - Password parameter now input with --password flag, leaving blank will prompt. subjectAltName and email have been made optional and equipped with flags. certificateprofile, endentityprofile and hardtokenissuer have been given flags. hardtokenissuer options won't appear at all unless hard tokens been turned on.
• Services - The -listFields|-listProperties switched have been turned into commands instead
• ServiceCreateCommand/ServiceEditCommand - properties are sent in as a single command instead, at least until Services can be properly refactored and made more dynamic.

Known issues:

• One test failure on DB2: ECA-3298

EJBCA 6.1 Release Notes

EJBCA 6.1.3

This is a maintenance release with only minor bug fixes. In all 4 issues have been fixed.

Noteworthy changes

• Fixed a small typo and some localizations in a few GUI messages.
• Backport some fixes to the statedump command (Enterprise only).

EJBCA 6.1.2

This is a maintenance release with only one bug fixes. In all 1 issue have been fixed.

Noteworthy changes

• Fixed an issue where browser enrollment link was generated with incorrect encoding

See the notes, and known issues, for 6.1.0 below.

EJBCA 6.1.1

This is a maintenance release with a few bug fixes. In all 4 issues have been fixed.

EJBCA 6.1.0 was never distributed publicly.

Noteworthy changes

• Fixed some regressions that prevented 6.1.0 from functioning optimally.

See the notes, and known issues, for 6.1.0 below.

EJBCA 6.1.0

This is a major release with new features, bug fixes and improvements. In all 32 issues have been fixed.
The biggest news in this release are support for EAC 2.10 access control templates, more OCSP improvements as well as improvements for Key Recovery.

Noteworthy changes

• OCSP improvements and new features related to RFC 6960, minimizing size of OCSP responses (see note below).
• Implemented OCSP signing algorithm including client requested algorithms.
• CVC certificate profiles (ePassport PKI) now supports EAC 2.10 access control templates.
• Improvements to Key Recovery enabling encryption key rollover and providing more information about encryption keys.
• Windows build/install is now working.
• ManagementCA created during a default install now uses SHA256WithRSA.
• EJBCA now compiles (deployment/running not supported however) on WildFly 8 and Glassfish 4, also using Java 8.
• EJBCA can now use certificate serial number longer than 64 bits.
• Minor improvements and fixes to make life easier for everyone.

Note 1: OCSP responses no longer includes the Root CA Certificate, unless the Root CA is the OCSP signer, and it is configured to include the signer certificate. Having OCSP responses as small as possible is an important performance feature, and since the
client must have the root certificate as trusted there is no need to include the root certificate in the chain.

Note 2: In EJBCA 6.1.0 the Public Web interface logo filename was changed. If you have customized your own logo, you need to rename the logo filename from 'logotype.png' or 'ejbca_pki_by_primekey_logo.png' to 'banner_ejbca-public.png'.

Known issues

• One test failure on DB2: ECA-3298
• OCSP request signer verification does an additional database lookup: ECA-3299
• Poorly created primary keys for the AdminEntityData table causes issues in some cases: ECA-3469

EJBCA 6.0 Release Notes

EJBCA 6.0.4

This is a maintenance release with new features, bug fixes and improvements. In all 53 issues have been fixed.

The biggest news in this release is support for Certificate Transparency in EJBCA Enterprise.

Apart from that all issues reported from installations of EJBCA 6.0.3 has been fixed.

One of the fixes is a security fix. The security issue is rated as low, and can lead only to excessive CPU usage, if exposed to untrusted networks.

Noteworthy changes

• Support for Certificate Transparency, RFC6962 (EJBCA Enterprise only).
• Support for JBoss EAP 6.2 that changed default behaviour when creating datasources.
• SCEP GetCACaps command now works from iOS.
• Ensure that OCSP RFC5019 responses with nonces are not cached.
• Minor Command Line improvement.
• Fixed most issues reported from installations of EJBCA 6.0.3.

Known issues

• One test failure on DB2: ECA-3298
• OCSP request signer verification does an additional database lookup: ECA-3299
• Deployment on Windows does not work due to jboss-cli.bat arguments differing from jboss-cli.sh (half fixed some remaining)

EJBCA 6.0.3

This is a maintenance release with bug fixes, new features and improvements. In all 21 issues have been fixed.

Noteworthy changes

• Support for OCSP extended revoked status compliant with RFC6960.
• Ensure OCSP RFC5019 responses with unknown response code are not cached, compliant with CABForum discussions.
• Add OCSP archive cutoff date for expired certificates.
• Speedups starting the Command Line Interface.
• Bug fixes for Internal Key Bindings.

Known issues

• Cannot deploy with web-services disabled: ECA-3361
• Deployment on Windows does not work due to jboss-cli.bat arguments differing from jboss-cli.sh
• One test failure on DB2: ECA-3298
• OCSP request signer verification does an additional database lookup: ECA-3299

EJBCA 6.0.2

This is a maintenance release with bug fixes and improvements. In all 12 issues have been fixed.

Noteworthy changes

• Fix some issues with, and improve, OCSP signing cache reloading.
• Fix rotation of safer log4j logs.
• Support returning revoked for non issued certificates, instead of unknown (RFC6960).
• Minor CMP improvements, including full chain in responses and improve GUI.

EJBCA 6.0.1

This is a maintenance release with bug fixes and improvements. In all 13 issues have been fixed.

Noteworthy changes

• Improve statedump command (Enterprise).
• Fix bug causing OCSP healthcheck to always return error.
• Minor security fix and improvement.

EJBCA 6.0.0

EJBCA 6.0.0 is the latest major release of EJBCA, and both introduces and redefines a number of core concepts. Foremost amongst these are:

Main Changes

• The concept of Crypto Tokens has been introduced in order to separate CAs from the keys tied to them. Crypto Tokens allow for reuse of keystores between CAs or for other services like OCSP, and make configuration of keystores, both hard and soft, far simpler.

For additional information see Admin Guide and http://blog.ejbca.org/2013/08/whats-new-in-ejbca-6-part-1-crypto.html

• CMP is now fully configurable in the Admin GUI, and you can simultaneously use multiple different CMP configurations, called CMP aliases. For additional information see Admin Guide and http://blog.ejbca.org/2013/09/whats-new-in-ejbca-6-part-2-cmp-aliases.html
• There is a new concept of Internal Key Bindings to bind a Crypto Token to a certificate for different usages, OCSP signing and TLS authentication. For additional information see User Guide and http://blog.ejbca.org/2013/10/whats-new-in-ejbca-6-part-3-internal.html
• The merging of EJBCA and VA deployments. VA deployments are no longer anemic versions of EJBCA, instead all VA functionality has been merged into EJBCA proper. This for a single installation procedure, and for a machine to function as a CA and a VA simultaneously.

Other Noteworthy Changes

• Internal OCSP services are no longer configurable from the CA, but are instead automatically set up and always active.
• OCSP code has been brought up to CESeCore standard
• The installation work-flow and ant targets have changed to be more logical for deployment and installation.
• 'Certificate Request History' is now disabled by default for new CAs.
• PKCS11 crypto tokens can now be managed by slot label (in addition to slot number and index)
• JBoss 7.1 and EAP 6 are now supported
• Java 7 is now the default recommended Java version.

Minor Changes

• The term 'Admin Group' has been mostly purged and replaced with 'Role', as has the term 'User' been replaced by 'End Entity'
• Changes to certificate profiles:
  • The PKIX QCSyntax-v1 identifier from RFC3739 has been removed and will never be generated.
  • If "PKIX QCSyntax-v2" in the Certificate Profile is unchecked, no QCStatement with QCSyntax will be generated (new behavior).
  • If "PKIX QCSyntax-v2" in the Certificate Profile is checked, a QCStatement with PKIX QCSyntax-v2 will be generated (same as before).
• The default management CA has been renamed from AdminCA to ManagementCA.
• Many many minor features, improvements and bug fixes (over 300 issues are resolved for this release)

Known issues

• Other Rules for Supervisor role is not cleared is previously selected for another role type: ECA-3297
• One test failure on DB2: ECA-3298
• OCSP request signer verification does an additional database lookup: ECA-3299

EJBCA 5.0 Release Notes

EJBCA 5.0.14

This is a maintenance release with only minor bug fixes. In all 2 issues have been fixed.

Noteworthy changes:

• Fix problem, in some cases, when adding administrators with similar names.
• Default CA in OCSP responder can now handle CA DNs of any order.

EJBCA 5.0.13

This is a maintenance release with only minor bug fixes, where one is a security fix. In all 4 issues have been fixed.

The security issue is rated as low, and can lead only to excessive CPU usage, if exposed to untrusted networks.

Noteworthy changes:

• Some versions of MySQL picks bad index mixing OR and AND, so we make two generically safe queries instead.
• Fixed a regression where using a sun config file for PKCS11 (not the normal case) did not work.

EJBCA 5.0.12

This is a maintenance release with only security fixes.

Two cross site scripting vulnerabilities were discovered in EJBCA and fixed accordingly.

The vulnerabilities are rated as low, with a CVSS score between 1 and 3 (depending on subjective assessments).

The complexity to exploit the vulnerabilities is considered high and requires knowledge of the internal CA network as well as social engineering, or malicious internal super administrators.

The consequences of an exploit is considered low, as no administrator credentials can be stolen, and full audit logs of all actions are preserved.

We recommend that you assess the need to upgrade based on your particular deployment of EJBCA. Most CA deployments are largely
immune due to environmental isolation.

EJBCA 5.0.11

This is a maintenance release with new features, improvements and bug fixes. In all 12 issues have been fixed.

Noteworthy changes:

• Possibility to store the Base64 certificate data in a separate table.
• Fixed possible database rollback when CRL publishing failed.
• Support for multiple Vendor CA in CMP for 3GPP/LTE networks.
• Allow to use token label to reference PKCS#11 slots.
• Support ECDSA for automatic key renewal in OCSP responder.
• Added a new WS keyrecovery method for specified certificates.
• Add hostname in startup log.
• Add configuration option for forbidden characters.

EJBCA 5.0.10

This is a maintenance release with new features, improvements and bug fixes. In all 20 issues have been fixed.

Noteworthy changes:

• Added lots of CLI improvements to create subCA signed by external CAs, edit CAs and profiles, and add and edit services.
• It is now possible to create CAs, using the CLI, with explicit ECC key encoding in CA certificate. Useful for ePassport installations.
• When creating link certificates they are now issued using the same certificate profile as the CA is using.
• Improved support for Elliptic Curve Cryptography (ECC) using the CMP protocol. You can now use CMP in a Suite B compliant way.
• The LDAP publisher now supports STARTTLS extension, in addition to pure TLS connections.
• The batch enrollment GUI can now use JKS keystores, in addition to PKCS#12 keystores.
• Healthcheck messages are now logged in debug log, for easier troubleshooting.

EJBCA 5.0.9

This is a maintenance release with improvements and bug fixes. In all 14 issues have been fixed.

This release contains a minor security fix.

Noteworthy changes:

• New ClientToolbox sub-command: 'batchgenerate'
• CMP vendor certificate authorization
• Cache for publishers
• EJBCA compiles and runs on JDK7
• Fixed upgrade failure
• Fixed revocation not performing as expected in all circumstances
• Fixed renewal not always persisting the keys
• Minor bugfixes and improvements

Please notice the upgrade of BC jars if you are using Oracle JDK.

EJBCA 5.0.8

This is a maintenance release with improvements and bug fixes. In all 12 issues have been fixed.

Noteworthy changes:

• Improved robustness of 'ejbca.sh ca importcertdir' command.
• It is now possible to obfuscate log signer key password.
• Fixed a but with CMP certificate authentication.
• Minor bugfixes.

Please notice the upgrade of BC jars if you are using Oracle JDK.

EJBCA 5.0.7

This is a maintenance release with only a security fix.

Noteworthy changes:

• Fixed minor administrator escalation issue

Please notice the upgrade of BC jars if you are using Oracle JDK.

EJBCA 5.0.6

This is a maintenance release with a few bug fixes but also new features. In all, 35 issues have been resolved.

Noteworthy changes
- Support for German CertHash OCSP extension for Common PKI.
- Add rate limit for health check queries.
- Add Extended Key Usage for WiFi EAP.
- Fixed download of CA certificates with plus character in CA DN.
- Fixed key recovery when CA signed by External CA.
- Fixed a few upgrade glitches when upgrading from EJBCA 4.
- Fixed re-activation of suspended certificates through VA-publisher.
- Fixed potential privilege escalation issue for certain, non default, configurations.
- Fixed many other minor issues making deployment smoother.

Please notice the upgrade of BC jars if you are using Oracle JDK.

EJBCA 5.0.5

This is a maintenance release with a few bug fixes and new features. In all, 26 issues have been resolved.

Noteworthy changes
- Index recommendations have changed.
- CVC CAs can now be created from the Command Line Interface.
- EJBCA now supports Japanese localization
- Fixed bug where recursive deny rules caused deny for system user.
- Overall performance increases
- Removed redundant and excessive logging to audit logs

EJBCA 5.0.4

This is a maintenance release with a few bug fixes and new features. In all, 20 issues have been resolved.

Noteworthy changes
- OCSP: Possibility to only publish revoked certificates to Validation Authority.
- OCSP: Possibility to treat "non existing is good" based on URI on the Validation Authority.
- Do not allow creation of CAs using weak keys.
- Add Kerberos extended key usages.
- Add possibility to specify certificate profile to CA init CLI command.
- Fix a few more tests on windows platform.
- Fixed minor security issues in admin web.
- Fixed a few cosmetic issues improving usability.

EJBCA 5.0.3

This is a maintenance release with a few bug fixes and new features. In all, 16 issues have been resolved.

Noteworthy changes
- CMP: SenderKeyID no longer needs to be set in the request if it is not needed.
- CMP: KeyUpdateRequest works in RA mode as well as in client mode.
- CMP: It is now possible to skip verification of a CertConfRequest if desired.
- CMP: The CMP Proxy can now debug logging actual CMP messages.
- Approvals now work when approval requests were created using the CLI.
- Fixed all tests running on Glassfish and Windows platform.
- Fixed few minor XSS issues and other minor bugs

EJBCA 5.0.2

This minor release primarily addressed issues that cropped up during manual testing for Common Criteria
certification. Quite some effort was also put into stabilizing the 5.0.x release.

Noteworthy changes
- Support has been added for incorporating external plugins in the EJBCA EAR file at build time.
- Some XSS issues have been corrected.
- Authorization checks have tightened up in accordance to Common Criteria demands.
- Access rules for logging have finally been reconciled between CESeCore and EJBCA. The implication of this is
that the old EJBCA rules have been converted to the newer CESeCore rules, while those rules lacking application
in the new Secure Audit logging have been removed (all old rules matching /log_functionality/view_log/*_entries).
Thus in the new logging system it is no longer possible to add rules to a role allowing that rule to only view a
certain type of log event depending on what entry that event was registered as. Old rules are upgraded during
<ant post-upgrade>, which means that Supervisor roles won't work until this step is performed. Installations made in
5.0.0 or 5.0.1 need to be upgraded manually (see UPGRADE document), while installations upgraded from 4.0.x will have
their rules upgraded as part of the standard upgrade procedure.
- Chinese characters are now supported in DN attributes for End Entity Profiles.
- Lots of small bug fixes.

EJBCA 5.0.1

This minor release primarily fixed some CMP issues, one regression that was introduced in 5.0.0 and introduced
support for functionality from RFC4043 and RFC4325.

Noteworthy changes
- Support for Permanent Identifiers (RFC4043)
- Support for authorityInformationAccess in CRLs (RFC4325)
- Split xdocs in two separate sites, ejbca.org site and documentation site
- Documentation of EJBCA Djigzo integration

EJBCA 5.0.0

This major release marks a new step as EJBCA is now built on the Common Criteria certified secure core: CESeCore. The
negative implications of this for the end customer should be minimal, as database changes are few and far between, and
there is a clear upgrade path from EJBCA 4.0.x

CESeCore primarily provides two new features that will be of interest to the end user:
- The old database audit log system has been removed and replaced by a new security audit function that is capable of storing integrity protected audit records in the database.
- Integrity protection has been introduced to essential tables. This means that rows in these tables can't be modified through direct database interaction without invalidating the row.

Additionally, the following feature has been introduced.
- The Command Line Interface now uses authentication. Users are drawn from the standard End Entities list, and have the same respective roles. A default CLI user is created as a part of startup/upgrade in order to allow allow the CLI to be used without authentication,
and can be turned off from the Administration Interface. This user is defined in ejbca.properties

For administrators, the following changes are worth noting:
- When upgrading from 4.x to 5.x new approval requests created in a 5.x instance can not be read in a 4.x instance. So if you require uptime and roll-back capabilities, only allow to create new approval requests from an 4.x host.
- A "Super Administrator Role" is created during either bootstrap or upgrade to create a role for the default CLI user.
- 'Admin Groups' have been renamed 'Roles'. Relevant database tables remain unchanged.
- 'Admin Entities' are now referred to as 'Access User Aspects'.
- 'Users' are now ubiquitously referred to as 'End Entities'.
- Usage of access rules have in some cases changed, and some new access rules have been added (edit publishers). After an upgrade to 5.0, verify your roles and privileges.

EJBCA 4.0 Release Notes

EJBCA 4.0.16

This is a maintenance release containing a new feature and two bug fixes. In all 3 issues have been resolved.

Noteworthy changes
- Possibility to store the Base64 certificate data in a separate table.
- Fixed possible database rollback when CRL publishing failed.

EJBCA 4.0.15

This is a maintenance release containing a few new features and improvements. In all 5 issues have been resolved.

Noteworthy changes
- Possibility to create link certificates using the same certificate profile as the CA.
- LDAP publisher can publish certificate serialnumber to special object class inetOrgPersonWithCertSerno.
- Add missing variables C and UID to end user notification emails, by David Carella.

Note: There is a change in the LdapPublisher class API. Custom publishers overriding the LdapPublisher must be updated.

EJBCA 4.0.14

This is a maintenance release containing a few new features and improvements. In all 5 issues have been resolved.

Noteworthy changes
- Active certificates published to a VA publisher that only publishes revoked certificates are no longer stored in the queue.
- Publishers are cached for improved performance.
- New and fixed settings that makes EJBCA work better behind an Apache using ProxyPass, by David Carella.
- Some passwords are not displayed in the console during build anymore, by David Carella.

EJBCA 4.0.13

This is a maintenance release containing a few new features and improvements. In all 25 issues have been resolved.

Noteworthy changes
- New self-registration work-flow available in the public web.
- Added extended key usage for WiFi EAP authentication.
- Some build improvements to avoid issues on some platforms (no javascript, no jasper).
- More minor GUI improvements by David Carella of Linagora.
- Minor bug fixes.

EJBCA 4.0.12

This is a maintenance release containing a few new features and improvements.

Noteworthy changes
- Possibility for External OCSP responder key renewal at absolute times.
- Certificate expiration notifier can now filter on certificate profiles, not only CAs.
- A publisher for sampling of issued certificates.
- Added user friendly output of certificate profile dependencies when deletion can not be done.
- A new language tool for developers and localizers, by David Carella of Linagora.
- OCSP rekeying now works on JBoss 6.1.0 and JBoss EAP5

EJBCA 4.0.11

This is a maintenance release containing a few new features, GUI improvements and support for Japanese.

Noteworthy changes:
- Support for Japanese in the admin GUI, by OGIS-RI Co.
- Possibility to use custom revocation dates.
- Possibility to use aliases in RFC4387 CRL download links.
- Fixed support for special characters in filenames in export profiles cli command.
- Admin GUI improvements for looks and consistency, by David Carella of Linagora.

EJBCA 4.0.10

This is a maintenance release containing 1 new VA publisher feature, 1 security fix and GUI improvements..

Noteworthy changes:
- Possibility to only publish revoked certificates to VA.
- Possibility for OCS to handle "non existing is good" different depending on OCSP uri.
- Fixed XSS issue in admin GUI.
- Admin GUI improvements for looks and consistency.

David Carella has contributed many GUI improvements for the last few releases.
- forms and tables are colored according to consistent rules.
- all forms and tables are split in several logical sections.
- all similar fields (e.g. “[_] Use”, “[_] Critical”, “[_] Required”, “[_] Modifiable”, etc.) are vertically aligned.
- all check boxes (and radio boxes) can be checked by clicking on its label,
- two rules for in-line help for PKI administrators and RA officers.
- forms are globally more compact (the page heights are smaller).
- naming of certain object are more consistent across the web.

EJBCA 4.0.9

This is a maintenance release containing 1 security bug fix.

Noteworthy changes
- Fixed XSS issues in admin GUI.

EJBCA 4.0.8

This is a maintenance release with a few bug fixes and new features. In all, 16 issues have been resolved.

Noteworthy changes
- CMP: SenderKeyID no longer needs to be set in the request if it is not needed.
- CMP: KeyUpdateRequest works in RA mode as well as in client mode.
- CMP: It is now possible to skip verification of a CertConfRequest if desired.
- CRL: More efficient CRL download
- AdminGUI: Improvement in the appearance.
- Fixed few minor XSS issues and other minor bugs

EJBCA 4.0.7

This is a maintenance release with a few bug fixes and a new feature. In all 10 issues have been resolved.

Noteworthy changes
- Fixed a bug reading large OCSP requests over HTTP 1.1 using chunked encoding.
- Fixed a few minor XSS issues.
- Fixed an issue where building the Validation Authority (VA) failed on specific platforms.
- The VA health-check URL is now what it is claimed to be in the property file. You will need to reconfigure devices monitoring this URL.
- Documented EJBCA integration with Djigzo
- Added a plug-in build system.
- Improved support for Chinese in the admin GUI.

EJBCA 4.0.6

This is a maintenance release with a few bug fixes and a new feature. In all 4 issues have been resolved.

Noteworthy changes
- Improved CMP by supporting KeyUpdate requests is client mode.
- Fixed importing empty CRL via CLI
- Fixed two minor bugs

EJBCA 4.0.5

This is a maintenance release with a few improvements and bug fixes. In all 7 issues have been resolved.

Noteworthy changes
- Correct comparison of public key in HSM and CA certificate
- Fixed regression during republish
- Many small bug fixes.

EJBCA 4.0.4

This is a maintenance release with a few new features and bug fixes. In all 33 issues have been resolved.

Noteworthy changes
- Improved CMP with many new authentication modules in both client and RA mode, and support for Nested content
- Support for custom certificate extensions with raw or RA defined values.
- Many small bug fixes.

EJBCA 4.0.3

This is a maintenance release with a few improvements and bug fixes. In all 5 issues have been resolved.

Noteworthy changes
- Improved CMP interoperability, with minor improvement and bugfixes.
- Fixed a bug that made it impossible to delete end entity profile on certain databases, in particular hsql (test database).

EJBCA 4.0.2

This is a maintenance release with many improvements and fixes. In all 44 issues have been resolved.

Noteworthy changes
- Internal optimizations makes this the fastest version of EJBCA ever, capable of issuing > 400 certificates/second (depending on configuration).
- Certificate enrollment now works also with Safari and Chrome browsers.
- Support for PrivateKeyUsagePeriod certificate extension.
- Fixed a time zone bug issuing CVC certificates where the date was encoded using local timezone instead of GMT in certificates.
- More admin console and public web improvements from David Carella of Linagora.
- Now uses ISO8601 date format consistently when entering dates in admin console.
- Automatic generation of Norwegian UNID numbers from CMP requests.
- Many small bug fixes and improvements.

The ISO8601 date format (yyyy-MM-dd HH:mm:ssZZ) is used in the Admin GUI and EJBCA WS interface, so clients no longer have to be aware of in what time zone the CA servers are located.

The old format (in US Locale) will still work for incoming requests in the WS, but any returned UserDataVOWS containing custom start and end date will use the new format.

If you get a "java.lang.NoSuchMethodError" in the admin GUI it is because JBoss does not clean temporary files very good.

Delete the directories JBOSS_HOME/server/default/tmp and JBOSS_HOME/server/default/work and restart JBoss to get it working.

EJBCA 3.11 Release Notes

EJBCA 3.11.5

This is a maintenance release containing 1 security bug fix.

Noteworthy changes
- Fixed XSS issues.

EJBCA 3.11.4

This is a maintenance release containing 1 security bug fix.

Noteworthy changes
- Fixed XSS issues in admin GUI.

EJBCA 3.11.3

This is a maintenance release containing 3 bug fixes.

Noteworthy changes
- Certificate enrollment now works also with Safari and Chrome browsers. (Backport from EJBCA 4.0.2.)

EJBCA 3.11.2

This is a maintenance release containing 11 bug fixes, and 12 new features/improvements.

Noteworthy changes
- Several bug fixes
- Increased algorithm support on PKCS11 HSMs
- Added a webservice based RA written by Daniel Horn
- Possibility to disable the command line interface
- New CA CLI commands to import CRLs and certificates which are useful when migrating to EJBCA

EJBCA 4.0.1

This is a maintenance release - only one issue is resolved.

Noteworthy changes
- Fixed failure to perform web browser enrollment with Internet Explorer.

EJBCA 4.0.0

EJBCA 4 uses Java Enterprise Edition (JEE) 5 instead of J2EE. This release is a major improvement of the core, modularization, portability and packaging, but you will not notice many functional
differences.

The database schema is fully defined through the Java Persistence API and table create scripts are provided for all the supported databases.

The Ingres database can now be used with EJBCA without patching the code.

Many bugs have been corrected. For example EJBCA Services will run more stable in a clustered environment.

The interface ICustomPublisher has been modified, via removal of the number parameter from the storeCRL method. Any custom classes implementing this interface need to be modified.

Java 1.6 and Ant 1.7.1 or higher is required from this version on.

For upgrade instructions, please see UPGRADE and have a look in the installation instructions for notes on how to configure your application server.

Known issues (see EJBCA issue tracker for a more updated version):
- XKMS Signature validation does not work. (ECA-2078)
- OCSP re-keying on JBoss 6.0.0.FINAL does not work. (ECA-2077)

EJBCA 3.11.1

This is a maintenance release - 16 issues have been resolved. Only fixes and layout improvements, no new features.

This release fixes an upgrade issue from 3.6.x to 3.11.x and also a MySQL/MyISAM related issue in the 3.11.0 release.

A few uncaught regressions from 3.10.x and 3.11.0 were fixed, and as usual David Carella of Linagora added some Admin GUI layout improvements.

Noteworthy changes
- It is now possible to easily upgrade from EJBCA 3.6.x to 3.11.x
- Fixed a MySQL mapping that did not work when using the MyISAM storage engine and UTF-8 encoding.
- ETSI QC value limit can now have the value zero.
- Admin GUI improvements from David Carella of Linagora.
- Added a favicon to the EJBCA web interfaces.
- Fixed an issue causing cached end entity profiles (not default) to be changed for some actions in the admin GUI.
- Fixed an issue where session information spilled over to other edits when using the "Back to certificate profiles" link.
- Fixed an issue where using the required flag on Cardnumber in a end entity profile gave error about missing unstructured address.
This also resolved an issue where the DN field Unstructured Address did not work.

NOTE: If you have been using the SEIS Cardnumber extension in End Entity Profiles (not default), this setting had an internal collision with the UnstructuredAddress DN field, so they could not be used at the same time. There was a problem using the UnstructuredAddress lately.

The issue was resolved by changing the internal number for Cardnumber. This is not possible to upgrade automatically.
* If you used SEIS Cardnumber * you must manually edit your end entity profiles and re-check the 'use' checkbox after upgrade to 3.11.1.
This should affect a very small number of users.

EJBCA 3.11.0

This is a major release with several new features - 47 issues have been resolved.
One major goal with this release is to prepare for a seamless migration to EJBCA 4.0. To make the migration path to EJBCA 4.0 a simple plug-in upgrade, EJBCA 3.11 introduces database changes needed to make the schema fully compatible and consistent across all supported databases.

Upgrade to EJBCA 3.11 should be simple as usual, just follow the instructions in doc/UPGRADE.

Noteworthy changes
- Possibility to configure CA not to use certificate and user store, meaning that CA can issue certificates without having to access database after service startup.
- External OCSP responder can now function as a validation authority serving OCSP, CRLs and CA certificates.
- Certificate store access via HTTP according to RFC4387 standard.
- Possibility in WebService Interface to specify extended information when editing users.
- Possibility to specify custom certificate serial number for end entities using CMP protocol. CMP RA secret can now also be specified per CA.
- Upgrade database schema to be consistent across databases.
- Add a few new columns to database tables, a preparation to be used in EJBCA 4.0.
- Improvements in the Glassfish support, now also usable with Oracle database.
- Several other new features and extended key usages, GUI improvements and performance enhancements - many of which are contributed by Linagora.

Important notes
1. If you have a very large database (>1 million issued certificates) you can probably not run the database schema upgrade scripts automatically, but you want better control of the changes. You can then run the upgrade SQL statements manually. You can find them under src/upgrade/310_311, with an individual sql file for your database.

2. The external OCSP responder module have many added features in this release. This has caused some configuration file changes. See VA Installation documentation. Specifically the CA Publisher datasource configuration has moved from ocsp.properties to va-publisher.properties, a much better location. Health check settings has moved from ocsp.properties to va.properties.

3. The database schema has changed. If you run an external OCSP responder the database schema on that must also be updated for the VA/OCSP publisher to work. The two new columns rowVersion and rowProtection does not have to be set to any specific value.

4. The error message when publishing fails has changed from "EXTERNAL OCSP ERROR" to "Validation Authority ERROR". If you have scripts monitoring this, they must be updated.

EJBCA 3.10 Release Notes

EJBCA 3.10.6

This release is a very small maintenance release to mark the end of the 3.10 branch, anticipating 3.11.0 to be released withing a few days.
If you are running 3.10.5 with no issues, there is no real reason to upgrade to 3.10.6.

Noteworthy changes
- ExtendedInformation, such as issuance revocation reason, can now be added when editing users with the WebService API.

The release also fixes four minor or exotic bugs.

Note: The WebService WSLD has changed for adding ExtendedInformation in the UserDataVOWS object.
Old WS clients without this should still work and we have tested with older EJBCA clients.
However if you depend on the WS-API you must test in your environment before bringing this new version in production.

EJBCA 3.10.5

This is a maintenance release with 37 issues resolved, both features and bug fixes.

Noteworthy changes
- Fixed admin GUI error running on JBoss 5.
- Fixed some issues with audit and approvals when using admin certificates issued by an external CA.
- Harmonized admin GUI and improved looks. Contributed by David Carella of Linagora.
- Added and improved caches of profiles and CAs, improves performance. CLI for clearing caches.
- Fixed installation issue on Windows when JBoss installed in root directory.
- Fixed re-publishing of certificates when CertReqHistory is not used. CertReqHistory is enabled by default for new CAs.
- Updated German translation, contributed by Atos Origin.
- Support unrevocation using WS-API.

There were many changes in the admin GUI for this release. Please let us know if you encounter any regressions using the admin GUI.

EJBCA 3.10.4

This is a maintenance release with 23 issues resolved, both features and bug fixes.

Noteworthy changes
- Possibility to specify custom certificate serial number for end entities.
- Possibility to configure CA to not use CertReqHistory to increase performance.
- Harmonized admin GUI and improved looks. Contributed by David Carella of Linagora.
- Other performance optimizations. More than 100 certificates per second can now be issued under certain conditions.
- WS API did not work with external administrator certificates.
- Mitigate potential XSS vulnerabilities in admin GUI.
- Fixed bug when creating CRLs for CAs with single quote in the DN.
- Other admin GUI improvements with better error messages in some cases.

One known issue from 3.10.4 is https://jira.primekey.se/browse/ECA-1779

There were many changes in the admin GUI for this release. Please let us know if you encounter any regressions using the admin GUI.

EJBCA 3.10.3

This is a maintenance release with only 6 issues fixed.
The release was primarily done to fix a regression for EAC CVC CAs using ECC keys.

Noteworthy changes
- EAC CVC Document Verifiers using ECC keys did not work properly. This was fixed and new test cases was added to the test suite.
- Removed requirement to use "Batch generation" when using CMP RA mode.
- Fixed issue that revocation in admin gui did not work with CAs using accented characters.
- Added code to mitigate potential cross site scripting in admin gui. Note that client certificate authentication was still needed so it was not publicly exploitable.
- Added UTF-8 URI encoding for the public http port (8080). It was previously only enabled for the https ports.

EJBCA 3.10.2

This is a maintenance release with a new features, improvements and several bug fixes. 36 issues in total have been resolved.
With this release 3.10.2 is the preferred release for all installations.
We believe that most regressions resulting from the large restructuring in 3.10.0 is resolved.

Noteworthy changes
- CMP proxy module.
- Improved transaction isolation and performance in CMP.
- Improvements for JBoss 5.
- Possibility to Enforce unique SubjectDN Serial Number.
- Framework for validation of the contents of end entity fields.
- Fixed some regressions in the admin GUI related to cross certification and CV certificates.
- Possible to define custom CN of superadmin on install.
- Update pre-defined windows smart card logon profiles.
- Output the servers time to the first page of the Admin GUI.
- Supervision of the OCSP responder certificate validity in the standalone OCSP responder.
- Many minor bug fixes related to the big restructure in 3.10.0.
- Minor security enhancements.

In EJBCA 3.10.2 the Exception handling for NotFoundExceptions when a user does not exist was slightly overhauled.
This effected some WS-API calls (findCerts, getLastCertChain and getHardTokenData). The behavior of the methods are unchanged, but if
you have handling for such errors you should double check the error handling anyhow. Javadoc has been updated where it was previously not clear.

EJBCA 3.10.1

This is a maintenance release with a few new features, some improvements and several bug fixes. 33 issues in total have been resolved.

Noteworthy changes:
- New WS-API methods for renewing CAs. This enables the possibility for automated SPoCs in an EAC ePassport PKI.
- New CMP proxy module letting you have a separate server terminating CMP connections and then forwarding them to the CA.
- Possibility to renew CAs without activating new keys, enabling the CA to continue working until a new certificate is imported.
- Support for SHA384WithECDSA signature algorithm.
- Fixed deployment on JBoss EAP 5.0.0.
- Fixed admin GUI bug with problems selecting privileges for RA administrators.
- Fixed some issues with cli and renewal of expired CAs.
- Fixed a bug with cli for getting delta CRLs.
- Other minor bug fixes.

Note that there is a new access rule for "Renew CA". An administrator with renew CA privileges is authorized to renew CA and import certificate response (from an external CA). Previously only super administrator was allowed to to this.
CA administrators bye default has this new privilege. If you do not want them to have this privilege you can disable it in Advanced mode in the edit privileges section of the admin GUI.
The new privileges can be used together with the new WS-API functions and CLI to renew specified CAs.
To be authorized the administrator need both the new "Renew CA" privilege and and be authorized to the specific CAs.
The methods in CAAdminSessionBean that have changed privileges are renewCA, makeRequest and receiveResponse.

EJBCA 3.10.0

This is a major release with lots of internal reorganisations, new features and fixes.

NOTE:
A user that is requesting a certificate with same public key or subject DN as an existing certificate issued to another user is now denied the certificate. If this will result in any problem in your installation you may disable any of these checks on the "Edit CA" page. You can read more about it in the user guide.

Noteworthy changes
- Restructuring and refactoring to improve maintainability, prepare for the EJBCA 4 release and Common Criteria certification.
- Web Service method for creation or update of a user and creation of a certificate in a single transaction.
- Enforcement of unique public keys and subject DNs.
- New External RA API GUI for browser enrollment without ingoing traffic to the CA.
- Support for Ingres 9.3.

This version removes the SafeNet Luna JCE class for use as a CA Token. You must now use the more generic, and well tested, PKCS#11 CA token type instead.
The usage of PKCS11 CA tokens is well documented in the Admin Guide.

EJBCA 3.9 Release Notes

EJBCA 3.9.10

This is a maintenance release with one backported fix from 4.0.

Changes:
- Better handling of X.500 DN order with multiple attributes (e.g. DC, OU)

EJBCA 3.9.9

This is a maintenance release with one new feature and a few backported fixes from 3.10.

Changes:
- ExtendedInformation, such as issuance revocation reason, can now be added when editing users with the WebService API.
- Added correct URIEncoding also for port 8080 in Tomcat's server.xml.
- Fixed Issuer CA DN HTML escaping when revoking through Admin GUI.

Note: The WebService WSLD has changed for adding ExtendedInformation in the UserDataVOWS object.
Old WS clients without this should still work and we have tested with older EJBCA clients.
However if you depend on the WS-API you must test in your environment before bringing this new version in production.

EJBCA 3.9.8

This is a maintenance release with only three fixes.

Changes:
- Supervision of the validity time of the signing certificates for the OCSP responder.
- The CAR of a CV Certificate can hold an incorrect sequence number (which makes the CAR incorrect).
- Upgrade may cause "use authority information access" to be enabled though it was not before in certificate profile.

EJBCA 3.9.7

This is a maintenance release with only four fixes.

Noteworthy changes
- Fixed an error when creating DVs signed by external CVCAs (EAC ePassport only).
- Give better error message when the same public key is passed in initial CVC request (EAC ePassport only).
- Log OCSP responder startup and shutdown.
- Fix possible NullpointerException in EjbcaWS.getAvailableCertificateProfiles.

EJBCA 3.9.6

This is a maintenance release with two new features, and five minor fixes.

Noteworthy changes
- New WS-API methods for renewing CAs. This enables the possibility for automated SPoCs in an EAC ePassport PKI.
- When renewing CA keys for CAs signed by external CAs you can now choose to not activate the new keys. This enables your CAs to continue working uninterrupted until a certificate response is received and imported.
- Errors when using approval notifications are fixed.
- The getcrl cli command can now also retrieve delta CRLs.
- Two other minor fixes for CA renewal.

Note that there is a new access rule for "Renew CA". An administrator with renew CA privileges is authorized to renew CA and import certificate response (from an external CA). Previously only super administrator was allowed to to this.
CA administrators bye default has this new privilege. If you do not want them to have this privilege you can disable it in Advanced mode in the edit privileges section of the admin GUI.
The new privileges can be used together with the new WS-API functions and CLI to renew specified CAs.
To be authorized the administrator need both the new "Renew CA" privilege and and be authorized to the specific CAs.
The methods in CAAdminSessionBean that have changed privileges are renewCA, makeRequest and receiveResponse.

EJBCA 3.9.5

This is a maintenance release with minor fixes and improvements.

Noteworthy changes
- Fixed a performance regression for the OCSP service that could lower throughput from 400 to 200 req/s.
- Added process time parameter to OCSP transaction logging.
- Fixed and improved usage of the optional IAIK PKCS#11 provider.
- Improve sequence handing for EAC CVC CAs.
- Fixed a bug when renewing CA keys on HSMs.
- Fixed that you could not use a dot in pre-set usernames in end entity profiles.
- Added possibility to install directly with external admin CA, initializing authorization module in importcacert cli command.
- Added possibility to prompt for keystore password during install so you never have to write it anywhere.

EJBCA 3.9.4

This is a minor release with only a few minor fixes.

Noteworthy changes
- Fixed a bug where OCSP responder would not return correct status for archived (expired) certificates.
- Fixed a regression for the (deprecated) SafeNet JCE CA token.
- Fixed a regression where you could not renew expired CAs
- It's not possible to renew soft ECC CA keys in the admin GUI
- All language files are now encoded in UTF-8
- Fixed corner cases where bogus CRLs and certs could be published to LDAP

EJBCA 3.9.3

This is a minor release but packed with new minor features and fixes, 41 issues have been resolved.
Some minor features and options and some bug fixes and stabilizations.

Noteworthy changes
- Fixed a regression in 3.9.2 where you could not upload files in the admin GUI.
- Certificate profiles can now specify a different signature algorithm than the CA. Useful to start migrating SHA1 CAs to issue SHA256 certificates.
- Possibility to use part of user data in LDAP DN but not in certificate DN when publishing certificate to LDAP.
- Possibility to set fixed end date of certificates in certificate profile and CA configuration.
- Possibility to configure several notification services for expiring certificates, notifying at different times, i.e. 30 days, 7 days, etc.
- Browser enrollment tested with Windows 7.
- ECC improvements and fixes for CAs and HSMs, CA renew keys, CA import, brainpool curves, explicit ec parameters, clientToolBox etc.
- GUI improvement to the admin GUI with nicer navigation menu and CSS. Contributed by Linagora, France.
- cert-cvc: fixed rare possibility to get bad encoding of EC points in certificates. Contributed by DGBK, Netherlands.
- CVC CA fixes and improvements for EAC PKI, approvals, import CAs, fix cli info command, .cvcert instear of .crt when downloading certs, etc.
- Don't publish certificates for inactive CA services to LDAP.
- Fix so renewing CA keys in admin GUI does not reload all CA tokens.
- Fixed an OutOfMemory error when failing to publish large CRLs with connection closed error.
- Fix download issues with IE for exported CA keystores.
- Many small optimizations, fixes and improvements.

EJBCA 3.9.2

This is a minor release but packed with new minor features and fixes, 38 issues have been resolved.
Some minor features and options and many bug fixes and stabilizations.

Noteworthy changes
- Sign and verify of files with clientToolBox when the private key is stored on a HSM.
- Possible to limit signing keys for an external OCSP responder to keys within a set of key aliases.
- Add support for the TSL signer extended key usage
- Use improved validity period parsing in Certificate Profiles
- Add option to use publisher queue or not for CRLs and certificates
- Document MS application policies extension
- Fixes for ejbcaClientToolBox.bat for windows platform
- Timeouts for LDAP publishers to handle unstable LDAP servers
- For issue where CRL service may stop running if database is stopped for some period
- Change so that Issuing Distribution Point on CRLs is not used by default in CA configuration
- Fix issue using IAIK provider with several CAs
- Fix slow revocation if a user have many certificates
- cert-cvc: getting expiration date returns 00.00 hours but it means it's valid the whole day
- cert-cvc: bad encoding of EC points in certificates in rare cases where affineX and affineY is not same size
- Many small optimizations, fixes and improvements.

EJBCA 3.9.1

This is a minor release but packed with new minor features and fixes, 46 issues have been resolved.

Noteworthy changes
- Improvements to public enrollment process including automatic renewal.
- Ability to specify approvals on certificate profiles.
- Configurable list of extended key usages.
- Dynamic update of max-age and nextUpdate for OCSP responders, also per certificate profile.
- In CRL update service you can select which CAs to generate CRLs for.
- Possible to schedule CRLs more often than hourly.
- Possible to remove soft CA key and possibility to import it back again.
- Possibility to remove passwords from properties files.
- Support for CRL distribution points with URI:s containing semicolon.
- Transaction log for web service certificate issuance.
- Possibility to specify Any CA in end entity profiles.
- More flexible configuration of CA validity, years, months days.
- Improved error message in GUI when HSM activation fails.
- Many small optimizations, fixes and improvements.

EJBCA 3.9.0

This is a major release adding many new features and improvements, and fixing numerous bugs.
126 issues have been resolved for this release. Check the changelog, there is a good chance that your favorite issue has been resolved.

Noteworthy changes
- Support for CAs using DSA keys. EJBCA now supports all major algorithms; RSA, DSA and ECDSA.
- External RA improvements. CA service running as an EJBCA services gives full cluster functionality and support for multiple external RAs. As a bonus it is now much easier to install and configure.
- Robust re-publishing mechanism for publishers that fail, running as an EJBCA service.
- OCSP responder improvements with performance improvements and support for on-line renewal of OCSP responder keys and certificates.
The external OCSP responder can now saturate high performance HSMs.
- OCSP monitoring tool for monitoring synchronization between EJBCA and external OCSP responders.
- GUI for configuring the external OCSP publisher with new options.
- Possible to change OCSP signing keys in a running external OCSP responder.
- New commands and stress tests in the client toolbox.
- A new admin web gui front page with status overview panels.
- Possible to configure status of certificates issued for end entities, i.e. issue certificate revoked "on hold".
- New DN attribute, Name.
- Performance improvement by caching and lowering number of database queries.
- XKMS now works also on Java 6.
- Possibility to set user validity start and end time in WS API.
- Lots of small fixes and improvements to the admin GUI.
- Lots of small bugfixes.
- Keon CA to EJBCA migration guide.

Note that the configuration of External RA changed dramatically (to the better). If using the external RA, please read the manual how to install and configure the RA CA service in EJBCA 3.9.

Note that this version brings database changes. Read the UPGRADE document for upgrade instructions.

This release should, as always, work on JBoss, Glassfish, Weblogic and OC4J, together with most available databases.

EJBCA 3.8 Release Notes

EJBCA 3.8.3

This is a minor release with only a few fixes

- Fixed unability to deploy on PostgreSQL + Glassfish combination.
- Fixed possible extensive CPU usage for crafted messages to CMP RA service (not default config).
- Fixed Ugly error message in LDAP publisher if no certificate to remove exists.

EJBCA 3.8.2

This is a minor release adding improvements and bugfixes

- Add street and pseudonym DN attributes.
- OCSP improvements, RFC 5019, nextUpdate, support for requests using GET, improved configuration and error handling.
- Correct coding of optional Issuing Distribution Point in CRLs.
- Possible to publish userPassword in LDAP.
- A few minor fixes.

EJBCA 3.8.1

This is a minor release, targeted for adding support for JBoss 5 and fixing a mistake that caused install on Glassfish to fail.

It also adds a few minor improvements and bugfixes.
- Add support for JBoss 5.
- Fix support for Glassfish caused by a forgotten commit in 3.8.0.
- Improve support for Weblogic 10.3.
- Fix support for IPv6 subject alternative names.
- A few minor CMP, OCSP and CVC fixes.

EJBCA 3.8.0

This is a major release, particularly focusing on support for administrators to log in with certificates from other CAs, not in EJBCA.

Noteworthy changes
- Restructure administrator validation to allow admins using externally issued certificates.
- Add a CLI subcommand to add an administrator in an admin group using the serial number.
- Drop administrator flag in end entities, it's not needed, makes configuration easier together with remade admin GUI.
- Possible to generate CA PKCS#10 request without giving CA certificate.
- Add support for SEIS Card Number extension.
- Added KRB5PrincipalName subjectAltName.
- Option in certificate profiles for reversing DN order.
- Enroll for CV certificate on public web.
- Upload PEM or binary certificate requests on public web.
- Possible to sign releases and deployed code.
- Enhanced basic custom certificate extension.
- Command to list objects in Luna HSM partition.
- Some bug fixes.

NOTE: There are database upgrades in this release, so read UPGRADE carefully.

Because there are binary files in EJBCA_HOME/lib changed there is no patch file for upgrading
EJBCA 3.7.x to 3.8.0. Use the full package from EJBCA 3.8.0 and follow the upgrade instructions in UPGRADE.

Note that if using JBoss, you need JBoss 4.2.x or later to run EJBCA 3.8.x.

EJBCA 3.7 Release Notes

EJBCA 3.7.5

This is a minor release that makes a few minor changes in the CVC WS-API and adds a variable in OCSP audit log.
- Allow logging of REPLY_TIME in both audit and transaction logs
- Fixed CVC certificate requests with error leaves user status as new
- Fixed that cvcgetchain does not return latest cert
- Add brazilian portuguese translation of admin GUI
- A few minor bugs

This is a plug-in upgrade from 3.7.x. See UPGRADE for the simple instructions.

EJBCA 3.7.4

This is a minor release that replaces 3.7.3 where initial install was broken. It has a few additional fixes from 3.7.3 as well.
- Substitute email from- and to- as well in user notifications
- Create a built-in Server certificate profile
- OCSP improvements

This is a plug-in upgrade from 3.7.x. See UPGRADE for the simple instructions.

EJBCA 3.7.3

This is a minor release mainly put out to fix building on Glassfish that broke in 3.7.2.
- Fix on Glassfish that was broken in 3.7.2
- Glassfish support for PostgreSQL
- A couple of trivial fixes.

This is a plug-in upgrade from 3.7.x. See UPGRADE for the simple instructions.

EJBCA 3.7.2

This is a minor release with focus on fixing making OCSP optimizations, introducing some minor features and fixing a few annoying bugs.
- Add Intel AMT extended key usage
- Optimize OCSP servlet for better performance
- OCSP responder improvements: reload of p11 when connection broken, return error of audit logging fails.
- CA certificates with SerialNumber in DN does not work with External OCSP
- WS-API, make mathtype contains with with matchwith username
- Key length changes when editing CA in admin-GUI
- Minor GUI fixes.

This is a plug-in upgrade from 3.7.x. See UPGRADE for the simple instructions.

EJBCA 3.7.1

This is a minor release with major focus on enhancements to CVC CA support for EU EAC ePassport PKIs.
- Support for both RSA and ECC with all EAC algorithms.
- Interoperability fixes tested with other implementation at the Prague 2008 event.
- Usability enhancements for CVC PKIs, for example download and import of binary certificates.
- Changes to the CVC cli to mimic the WS-API functions.
- Fixed that upgrade from 3.6 to 3.7 causes error when autogenerated password are used
- Other minor bugfixes.

This is a plug-in upgrade from 3.7.x. See UPGRADE for the simple instructions.
Because there are binary files in EJBCA_HOME/lib changed there is no patch file for upgrading
EJBCA 3.7.0 to 3.7.1. Use the full package from EJBCA 3.7.1 and follow the upgrade instructions in UPGRADE.

EJBCA 3.7.0

This is a major release, particularly focusing on support for CVC certificates as used in EU EAC ePassport PKI.
Read the changelog for details.

Noteworthy changes
- Support for CV Certificates (CVC) for EU EAC ePassports, you can now build a CVC PKI for EU ePassport using EJBCA.
- Upgrade of jaxb jars using for Webservice API, and new WS-API calls.
- Support for error codes in Exceptions from Webservice API.
- New service to automatically renew expiring CAs.
- Possible to use IAIK PKCS#11 provider as well as Sun PKCS#11.
- Client Tool box with client CLI tools easy to deploy stand-alone on other machines.
- Minor fixes and enhancements.
There are no database upgrades in this release.

Because there are binary files in EJBCA_HOME/lib changed there is no patch file for upgrading
EJBCA 3.6.x to 3.7.0. Use the full package from EJBCA 3.7.0 and follow the upgrade instructions in UPGRADE.

EJBCA 3.6 Release Notes

EJBCA 3.6.4

This is a minor release, only fixing one single issue.
- [ECA-921] - EjbcaHealthCheck does not work on OC4J

This is a plug-in upgrade from 3.6.x. See UPGRADE for the simple instructions.

EJBCA 3.6.3

This is a minor release, targeted for fixing a few annoying bugs.
- Upgrade fails to set internal state of CA expire time for externally signed CAs
- Key length changes when editing CA in admin-GUI
- TestProtectedLog fails if ProtectedLogDevice is not enabled in configuration
- PKCS11 support problem on OCSP responder
- LdapPublisher searches for old objects on certDN instead of Ldap DN

This is a plug-in upgrade from 3.6.x. See UPGRADE for the simple instructions.

EJBCA 3.6.2

This is a minor release but with a record amount of fixes for a point release. New features, improvements and a lot of bugfixes
rounding a lot of rough edges.

Noteworthy changes
- Major improvements to the External OCSP responder with more configuration options and
completely new Audit and Account logging. With the new, highly configurable, logging it is
suitable for using as a service charging for, and auditing, requests.
- New documentation feature with on-line documentation deployed in the Web interface by default.
Question mark links from options that are hard to understand in the Admin-GUI are now possible.
- Lots of improvements to the Admin-GUI with configuration for autogenerated passwords and fixing a lot of small GUI bugs and quirks.
- Fail over mechanism for the LDAP publisher.
- Improved documentation for more HSMs, Admin-GUI, etc.
- Improvements for other app servers apart from JBoss.
- MS document signing extended key usage, and tool for importing certificates from MS CA.
- Lots and lots of small bugfixes.
- Updated translations.

This is a plug-in upgrade from 3.6.x. See UPGRADE for the simple instructions.

EJBCA 3.6.1

This is a minor release with a few new features, from EJBCA 3.5.6, and some minor fixes.
Apart form the fixes from EJBCA 3.5.6 nCipherHSM.sh now hides the password the user enters and
an index collision in profilemappings.properties is fixed. Also an error when enrolling with approvals
activated was fixed.

This is a plug-in upgrade from 3.6.x. See UPGRADE for the simple instructions.

EJBCA 3.6.0

This is a major release with many new interesting features and framework improvements.

Noteworthy changes
- New (optional) fully clusterable log system with advanced log signing.
- Support for more extensions (FreshestCRL, caIssuers, more extended key usages, multiple policy statements)
- More WebService API commands.
- Support for Oracle Application Server and Websphere, improvements for Weblogic.
- Support for DB2 database.
- Support for delta CRLs
- Auto-enroll certificates for Microsoft systems (see ejbca.org->Howto).
- Improved PKCS#11 support for HSMs.
- OCSP improvements, support for PKCS#11 HSMs on external OCSP responder.
- External RA improvements, better configuration and SCEP improvements.
- LDAP publisher improvements.
- User notification improvements.
- New Wiki web, wiki.ejbca.org.

There are database upgrades in this release so please pay attention!

Because there are binary files in EJBCA_HOME/lib and many massive changes there is no patch file for upgrading EJBCA 3.5.x to 3.6.0. Use the full package from EJBCA 3.6.0 and follow the upgrade instructions in UPGRADE.

For the Oracle database we have made a switch from the deprecated type LONG to CLOB. Do not fear though, EJBCA 3.6 still works if you continue to use the LONG data type (i.e. does not make any changes to your database). If you decide to migrate, there is a migration sql script in src/upgrade/35_36/oracle-long-to-clob.sql.

EJBCA 3.5 Release Notes

EJBCA 3.5 Release Notes

EJBCA 3.5.12

This is a minor release, fixing a performance issue with getCerts webservice call when a single user have lots of certificates, and also an issue with authorization in UserDataSource.
- Optimize performance of findCerts WS call
- Serious bug in UserDataSource Authorization

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.11

This is a minor release, fixing two minor issues with webservice calls used by HardTokenMgmt.
- Change genTokenCertificates WS call behavior to not temporary revoke certificates for MS logon
- Fix error in EJBCAWS.genTokenCertificate temporary cards aren't revoked properly

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.10

This is a minor release, only backorting a fix done in 3.6.
- CertificateExpirationNotifier service not working on Weblogic-Oracle

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.9

This is a minor release, targeted for fixing a few annoying bugs.
- Upgrade fails to set internal state of CA expire time for externally signed CAs
- Key length changes when editing CA in admin-GUI

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.8

This is a minor release, adding two minor improvements.
- Option to Health Check to perform sign test on CA token
- Attempt to revoke a certificate.user that is already revoked generates an error

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.7

This is a minor release, fixing a few bugs.
- Deadlock under stress test involving revocation
- Importing certificate to CA with off-line token did not work
- NPE issuing some sparecard with HTMF
- Error enrolling certificate using SSL with client cert
- CRL generation for CAs waiting for certificate response throws exception

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.6

This is a minor release, fixing a few bugs and adding a new activation page to the admin-GUI.
- New activation page to effectively be able to activate many CAs quickly
- Possibility to exclude CAs from monitoring by the HealthCheckServlet
- Improve generation of CRL with the CRL worker
- Fix bugs listing many log or user entries
- Fix WS issues and a few other issues affecting hard token administration

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.5

This is a minor release, fixing a few bugs and adding support for dual authentication for CATokens.
- LDAPPublisher initialized the fakeCRL incorrectly
- Add support for the fields PostalCode and BusinessCategory, now natively supported by BouncyCastle.
- Add Approval option for activation of CAToken

EJBCA 3.5.4

This is a minor release, fixing a few bugs.
- A configuration file according to the Sun notation can now be used when creating keys on PKCS11 HSMs.
- A DB synchronization bug is fixed. Before two EJBCAs could update the log table with same sequence number.

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.3

This is a minor release, fixing a few bugs and introducing a new tool.

Noteworthy changes
- Support for AEP KeyPer HSM using the EJBCA tools.
- Fix for broken pkcs11HSM.sh.
- A new tool for stress testing over the WS-API.

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.2

This is a minor release, fixing some bugs and introducing some minor improvements.

Noteworthy changes
- Support for Luna HSM was broken
- Files for building debian package included
- Portugeese translation of Admin-GUI
- Optimized CRL generation for generating CRLs with more than 100.000 revoked certificate
- Possible to use altNames in External RA SCEP service, and require a specific password
- Several bugfixes related to using external CAs
- and other minor fixes...

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.1

This is a minor fix release, fixing an installation issue with 3.5.0 and some other minor bugs.

This is a plug-in upgrade from 3.5.x. See UPGRADE for the simple instructions.

EJBCA 3.5.0

This is a major release with many new interesting features and framework improvements.

Noteworthy changes
- PKCS#11 interface to HSMs, support for Utimaco CryptoServer, and improved auto-activation of HSMs.
- Much enhanced Webservice API for administration.
- Import CA function supports HSM, possible to create initial CA on HSM and initial admin on smart card.
- Soft CA keystores uses same framework as HSMs, possible to give private password to every soft CA.
- New options for specifying certificate validity, per end entity, fixed date etc.
- Possible to keep configuration/modifications in an external directory.
- Possible to use different profiles in CMP RA mode.
- you can now require approvals for revocation.
- Support multiple email altNames in admin-GUI.
- Option to choose reverse DN for a CA.
- Root-less install, using custom SSL truststore for JBoss/Tomcat.
- Lots of other small fixes and improvements, 69 issues resolved.

Because there are binary files in EJBCA_HOME/lib and many massive changes there is no patch file for upgrading
EJBCA 3.4.x to 3.5.0. Use the full package from EJBCA 3.5.0 and follow the upgrade instructions.

EJBCA 3.4 Release Notes

EJBCA 3.4.5

This is a patch release with only minor fixes.

Noteworthy changes
- Now it is configurable which interface JBoss http service listens to, eases hardening.
- Fixed a bug where path validation failed when using a MS-CA as External Root CA.

This is a plug-in upgrade from 3.4.x. See UPGRADE for the simple instructions.

EJBCA 3.4.4

This is a patch release with only minor fixes.

Noteworthy changes
- You can now use empty password to activate a HSM CA, which means that you can have operator cards without passwords, or that you can use module protected keys on the HSM (nCipher lingo).
- The interesting function for generating OpenVPN installers automatically for users have a fix so it works and is tested again.

This is a plug-in upgrade from 3.4.x. See UPGRADE for the simple instructions.

EJBCA 3.4.3

This is a patch release with some fixes and minor new features.

Noteworthy changes
- Support for JBoss 4.2.x
- Support RSASHA256WithRSAAndMGF1 again, this algorithm was temporarily removed for a few versions due to code cleanups.
Used mostly for electronic passports in EU.
- Support for JavaDB/Derby

The release contains binary file changes (new BC JCE provider) so no patch file is provided.

If you upgrade to JBoss 4.2.0 and have a customized conf/web.properties, remove web.jsfimpl from your conf/web.properties.

This is a plug-in upgrade from 3.4.x. See UPGRADE for the simple instructions.

Since there is a new version of the BC provider, you should run tests for yourself before upgrading in production. We have run alot of tests, but can not guard against everying related to your environment.

EJBCA 3.4.2

This is a patch release with several fixes and minor new features. There are more issues fixed then normal in a patch release, but they are mostly minor features and supposedly safe fixes.
Noteworthy changes
- many enhancements for running EJBCA smoothly on both Weblogic and Glassfish
- fixes for enrollment in windows vista
- possibility to export a soft CA keystore
- a new publisher for publishing certificates and CRL with custom made scripts
- support for SCEP RA polling mode using the external RA module
- lots of small bug fixes

This is a plug-in upgrade from 3.4.x. See UPGRADE for the simple instructions.

EJBCA 3.4.1

This is a minor release with only two bug fixes.

This is a plug-in upgrade from 3.4.x. See UPGRADE for the simple instructions.

EJBCA 3.4.0

This is a major release with many new interesting features and framework improvements.

Because there are binary files in EJBCA_HOME/lib and many massive changes there is no patch file for upgrading EJBCA 3.3.x to 3.4.0. Use the full package from EJBCA 3.4.0 and follow the upgrade instructions.

Noteworthy changes
In EJBCA 3.4.0 the default ASN.1 string encoding for DNs are now UTF8. In EJBCA 3.3.x and earlier, the default encoding was PrintableString, unless the character set forced the usage of UTF8 (international characters).
Now DN components are always encoded as UTF8 (except for components that does not allow UTF8 such as C and SerialNumber).
See UPGRADE for information regarding upgrading from an old CA, and how the behaviour can be configured.

If you used to deploy with 'deploywithjbossservices', this is now done using the regular 'deploy', but you have to set an option in conf/ejbca.properties.

EJBCA 3.3 Release Notes

EJBCA 3.3.3

This is a minor release with some improvement, most notably for LDAP.

This is a plug-in upgrade from 3.3.x. See UPGRADE for the simple instructions.

EJBCA 3.3.2

This is a minor release with some bugfixes, most notably for oracle and weblogic.

This is a plug-in upgrade from 3.3.x. See UPGRADE for the simple instructions.

EJBCA 3.3.1

This is a minor release with some bugfixes, most notably for Luna HSM.

This is a plug-in upgrade from 3.3.0. See UPGRADE for the simple instructions.

EJBCA 3.3.0

This is a major release with new features, improvements and bugfixes.

This is a plug-in upgrade from 3.2.2. See UPGRADE for the simple instructions.

EJBCA 3.2 Release Notes

EJBCA 3.2.2

This is a minor release with minor improvements and some bugfixes, mostly for MS-SQL.

This is a plug-in upgrade from 3.2.1. See UPGRADE for the simple instructions.

EJBCA 3.2.1

This is a minor release with one new features and some bugfixes.

This is a plug-in upgrade from 3.2.0. See UPGRADE for the simple instructions.

EJBCA 3.2.0

This is a release with new enterprise features and an internal restucturing of the code base.

There are database upgrades in this version (from 3.1.x).
See doc/UPGRADE for instruction how to upgrade your database.
You MUST do that!

Otherwise simply keep/copy ejbca.properties from the earlier installation.
Merge changes from ejbca.properties.sample into your ejbca.properties,
specially datasource.jndi-name and datasource.jndi-name-prefix if you changed them from the default values.
Copy the directory 'p12' from the earlier installation and 'ant deploy'
(or deploywithjbossservice) this new one.

Because there are binary files in EJBCA_HOME/lib and many massive changes there is no patch file for upgrading
EJBCA 3.1.3 to 3.2.0. Use the full package from EJBCA 3.2.0 and follow the upgrade instructions.

EJBCA 3.1 Release Notes

EJBCA 3.1.4

This is a minor release with some new features and some bugfixes.

This is a plugin-upgrade from 3.1.3. Except for the following:
Merge changes from ejbca.properties.sample into your ejbca.properties,
specially datasource.jndi-name and datasource.jndi-name-prefix if you changed them from the default values.

Otherwise simply keep/copy ejbca.properties from the earlier installation.
Merge changes from ejbca.properties.sample into your ejbca.properties.
Copy the directory 'p12' from the earlier installation and 'ant deploy'
(or deploywithjbossservice) this new one.

EJBCA 3.1.3

This is a minor release with some new features and some bugfixes.

This is a plugin-upgrade from 3.1.2.
Simply keep/copy ejbca.properties from the earlier installation, copy the directory 'p12' from the earlier installation and 'ant deploy' (or deploywithjbossservice) this new one.

Note that to fix ECA-144, 148 and 75, new version of lib/bcmail*.jar and lib/bcprov*.jar are used. Since they are binary files they are not included in the patch from version 3.1.2 to 3.1.3. You can use the patch and manually replace the jar-files from the full distribution.

The 3.1.3 release have support for RSASSA-PSS signatures to conform to the Swedish standard for MRTD certificates (Electronic Passports).
The RSASSA-PSS parameters can be seen and edited in the file src/java/se/anatom/ejbca/ca/caadmin/ExtendedX509Util.java.15

IMPORTANT, compliation using jdk1.5 is required for this algorithm.
Otherwise this algorithm option won't show up

Enhanced support for international characters in the adminweb gui (Add/Edit pages).
Should work with most languages now.

It's now also possible to select a subset of a users SubjectDN and SubjectAltName fields used in a particular kind of certificate. This is defined in the certificate profiles

EJBCA 3.1.2

This is a minor release with two new features and some bugfixes.

This is a plugin-upgrade from 3.1/3.1.1. Simply keep ejbca.properties from the earlier release, and 'ant deploy' this new one.

Note that to fix ECA-126, a new version of lib/bcmail-jdk14.jar and lib/bcprov-jdk14.jar are used. Since they are binary files they are not included in the patch from version 3.1 to 3.1.2. You can use the patch and manually replace the jar-files.

EJBCA 3.1.1

This is a minor release with a few small bugfixes found in the 3.1 release.

This is a plugin-upgrade from 3.1.

EJBCA 3.1

This is a major release including many new features, improvements, and bug fixes.

We are very proud of this release and recommend an upgrade.

This is mostly a plugin-upgrade from 3.0.7, no database changes needed.

Since the changes are massive, no patch file is provided.

To upgrade from 3.0.x follow doc/UPGRADE.

EJBCA 3.0 Release Notes

EJBCA 3.0.7

This is a plugin-upgrade from 3.0.6 or 3.0.5.
Apply patch, build and redeploy.

EJBCA 3.0.6

This is a plugin-upgrade from 3.0.5. 

Apply patch, build and redeploy.

If you are using the hard token stuff on MySQL (which you probably aren't or you would have noticed
this bug), you should drop the table HardTokenData and restart JBoss to recreate the table.

EJBCA 3.0.5

This is a plugin-upgrade from 3.0.4. 

Apply patch, build and redeploy.

For users of MS SQL 2000 you should note the column name 'rule_' (earlier 'rule' which is
a reserved word) in the table AccessRulesData.

EJBCA 3.0.4

This is a plugin-upgrade from 3.0.3. 

Apply patch, build and redeploy.

EJBCA 3.0.3

The database table 'hardtokenprofiledata' using the database HypersonicSQL changed. 

If you are using the hardtoken functionality on the HypersonicSQL database
(which you should not be doing in production), the table must be removed and
recreated. No migration script is provided since we don't anticipate anyone using
this combination in production.

EJBCA 3.0

EJBCA 3.0 is a major new release taking the Open Source CA to new heights.
The most important improvment is that it is now possible to run several
PKI infrastructures within one single instance of EJBCA. Among other major improvements are also
complete support for OCSP, enanced Hard token interface and flexible
LDAP configuration through the Web-GUI.

This is a plugin-upgrade from beta3.

This release is not backwards compatible with EJBCA 2.1 without database upgrade.
Upgrade instructions must be followed if upgrading from EJBCA 2.1,
backup your database before trying any upgrades.

EJBCA 3.Beta3

This is a plugin-upgrade from beta2.
There is an upgrade function from EJBCA2->EJBCA3 for the MySQL database, see doc/UPGRADE.

EJBCA 3.0Beta2

Thanks to a bug in Beta1 the database table 'HardTokenPropertyData' has changed. If you have been
using the HardToken features in Beta1, or plan to use them in the future, this table must be rebuilt.
'drop table hardtokenpropertydata' will delete and rebuild the table (data must be entered again).

Apart from this, it is a plug-in upgrade.

EJBCA 3.0beta1

EJBCA 3.0 is a major new release taking the Open Source CA to new heights.
The most noteworthy change is that it is now possible to run a complete (or several)
PKI infrastructure within one single instance of EJBCA.

This release is not backwards compatible with EJBCA 2.1 without database upgrade.
Upgrade instructions must be followed if upgrading from EJBCA 2.1,
backup your database before trying any upgrades.

The (default) LDAP schema has been changed to follow RFC 2256. If using LDAP,
the schema should be checked. You can configure the schema
(in ca/ca/META-INF/ejb-jar.xml) to be the same as before if needed.

EJBCA 2.1 Release Notes

EJBCA 2.1.2

This is a plugin upgrade from V2.1.

The (default) LDAP schema has been changed to follow RFC 2256. If using LDAP,
the schema should be checked. You can configure the schema
(in ca/ca/META-INF/ejb-jar.xml) to be the same as before if needed. See HOWTO-LDAP.txt.

EJBCA 2.1.1

This is a plugin upgrade from V2.1.

EJBCA 2.1

New method to revoke certificates with external publishers.

EJBCA 2.0 Release Notes

EJBCA 2.0.1

Except from notes below this is a plugin upgrade from v2.0.

Java >= 1.4 is now required.

Delete bcmail-jdk13*, jce-jdk13*, ldap.jar and regexp1_0_0.jar
from $JBOSS_HOME/server/default/lib.

EJBCA 2.0

Name of initial temporary super administrator changed from "CN=Walter" to "CN=SuperAdmin". A new must be created.

All defined administrator privileges must be redefined.

Certificate profiles should be redefined.

Drop tables GlobalConfigurationData, AdminGroupData,AdminEntityData,AccessRulesData and EndEntityProfileData to flush configuration and administrator privileges (actually deleting the content would be enough but you
might as well drop the tables).

Delete bcmail-jdk13-116.jar, jce-jdk13-116.jar, ldap.jar and regexp1_0_0.jar from $JBOSS_HOME/server/default/lib.

EJBCA 2.0B1

We have moved to EJB 2.0. JBoss 3 is now required. A complete reinstall from EJBCA 1.x is required, old jars, wars and ears must be deleted.
Database schema has changed, old data in the database must be migrated.
A Web GUI for administration is available through https, see doc/README for installation instructions.

EJBCA 1.0 Release Notes

EJBCA 1.3

This is a plugin upgrade from v1.2 or 1.1. Just build and deploy the new files.

EJBCA 1.2

This is a plugin upgrade from v1.1. Just build and deploy the new files.

EJBCA 1.1

Upgrading from version 1.0:

If upgrading from version 1.0 the database tables need to be migrated if the DN attributes L or ST have been used. This is because the ordering of those attributes have changed (for string matching the order must be defined).

If L or ST have not been used in DNs, migration is NOT needed.

What need to be done are to:
1. Read column with DN to me migrated from table.
2. Run 'newDN=CertTools.stringToBCDNString(oldDN)'.
3. Update column with DN in table.

Columns that need updating are:
issuerDN in table CRLData
subjectDN, issuerDN in table CertificateData
subjectDN in table UserData.

If a tool is needed to perform the migration, please contact us. See http://sourceforge.net/projects/ejbca