EJBCA 8.0 Upgrade Notes

Below are important changes and requirements when upgrading from EJBCA 7.x to EJBCA 8.0.

For upgrade instructions and information on upgrade paths, see Upgrading EJBCA. For details of the new features and improvements in this release, see the EJBCA 8.0 Release Notes.

New packages need to be added to logger

In EJBCA 8.0, some code has been migrated to the com.keyfactor package. To configure the log level for these classes, perform the following operation against the JBoss CLI:

BASH

/opt/wildfly/bin/jboss-cli.sh --connect '/subsystem=logging/logger=com.keyfactor:add(level=INFO)'

TLS v1.3 Support

As of EJBCA 8.0, TLS v1.3 cipher suites are supported for features such as Peer connections. In order to utilize it, TLS v1.3 has to be configured for your application server. For more information about configuring TLS for your application server, see the corresponding Configure TLS section for your Application Server.

Deprecated algorithms affecting MS auto-enrollment

The RC4 algorithm has been deprecated since Java 8 and removed in later versions. With Java 11 as the new baseline, auto-enrollment deployments using RC4 in their Kerberos configuration will fail with the following error:

CODE

 WARN  [org.ejbca.msae.Krb5TicketValidateAction] (default task-5) Invalid ticket for HTTP/ejbcaserver.yourcompany.com@YOURCOMPANY.COM: java.security.PrivilegedActionException:
Failure unspecified at GSS-API level (Mechanism level: Encryption type RC4 with HMAC is not supported/enabled)

Resolution

Update krb5.conf, keytab as well as the service account configured for the auto-enrollment alias to support AES instead. You may also need to purge to old RC4 Kerberos ticket before the change takes effect.
Add "allow_weak_crypto" in krb5.conf (not recommended)

Configuration change for MSSQL and Postgres users

Due to differences between databases in how batches are read, MSSQL and PostgreSQL installations should have database.crlgenfetchordered set to 'true'. For more information, see cesecore.properties in Managing EJBCA Configurations.

Changed Transaction Handling in Enrollment Protocols

In order to support parallel enrollment requests with the same username (ECA-4347), the handling of database insertion/updates of end-entities has been changed in several enrollment operations. This affects the following enrollment protocol operations and enrollment APIs:

EST: simpleenroll in RA mode
CMP: IR & CR requests in RA mode
REST API: /v1/certificate/pkcs10enroll
EjbcaWS SOAP API: The certificateRequest method

The following changes have been made:

End entity updates are suppressed if there are no meaningful changes:
- If only the modification timestamp changed.
- For end entities that enter the GENERATED state, changes of the password hash are also ignored.
End entity insertions/updates are run in a separate transaction, and conflicts are ignored, if:
- A new end entity is being created.
- The end entity is in GENERATED state, and after the enrollment operation, it remains in GENERATED state.

Unintended API Breakage in Peer Connections

The 8.0 release contained two unintended API breakages in Peer Connections. This can cause enrollment, search and key recovery to fail when one, but not both, of the CA and the RA is running 8.0.

In EJBCA 8.0.0.1 an initial fix was made, but it did not fully resolve all problems (ECA-11731).

In EJBCA 8.2.0.2 the API was restored to work as in 7.x again (ECA-12067).

CA version	RA version	Status
<=7.x	<=7.x	Works
<=7.x	8.0	Not working
<=7.x	>=8.0.0.1	Not working
<=7.x	>=8.2.0.2	Works
8.0	<=7.x	👎 Unsupported. Not working
8.0	8.0	Works
8.0	>=8.0.0.1	Key recovery does not work. Other operations work
>=8.0.0.1	<=7.x	👎 Unsupported, but works.
>=8.0.0.1	8.0	👎 Unsupported. Not working.
>=8.0.0.1	>=8.0.0.1	Works