EJBCA 7.6.0 Release Notes

JUNE 2021

The PrimeKey EJBCA team is pleased to announce the release of EJBCA 7.6.0.

This release continues this spring's push to develop EJBCA as the preeminent solution for Enterprise PKIs, with further integration with Microsoft PKIs. It also brings to light External Account Bindings, an important concept for anybody needing to handle large volumes of device certificates. Included in this release are also the changes made in EJBCA 7.5.1, which was only released internally. 

Deployment options include EJBCA Hardware Appliance, EJBCA Software Appliance, and EJBCA Cloud.

Highlights

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-2 Level 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. 

Upgrade Information

Review the EJBCA 7.6.0 Upgrade Notes for important information about this release. For upgrade instructions and information on upgrade paths, see Upgrading EJBCA.

EJBCA 7.6.0 is included in EJBCA Hardware Appliance 3.8.0 and EJBCA Cloud 2.7.0 and can be deployed as EJBCA Software Appliance.

Change Log: Resolved Issues

For full details of fixed bugs and implemented features in EJBCA 7.6.0, refer to our JIRA Issue Tracker.

Issues Resolved in 7.6.0

Issues Resolved in 7.5.1