Relution Signet Customer Hub

S3 : le démarrage s'arrête avec une erreur PKIX

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.

Les éléments suivants se combinent ici :

  • Lorsqu’un stockage d’objets est configuré, les ressources y sont déportées. 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é ; en cas d’exploitation avec plusieurs nœuds Relution, sur tous les nœuds.
  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. D’autres jetons signés avec ce certificat perdent également leur validité, par exemple pour des inscriptions d’appareils Apple et Android commencées mais pas encore terminées. Ces processus sont relancés.

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éversé (voir Gestion des certificats →).
  • Sous Paramètres → Configuration de confiance TLS → Certificats de confiance, le certificat téléversé est sélectionné dans la bibliothèque de certificats via Ajouter, puis la configuration est appliquée avec Enregistrer.

La configuration de confiance TLS prend effet 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 transférés du stockage d’objets vers la base de données lors de la prochaine exécution de la tâche de migration (par défaut chaque jour à 3 h 00).

En cas de chiffrement côté client via KMS (relution.storage.s3.clientSideEncryption.type=KMS), Relution 26.4 à 26.5.4 inclus n’appliquent pas la configuration de confiance TLS aux accès aux objets. Dans ce cas, les accès au stockage d’objets et le transfert des autres certificats vers la base de données continuent d’échouer, même après l’ajout de l’autorité de certification. À partir de Relution 26.5.5, ces accès utilisent également les certificats de confiance enregistrés ; les installations concernées sont donc mises à jour vers Relution 26.5.5 ou une version plus récente.

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 par défaut une fois par jour à 3 h 00. La planification peut être adaptée dans application.yml via relution.storage.s3.resourceMigrationSchedule (expression cron, valeur par défaut 0 0 3 * * ?). 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.
  • Si une clé de signature propre est définie dans application.yml via relution.jwt.secret, Relution n’utilise pas de certificat de signature JWT ; le problème décrit ici ne se produit alors pas.
  • La configuration du stockage d’objets est décrite sous Connecter le stockage →.