Relution Signet Customer Hub

Démarrage du serveur avec un certificat S3 auto-signé

Après une mise à jour d’une version antérieure à 26.2 directement vers Relution 26.4 ou une version plus récente, le serveur ne démarre plus si le stockage d’objets S3 connecté est accessible via TLS avec un certificat auto-signé ou interne à l’entreprise. L’erreur suivante apparaît dans le journal :

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

Au démarrage, Relution lit le certificat de signature JWT depuis le stockage d’objets configuré. Si le certificat de l’autorité de certification émettrice n’est pas enregistré comme étant de confiance, la connexion TLS vers le point de terminaison S3 échoue et le démarrage est interrompu.

Trois modifications se combinent ici :

  • Depuis Relution 5.27, les ressources sont déportées vers le stockage d’objets lorsque celui-ci est configuré. Cela concerne également les certificats et donc le certificat de signature JWT.
  • Avec Relution 26.2, les certificats sont classés comme sensibles sur le plan de la sécurité et sont conservés durablement dans la base de données. Les certificats déjà déportés sont automatiquement migrés du stockage d’objets vers la base de données.
  • Avec Relution 26.4, les certificats CA ne sont plus enregistrés dans le système d’exploitation du conteneur, mais dans la base de données, et sont gérés via l’interface utilisateur (voir Certificat CA dans Docker →). L’ajout du certificat suppose donc un serveur en cours d’exécution, alors que le serveur ne démarre à son tour que lorsque le certificat est déjà considéré comme de confiance.

Si la mise à jour est effectuée par étapes intermédiaires via 26.2 ou 26.3, le certificat de signature se trouve de nouveau dans la base de données après la migration inverse, de sorte que le démarrage sous 26.4 ne nécessite plus d’accès au stockage d’objets. Ce n’est que lors d’une mise à jour directe d’une version antérieure à 26.2 vers 26.4 ou une version plus récente que cette migration inverse n’a pas lieu, alors que le certificat CA ne peut simultanément plus être ajouté via le système d’exploitation.

Solution

Pour permettre au serveur de démarrer, le certificat de signature concerné est supprimé de la base de données. Au démarrage suivant, Relution génère un nouveau certificat de signature et l’enregistre dans la base de données, de sorte qu’aucun accès au stockage d’objets n’est nécessaire pour le démarrage.

Étapes nécessaires :

  1. Le service Relution est arrêté.
  2. L’enregistrement du certificat de signature est supprimé de la base de données à l’aide de l’instruction ci-dessous.
  3. Le service Relution est démarré.

Pour PostgreSQL, le nom de colonne usage est encadré par des guillemets doubles. Dans MariaDB, usage est un mot-clé réservé et y est encadré par des accents graves.

PostgreSQL :

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

MariaDB :

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

Conséquences

Un nouveau certificat de signature JWT est généré lors du démarrage suivant. Les cookies de connexion existants deviennent ainsi invalides, ce qui oblige tous les utilisateurs à se reconnecter.

Après le démarrage du serveur

Une fois le serveur démarré, le certificat de l’autorité de certification interne est ajouté afin que la connexion au stockage d’objets soit de nouveau considérée comme de confiance :

  • La connexion s’effectue dans l’organisation globale.
  • Sous Paramètres → Certificats, le certificat de l’autorité de certification interne est téléchargé (voir Gestion des certificats →).
  • Sous Paramètres → Configuration de confiance TLS → Certificats de confiance, le certificat téléchargé est sélectionné dans la bibliothèque de certificats via Ajouter un certificat.

La prise en compte s’effectue pendant le fonctionnement du système ; aucun redémarrage supplémentaire du serveur n’est nécessaire. Les autres certificats sensibles sur le plan de la sécurité — par exemple le certificat de signature pour les services externes et le certificat de l’autorité SCEP — sont ensuite également transférés du stockage d’objets vers la base de données.

Remarques complémentaires

  • Si le stockage d’objets est connecté sans TLS ou avec un certificat publiquement reconnu, le problème ne se produit pas.
  • La migration inverse des certificats vers la base de données est effectuée par une tâche d’arrière-plan exécutée une fois par jour par défaut. En cas de mise à jour par étapes intermédiaires, il convient donc de s’assurer que la migration est terminée sous 26.2 ou 26.3 avant de passer à 26.4.
  • La configuration du stockage d’objets est décrite sous Configurer Relution →.