Release Notes

Bei Verwendung des Generic HSM-Moduls in Kombination mit einem Luna HSM, das per PKCS#11 angebunden wird, kam es unter bestimmten Umständen zu Problemen bei der Verbindung zum HSM. Das Problem bestand seit CARA Version 3.2.0. Es wurde behoben.

Das GenericHSM-Modul unterstützt nun den PQC-Algorithmus ML-DSA. Voraussetzung für die Verwendung des Algorithmus ist die Unterstützung durch das angebundene HSM.

Nach dem Hibernate-Update im Rahmen der Spring Boot 3-Migration war es unter MariaDB 10.7+ nicht mehr möglich, neue OIDC-Benutzer anzulegen. Das Problem wurde behoben.
Ab dieser CARA-Version unterstützt CARA offiziell MariaDB 11.4. Entwicklung und Tests erfolgen nun unter dieser Version.

Bei Verwendung des OCSP-Responder-Moduls können nun auch PQC-Algorithmen zur Signierung von OCSP-Responses verwendet werden. Im Admin-Frontend stehen dabei nur noch Signaturalgorithmen zur Auswahl, die mit dem Schlüssel des gewählten CA-Zertifikats bzw. des gewählten EE-Signers kompatibel sind.

Für die Entschlüsselung von SCEP-Nachrichten wird RSA mit OAEP-Padding nun auch für Schlüssel unterstützt, die sich auf einem Generic HSM-Device befinden. Bisher konnte in diesem Fall nur PKCS#1-Padding für die Entschlüsselung verwendet werden. Voraussetzung ist eine Unterstützung des Verfahrens durch das jeweilige HSM.

Bei Verwendung des Generic HSM-Moduls in Kombination mit einem Luna HSM wird nun das Enhanced Cryptoki User Model unterstützt. Es erlaubt eine Rollentrennung zwischen Crypto Officer (CO) und Crypto User (CU). Die jeweilige Benutzerrolle muss bei der Anmeldung am HSM über das CARA Admin-Frontend ausgewählt werden. Die Änderungen betreffen die Luna HSM-Anbindung per Java-API und per PKCS#11.

Keycloak-Clients können sich nun auch an der CARA-WS-API sowie der Admin-API authentifizieren. In CARA muss dazu eine passende Applikation existieren, deren App-ID der Keycloak-Client-ID entspricht und die eine Applikationsrolle mit den für den Aufruf benötigten Rechten besitzt. Ähnlich wie für OIDC User ist auch eine automatische Synchronisation für Keycloak-Clients als Applikationen möglich.

In speziellen Fehlersituationen beim Wiederherstellen einer HSM-Verbindung konnte es vorkommen, dass eine kryptische Fehlermeldung erschien oder der Verbindungszustand nicht korrekt angezeigt wurde. Dies wurde behoben.

Die Suche nach EE- und RA-Zertifikaten nach Status wurde erweitert. Es gibt nun getrennte Suchfelder für den Request-Status und den Zertifikats-Status. Es ist damit zum Beispiel möglich, explizit nach noch aktiven Zertifikaten (nicht gesperrt und nicht abgelaufen) zu suchen.

Die Suchkriterien für die Suche nach EE- und RA-Zertifikaten wurden um den Zertifikats-Issuer erweitert. Es ist damit möglich, alle Zertifikate eines bestimmten Issuers anzuzeigen.

Die erweiterte Suche nach Zertifikats-Templates bietet nun auch eine Möglichkeit zur Filterung nach Templates vom Typ "RA" bzw. "OIDC".

Es ist für das CARA Admin-Frontend nun möglich, die Client-ID des Keycloak-Clients zu konfigurieren. Zudem wird der Keycloak-Realm-Name jetzt aus der Basis-URL des Keycloak-Realms gelesen. Vorher war der Realm-Name auf mtg-ers festgesetzt.

Bei Verwendung des OCSP-Responder-Moduls war es beim Bearbeiten von OCSP-Response-EE-Signern nicht möglich, einem bestehenden OCSP-Response-EE-Signer einen neuen EE-Signer zuzuordnen. Stattdessen musste der vorhandene OCSP-Response-EE-Signer gelöscht und ein neuer angelegt werden. Das Problem wurde behoben.

Bei Verwendung von PostgreSQL als Datenbank-System kam es im Log des CARA-Servers zu einer Häufung von PSQLExceptions. Ursache war ein Fehler im Transaction Handling. Der Fehler wurde behoben.

Wenn keine Utimaco-Bibliothek vorhanden war, wurde auf der Status-Seite im Admin-Frontend ein Fehler angezeigt. Da es sich dabei nicht um einen Fehlerfall handelt, kommt es nun nicht mehr zu einer Exception.

Wenn die Master-Passphrase beim Erstellen eines Passwort-Sicherungsschlüssels nicht gespeichert wurde, war es nicht möglich sie zum Speichern von Passwörtern für die Login-Wiederherstellung zu verwenden. Dieses Problem wurde behoben. Ferner ist es nun auch wieder möglich, einen neuen Passwort-Sicherungsschlüssel anzulegen, wenn schon einer existiert. Dabei wird der vorhandene Schlüssel überschrieben.

CARA verwendet nun Spring Boot 3. Im Rahmen der Migration wurden zahlreiche Bibliotheken aktualisiert, in der Regel auf die von Spring Boot vorgesehene Version.

Die vom Generic HSM-Modul unterstützte Luna-Client-Version wurde auf 10.5 angehoben. Ältere Versionen des Luna-Clients werden nicht mehr unterstützt.

Der CARA Software-Schlüsselgenerator unterstützt nun den hybriden Algorithmus Composite ML-DSA. Dabei handelt es sich um eine Kombination aus dem PQC-Algorithmus ML-DSA und einem klassischen Algorithmus wie zum Beispiel RSA oder ECDSA. Damit is es erstmals möglich, auch hybride Zertifikate (im Speziellen: Composite-Zertifikate) in CARA zu generieren.
 
Wichtiger Hinweis: Für den Moment handelt es sich hierbei um ein experimentelles Feature. Die Implementierung basiert auf Version 15 des Internet-Drafts draft-ietf-lamps-pq-composite-sigs-15. Das Feature wird nach Erscheinen des offiziellen RFCs finalisiert.

Standardmäßig überprüft CARA nun auch für ML-DSA, Composite ML-DSA und SLH-DSA-Schlüssel, ob die festgelegte Kombination an Key-Usage-Bits zulässig ist. Die Grundlage dafür bilden RFC 9881 und RFC 9909. Die Prüfung kann über das skipOptionalX509certificateChecks-Flag im CARA-Server deaktiviert werden.

Einige CA-Policies verlangen bei der Außerbetriebnahme einer CA die Veröffentlichung einer Sperrliste (CRL) mit dem speziellen nextUpdate-Wert "9999-12-31 23:59:59Z". Die Funktion zur manuellen CRL-Erstellung wurde um eine zusätzliche Checkbox erweitert, mit der dieses spezielle nextUpdate-Datum gesetzt werden kann. Die Erstellung weiterer CRLs wird durch diese Einstellung nicht automatisch unterbunden und muss organisatorisch sichergestellt werden (etwa durch das Löschen bestehender CRL-Jobs sowie durch die Vernichtung des CRL-Signaturschlüssels).

Die API-Spezifikation der Admin-API ist nun nicht mehr abrufbar und nicht mehr Teil der Swagger UI.
 
Wichtiger Hinweis: Die Admin-API ist nur für die Nutzung durch das Admin-Frontend vorgesehen. Es handelt sich nicht um eine offene, für Kunden dokumentierte und zur Anwendungsentwicklung vorgesehene API.

Die Suche nach Zertifikats-Templates liefert nun auch Echtzeit-Ergebnisse während der Eingabe des Suchbegriffs und funktioniert damit analog zu den anderen Suchen. Die Optionen für die Suche in der Beschreibung der Zertifikats-Templates und die Suche nach fehlerhaften Zertifikats-Templates wurde in die erweiterte Suche verschoben.

Bei der Suche nach EE-Zertifikaten sind die verfügbaren Verwendungszwecke nun abhängig von der ausgewählten Virtual CA.

Der CARA Software-Schlüsselgenerator unterstützte bisher nur die Generierung von SLH-DSA-Schlüsseln, nicht jedoch von HashSLH-DSA-Schlüsseln. Wenn ein SLH-DSA-Schlüssel verwendet werden soll, um Pre-Hash-Signaturen zu generieren, muss dies bereits bei der Schlüsselgenerierung festgelegt werden. HashSLH-DSA-Schlüssel werden durch eine andere OID identifiziert als "Pure SLH-DSA"-Schlüssel. Ein "Pure SLH-DSA"-Schlüssel darf nicht zur Generierung von Pre-Hash-Signaturen verwendet werden, während ein HashSLH-DSA-Schlüssel nicht zur Generierung von "Pure"-Signaturen verwendet werden darf. Dies wird nun von CARA sichergestellt.
 
Die Schlüsselgenerierung von SLH-DSA-Schlüsseln wurde im Rahmen dieses Bugfixes grundlegend überarbeitet. Im CARA Admin-Frontend muss bei der Generierung von SLH-DSA-Schlüsseln jetzt keine Kombination von Security Level, Performance Variante und Hashfunktion mehr ausgewählt werden. Stattdessen existiert eine Auswahlmöglichkeit für den vollständigen Parametersatz (Algorithmus-Variante), z. B. SLH-DSA-SHA2-256f.

Beim Anlegen eines neuen Template-Signers überprüft CARA, ob der Signer-Schlüssel zum im Template konfigurierten Signaturalgorithmus passt. Bei der Überprüfung wurden PQC-Algorithmen bisher nicht berücksichtigt, sodass das Anlegen eines Template-Signers mit PQC-Schlüssel nicht möglich war. Dies wurde behoben.

Um zu bewirken, dass die OpenAPI-Spezifikation der CARA-WS-API inklusive Swagger UI nicht abrufbar ist, konnte bisher das Property api.documentation.public auf false gesetzt werden. Nach einer Library-Umstellung war dieses Property wirkungslos. In dieser Version wurde die Unterstützung für dieses Property entfernt. Stattdessen können die Springdoc-Standard-Properties springdoc.api-docs.enabled und springdoc.swagger-ui.enabled verwendet werden, um die Erreichbarkeit der OpenAPI-Spezifikation feingranular zu steuern.

Bei der Verarbeitung von OCSP-Requests, wie sie zum Beispiel bei Verwendung des CARA Revocation Info Servers erfolgt, kam es zu einer LazyInitializationException. Der Fehler ist durch die technische Modernisierung des Datenbank-Layers entstanden und wurde in dieser Version behoben.

Wenn ein Benutzer aus Keycloak in die CARA-Datenbank synchronisiert wird, können die Rollen ausgewählt werden, die dem Benutzer automatisch zugewiesen werden sollen. Bei der Synchronisation über die Detailseite eines Benutzers wurde die SuperAdmin-Rolle nicht korrekt zugewiesen, wenn die Option "Admin-User-Rollen" ausgewählt war. Wurde die Synchronisation hingegen über die Benutzer-Tabelle durchgeführt und waren dort mehrere nicht synchronisierte Benutzer sichtbar, konnten keine Rollen ausgewählt werden. Beide Fehler wurden behoben.