Préparer la rotation de vos certificats — Documentation API DSP2

En résumé

Le renouvellement de vos certificats eIDAS (QWAC et QSealC) ne nécessite aucune action de notre côté tant que votre identité d'organisation ne change pas :

Votre client est lié à votre identifiant d'organisation (organizationIdentifier, OID 2.5.4.97, ex. PSDFR-ACPR-12345), et non à une clé ou à un certificat précis.
Vous pouvez donc changer de clé / de certificat librement, à condition que le nouveau certificat porte le même identifiant d'organisation.

⚠️ Si votre autorité de certification (CA/QTSP) change — ou si votre organizationIdentifierchange, prévenez‑nous en amont.

Vos deux certificats

Certificat	Rôle	Où il est utilisé	Comment il est vérifié
QWAC	Authentification de transport (mTLS)	Handshake TLS mutuel sur tous les endpoints authentifiés (`/register`, `/token`, API AISP/PISP…)	La chaîne est validée par notre terminaison TLS, puis le certificat leaf est présenté au backend, qui compare son `organizationIdentifier` à celui enregistré.
QSealC	Signature des messages (HTTP Message Signature)	Signature des requêtes `/register` et `PATCH` de mise à jour	La signature est vérifiée contre le JWKS que vous avez publié, la clé étant résolue par son `kid`.

Les deux se renouvellent indépendamment.

Rotation du QWAC (transport / mTLS)

Tant que le nouveau QWAC porte le même organizationIdentifier :

Obtenez votre nouveau QWAC auprès de votre QTSP (même identité d'organisation).
Déployez‑le côté client comme certificat de transport mTLS.
Commencez à l'utiliser. Aucun ré‑enregistrement n'est requis : notre plateforme reconnaît le même TPP dès la première connexion avec la nouvelle clé.

Rotation du QSealC (signature) — recouvrement sans interruption

Vos clés de signature sont publiées dans votre JWKS, chacune identifiée par un kid. La rotation se fait en recouvrement (les deux clés valides simultanément), puis bascule:

Ajouter la nouvelle clé. Envoyez un PATCH de mise à jour d'enregistrement dont le jwks contient les deux clés (ancienne + nouvelle, chacune avec son kid). Cette requête doit être signée avec l'ancienne clé (encore valide à ce stade).
Période de recouvrement. Les deux kid sont acceptés: vous pouvez signer avec l'ancienne ou la nouvelle clé — aucune interruption. Basculez vos systèmes à votre rythme.
Bascule. Une fois vos systèmes passés à la nouvelle clé, envoyez un PATCH dont le jwks ne contient que la nouvelle clé. Cette requête doit être signée avec la nouvelle clé.
Retrait effectif. L'ancienne clé est désormais rejetée; seule la nouvelle signe.

Changement de CA ou d'identité

Deux cas nécessitent une coordination préalable avec nos équipes:

Changement d'autorité de certification (CA / QTSP): par précaution prévenez‑nous en amont afin que nous mettions à jour la chaîne de confiance avant votre bascule.
Changement de organizationIdentifier : votre client étant lié à cet identifiant, une modification revient à une nouvelle identité et impose un nouvel enregistrement. Contactez‑nous pour organiser la transition.