Relution Signet Customer Hub

Server startup with a self-signed S3 certificate

After updating from a version earlier than 26.2 directly to Relution 26.4 or newer, the server no longer starts if the connected S3 object storage is reached over TLS using a self-signed or company-internal certificate. The following error appears in the log:

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)

Cause

During startup, Relution reads the JWT signer certificate from the configured object storage. If the certificate of the issuing CA is not registered as trusted, the TLS connection to the S3 endpoint fails and the startup is aborted.

Three changes interact here:

  • Since Relution 5.27, resources are offloaded to the object storage whenever one is configured. This also affects certificates and therefore the JWT signer certificate.
  • With Relution 26.2, certificates are classified as security-sensitive and are kept in the database permanently. Certificates that were already offloaded are automatically migrated back from the object storage into the database.
  • With Relution 26.4, CA certificates are no longer stored in the container operating system but in the database, and are managed through the user interface (see CA certificate in Docker →). Adding the certificate therefore requires a running server, while the server in turn only starts once the certificate is already trusted.

If the update is performed in intermediate steps via 26.2 or 26.3, the signer certificate is back in the database after the reverse migration, so that the 26.4 startup no longer requires access to the object storage. Only when updating directly from a version earlier than 26.2 to 26.4 or newer does this reverse migration not take place, while at the same time the CA certificate can no longer be added through the operating system.

Solution

To allow the server to start, the affected signer certificate is removed from the database. On the next startup, Relution generates a new signer certificate and stores it in the database, so that no access to the object storage is required for the startup.

Required steps:

  1. The Relution service is stopped.
  2. The record of the signer certificate is removed from the database using the statement below.
  3. The Relution service is started.

For PostgreSQL, the column name usage is enclosed in double quotes. In MariaDB, usage is a reserved keyword and is enclosed in backticks there.

PostgreSQL:

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

MariaDB:

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

Impact

A new JWT signer certificate is generated during the following startup. The existing login cookies become invalid as a result, so all users have to sign in again.

After the server startup

Once the server has started successfully, the certificate of the internal CA is added so that the connection to the object storage is considered trusted again:

  • Sign in to the global organization.
  • Under Settings → Certificates, the certificate of the internal CA is uploaded (see Certificate management →).
  • Under Settings → TLS Trust configuration → Trusted certificates, the uploaded certificate is selected from the certificate library via Add certificate.

The change is applied while the system is running; no further restart of the server is required. Afterwards the remaining security-sensitive certificates — such as the signer certificate for external services and the SCEP CA certificate — are moved from the object storage into the database as well.

Additional notes

  • If the object storage is connected without TLS or with a publicly trusted certificate, the problem does not occur.
  • The reverse migration of the certificates into the database is performed by a background job that runs once a day by default. When updating in intermediate steps, it must therefore be ensured that the migration has completed under 26.2 or 26.3 before updating to 26.4.
  • The configuration of the object storage is described under Configure Relution →.