Relution Signet Customer Hub

Serverstart bei S3 mit selbstsigniertem Zertifikat

Nach einem Update von einer Version vor 26.2 direkt auf Relution 26.4 oder neuer startet der Server nicht mehr, wenn der angebundene S3-Objektspeicher über TLS mit einem selbstsignierten oder unternehmensinternen Zertifikat erreichbar ist. Im Log erscheint folgender Fehler:

2026-08-18 10:06:09.875 ERROR 12 [ main] s.boot.SpringApplication: Application run failed []
AccessDeniedException: software.amazon.awssdk.core.exception.SdkClientException: Unable to execute HTTP request: (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (SDK Attempt Count: 3)

Ursache

Beim Start liest Relution das Signaturzertifikat für JWT aus dem konfigurierten Objektspeicher. Ist das Zertifikat der ausstellenden CA nicht als vertrauenswürdig hinterlegt, schlägt die TLS-Verbindung zum S3-Endpunkt fehl und der Startvorgang bricht ab.

Drei Änderungen wirken dabei zusammen:

  • Seit Relution 5.27 werden Ressourcen bei konfiguriertem Objektspeicher dorthin ausgelagert. Davon betroffen sind auch Zertifikate und damit das Signaturzertifikat für JWT.
  • Mit Relution 26.2 werden Zertifikate als sicherheitsrelevant eingestuft und dauerhaft in der Datenbank gehalten. Bereits ausgelagerte Zertifikate werden dabei automatisch aus dem Objektspeicher zurück in die Datenbank migriert.
  • Mit Relution 26.4 werden CA-Zertifikate nicht mehr im Betriebssystem des Containers, sondern in der Datenbank hinterlegt und über die Benutzeroberfläche verwaltet (siehe CA-Zertifikat in Docker →). Damit setzt das Hinterlegen des Zertifikats einen laufenden Server voraus, während der Server umgekehrt erst startet, wenn dem Zertifikat bereits vertraut wird.

Erfolgt das Update in Zwischenschritten über 26.2 oder 26.3, liegt das Signaturzertifikat nach der Rückmigration wieder in der Datenbank, sodass der Start unter 26.4 keinen Zugriff auf den Objektspeicher mehr benötigt. Ausschließlich bei einem direkten Update von einer Version vor 26.2 auf 26.4 oder neuer unterbleibt diese Rückmigration, während zugleich das CA-Zertifikat nicht mehr über das Betriebssystem hinterlegt werden kann.

Lösung

Damit der Server startet, wird das betroffene Signaturzertifikat aus der Datenbank entfernt. Beim nächsten Start erzeugt Relution ein neues Signaturzertifikat und legt dieses in der Datenbank ab, sodass für den Startvorgang kein Zugriff auf den Objektspeicher erforderlich ist.

Erforderliche Schritte:

  1. Der Relution-Dienst wird gestoppt.
  2. Der Datensatz des Signaturzertifikats wird mit der nachfolgenden Anweisung aus der Datenbank entfernt.
  3. Der Relution-Dienst wird gestartet.

Für PostgreSQL wird der Spaltenname usage in doppelte Anführungszeichen gesetzt. In MariaDB ist usage ein reserviertes Schlüsselwort und wird dort in Backticks gesetzt.

PostgreSQL:

DELETE FROM mdm_crtfct WHERE "usage" = 'JWT_SIGNER_CERTIFICATE';

MariaDB:

DELETE FROM mdm_crtfct WHERE `usage` = 'JWT_SIGNER_CERTIFICATE';

Auswirkungen

Mit dem folgenden Start wird ein neues Signaturzertifikat für JWT erzeugt. Die bestehenden Anmelde-Cookies sind damit ungültig, sodass eine erneute Anmeldung aller Benutzer erforderlich ist.

Nach dem Serverstart

Nach dem erfolgreichen Start wird das Zertifikat der internen CA nachgetragen, damit die Verbindung zum Objektspeicher wieder als vertrauenswürdig eingestuft wird:

  • Die Anmeldung erfolgt in der globalen Organisation.
  • Unter Einstellungen → Zertifikate wird das Zertifikat der internen CA hochgeladen (siehe Zertifikatsverwaltung →).
  • Unter Einstellungen → TLS-Vertrauenskonfiguration → Vertrauenswürdige Zertifikate wird das hochgeladene Zertifikat über Zertifikat hinzufügen aus der Zertifikatsbibliothek ausgewählt.

Die Übernahme erfolgt im laufenden Betrieb, ein weiterer Neustart des Servers ist dafür nicht erforderlich. Anschließend werden auch die übrigen sicherheitsrelevanten Zertifikate — etwa das Signaturzertifikat für externe Dienste und das SCEP-CA-Zertifikat — aus dem Objektspeicher in die Datenbank übernommen.

Weitere Hinweise

  • Wird der Objektspeicher ohne TLS oder mit einem öffentlich vertrauenswürdigen Zertifikat angebunden, tritt das Problem nicht auf.
  • Die Rückmigration der Zertifikate in die Datenbank erfolgt über einen Hintergrundjob, der standardmäßig einmal täglich ausgeführt wird. Bei einem Update in Zwischenschritten ist daher sicherzustellen, dass die Migration unter 26.2 oder 26.3 abgeschlossen ist, bevor auf 26.4 aktualisiert wird.
  • Die Konfiguration des Objektspeichers ist unter Relution konfigurieren → beschrieben.