Release Notes

The CARA software key pair generator now supports the PQC algorithm ML-KEM. Since ML-KEM is not a signature algorithm, EE certificates can be issued with ML-KEM keys, but CA certificates and PKCS#10 requests cannot.

The Spring Boot Actuator has been extended with the /actuator/info endpoint. It is enabled by default and can be used to retrieve the installed CARA version.

Previously, the CARA Admin CLI started a web server during startup, although it was not required. This could lead to port conflicts. Now, the web server is no longer started.

The CA certificate search has been extended. It is now possible to filter the results by status, validity start date, and validity end date. In addition, the existing "Certificate Type" search criterion has been split into two separate search criteria.

Under MariaDB, the data type TEXT was previously used for the encoded revocation list (column ENCODED_CRL in the table CRL). This meant that very large revocation lists could not be stored in the database. The data type has now been changed to LONGTEXT.

A database index for case-insensitive searches of ident data was missing. The index has been added for Oracle and PostgreSQL. An equivalent index is currently not available for MariaDB.

The English label for the revocation reason "Superseded" was incorrect. This has been corrected.

The GenericHSM module now supports the PQC algorithm SLH-DSA. A prerequisite is that the algorithm is supported by the respective HSM.

When a new CA certificate is issued in the CARA Admin frontend, the suggested "Valid To" date is calculated based on the default validity defined in the certificate template. This calculation takes various constraints into account, such as the maximum validity specified in the template. The date can then be adjusted manually. In previous CARA 3 versions, manual modifications of the date did not take effect. This issue has been fixed.

Under certain conditions, connection issues to the HSM could occur when using the Generic HSM module together with a Luna HSM connected via PKCS#11. The issue existed since CARA version 3.2.0 and has now been resolved.

The GenericHSM module now supports the PQC algorithm ML-DSA. A prerequisite is that the algorithm is supported by the respective HSM.

After the Hibernate update that was performed as part of the Spring Boot 3 migration, it was no longer possible to create new OIDC users under MariaDB 10.7+. The problem has been fixed.
Starting with this CARA version, CARA officially supports MariaDB 11.4. Development and testing are now performed using this version.

When using the OCSP Responder module, it is now possible to sign OCSP responses using PQC algorithms. In the Admin frontend, the list of available signature algorithms is now dynamically filtered: once a CA certificate or EE signer is selected, only compatible signature algorithms are shown.

For the decryption of SCEP messages, RSA with OAEP padding is now also supported for keys located on a Generic HSM device. Previously, only PKCS#1 padding could be used for decryption in this case. A prerequisite is that the procedure is supported by the respective HSM.

When the Generic HSM module is used in combination with a Luna HSM, CARA now supports the Luna Enhanced Cryptoki User Model. It allows a separation of roles between Crypto Officer (CO) and Crypto User (CU). The respective user role must be specified when logging in to the HSM via the CARA Admin frontend. The changes affect the Luna HSM connection via the Java API and via PKCS#11.

Keycloak clients can now also authenticate against the CARA-WS API and the Admin API. For this purpose, a corresponding application must exist in CARA whose app ID matches the Keycloak client ID and which has an application role with the permissions required for the API call. Similar to OIDC users, automatic synchronization for Keycloak clients as applications is also possible.

In specific error scenarios when restoring an HSM connection, it could happen that a cryptic error message appeared or the connection status was not displayed correctly. This has been fixed.

The search for EE and RA certificates by status was extended. There are now separate search fields for the request status and the certificate status. This makes it possible, for example, to explicitly search for certificates that are still active (not revoked and not expired).

The search criteria for EE and RA certificates have been extended to include the certificate issuer. This makes it possible to display all certificates from a specific issuer.

The advanced search for certificate templates now also includes an option to filter the templates by type "RA" or "OIDC".

It is now possible to configure the client ID of the Keycloak client in the CARA Admin frontend. Additionally, the Keycloak realm name is now read from the base URL of the Keycloak realm. Previously, the realm name was fixed to mtg-ers.

When using the OCSP Responder module, the EE signer related to an OCSP response EE signer could not be updated. Instead, the existing OCSP response EE signer had to be deleted and a new one had to be created. The problem has been solved.

When using PostgreSQL as the database system, there was an increased number of PSQLExceptions in the CARA server log. The cause was an error in the transaction handling. This issue has been fixed.

If no Utimaco library was available, an error was displayed on the status page in the Admin frontend. Since this is not actually an error condition, it no longer results in an exception.

If the master passphrase was not saved upon password encryption key creation, it was not actually possible to use the encryption key for saving passwords for login recovery. This problem has been fixed. Furthermore, it is now possible again to create a new password encryption key even if one already exists. In this case, the existing key is overwritten.

CARA now uses Spring Boot 3. As part of the migration, numerous libraries were updated, generally to the versions defined by Spring Boot. The most important changes are:

The Luna client version supported by the Generic HSM module was updated to 10.5. Older versions of the Luna client are no longer supported.

The CARA software key pair generator now supports the hybrid algorithm Composite ML-DSA. It is a combination of the PQC algorithm ML-DSA and a traditional algorithm such as RSA or ECDSA. This enables the generation of hybrid certificates (specifically: composite certificates) in CARA.
 
Important note: For the moment, this is an experimental feature. The implementation is based on version 15 of the Internet-Draft draft-ietf-lamps-pq-composite-sigs-15. The feature will be finalized after the publication of the official RFC.

By default, CARA now checks for ML-DSA, Composite ML-DSA and SLH-DSA keys whether the specified combination of key usage bits is allowed. The check is based on RFC 9881 and RFC 9909. It can be disabled in the CARA server via the skipOptionalX509certificateChecks flag.

Some CA policies require that, upon decommissioning a CA, a Certificate Revocation List (CRL) be published with the special nextUpdate value "9999-12-31 23:59:59Z". The manual CRL generation function has been extended with an additional checkbox that allows this specific nextUpdate date to be set. The creation of further CRLs is not automatically prevented by this setting and must be ensured through organizational measures (e.g., by deleting existing CRL jobs and destroying the CRL signing key).

The OpenAPI specification of the Admin API is no longer accessible or included in the Swagger UI.
 
Important Note: The Admin API is intended solely for use by the Admin frontend. It is not a public API, and it’s not documented for customers or designed for application development.

The certificate template search now shows real-time results as you type, just like the other search functions. Options for searching within template descriptions and for finding invalid templates have been moved to the advanced search.

When searching for EE certificates, the available certificate usages now depend on the selected Virtual CA.

The CARA software key pair generator previously only supported the generation of SLH-DSA keys but not of HashSLH-DSA keys. If an SLH-DSA key is intended for generating pre-hash signatures, this must be defined at the time of key generation. HashSLH-DSA keys are identified by a different OID than pure SLH-DSA keys. A pure SLH-DSA key must not be used for generating pre-hash signatures, while a HashSLH-DSA key must not be used for generating pure signatures. CARA now enforces this restriction.
 
As part of this bug fix, SLH-DSA key generation has been fundamentally redesigned. In the CARA Admin frontend, it is no longer necessary to select a combination of security level, performance variant, and hash function when generating SLH-DSA keys. Instead, a single selection for the complete parameter set (algorithm variant) is available, e.g., SLH-DSA-SHA2-256f.

During template signer creation, CARA checks whether the signer key is compatible with the signature algorithm in the template. Until now, this check did not take PQC algorithms into account, so that creating a template signer with a PQC key was not possible. The issue has been resolved.

To ensure that the OpenAPI specification of the CARA-WS-API including the Swagger UI cannot be accessed, the property api.documentation.public could previously be set to false in the CARA server. A library change rendered this property ineffective. In this version, support for the property has been removed. As a replacement, the default Springdoc properties springdoc.api-docs.enabled and springdoc.swagger-ui.enabled provide more granular control over OpenAPI specification availability.

A LazyInitializationException could occur during OCSP request handling, e.g., when using the CARA Revocation Info Server.

When synchronizing a user from Keycloak to the CARA database, roles can be selected for automatic assignment.