Renouvellement des certificats EBICS serveurs

Écrit par Christophe Garnier – Directeur technique PPI FRANCE

La très grande majorité des serveurs EBICS, pour la version française de ce protocole, ont été mis en production fin 2009 et courant 2010. Bon nombre d’entre eux utilisent des certificats X.509 auto-signés d’une durée de vie de 5 ans, un certain nombre d’établissements ont donc déjà procédé à leur renouvellement et d’autres s’y préparent.


Si pour le renouvellement des certificats côté clients le protocole prévoit des messages dédiés (messages PUB, HCA et HCS) et une cinématique supprimant les interventions manuelles (messages signés ne nécessitant pas de validation complémentaire), il n’en est pas de même en ce qui concerne le renouvellement côté serveur. Le seul message HPB est disponible et la validation des certificats reçus inclut une étape manuelle : le rapprochement avec leur empreinte numérique. Une autre différence notable est la portée de l’opération qui peut concerner plusieurs milliers d’accès clients simultanément.

Il apparait donc évident qu’un minimum d’organisation et de précautions sont nécessaires pour faciliter cette intervention.

Fort de notre savoir-faire dans le développement et la mise en œuvre de logiciels EBICS tant du côté client que du côté serveur, nous avons pu tirer des enseignements des premières expériences de renouvellements de ces certificats, et nous nous permettons donc de faire les recommandations suivantes aux personnes en charge de l’administration des serveurs EBICS:

- S’enquérir auprès de son fournisseur du mode opératoire de génération et de mise à jour des certificats.

- Bien choisir la date et l’heure en évitant les périodes habituelles de stress (fin de mois, cut-off, …) ou de faible disponibilité des intervenants côté clients (fin de soirée, nuit, week-end, congés scolaires, …).  Eu égard aux dates de fin de validité des certificats, il est bien sûr possible d’anticiper leur renouvellement, ce qui offre un peu plus de latitude.

- Informer les clients, avec un délai significatif, de la date et de l’heure retenues pour la mise en place des nouveaux certificats. Il nous semble judicieux de prévoir l’envoi d’un courrier de rappel quelques jours auparavant. Voici quelques éléments que nous pensons utiles d’intégrer dans cette communication:
  • Inciter le client à prendre contact avec son fournisseur pour s’assurer que son logiciel supporte le renouvellement des certificats EBICS du serveur et en obtenir le mode opératoire s’il n’est pas déjà en sa possession. A noter que nous avons identifié deux logiciels clients distincts ne permettant pas de réaliser cette opération. Dans les deux cas, les clients ont été dans l’obligation de recréer complètement leurs accès.
  • Inviter le client à transmettre le courrier à d’éventuels prestataires auxquels il aurait délégué un accès de télétransmission. Le point précédent s’appliquant aussi à eux.
  • L’empreinte numérique (pour une meilleure compréhension nous conseillons d’ailleurs de mentionner également les autres dénominations couramment employées: condensat et hash) de chaque nouveau certificat doit bien sûr être indiquée dans le courrier pour en permettre la validation par rapprochement. La présentation habituelle sous forme d’une matrice de 4 lignes de 8 octets peut être complétée par une présentation linéaire (les 32 octets sur une même ligne sans caractère séparateur) afin d’en faciliter le copier-coller dans le logiciel du client.
  • Indiquer au client que s’il omet de mettre à jour à temps son paramétrage, le premier transfert échouera avec un code d’erreur réservé de valeur 091008 et de libellé EBICS_BANK_PUBKEY_UPDATE_REQUIRED. Il devra alors récupérer les nouveaux certificats avant de relancer le ou les transferts en échec.
  • Un dernier point peut aussi mentionner les empreintes numériques des certificats en cours pour permettre aux clients qui le souhaiteraient de se familiariser avec les actions à réaliser dans leur logiciel en faisant une simulation sur la base de ces certificats. Cela permettrait au client de détecter à l’avance un éventuel dysfonctionnement de la procédure de renouvellement dans son logiciel, et dans ce cas de solliciter son fournisseur sur le champ, dans un contexte moins stressant.
La gestion du renouvellement des certificats EBICS serveurs est l’un des derniers éléments du protocole manquant de fluidité. Gageons que comme pour l’OrderID, la société EBICS saura y remédier d’ici les 5 prochaines années en faisant évoluer le standard.

Marc Dutech
Réactions :

0 commentaires:

Enregistrer un commentaire