Renewing the EBICS certificates for servers

Written by Christophe Garnier – Technical director of PPI FRANCE

The vast majority of EBICS servers, for the French version of this protocol, were put into production at the end of 2009 and during 2010. Many of them use self-signed X.509 certificates, which are valid for 5 years. Some institutions have therefore already started renewing them and others are preparing for it.


If, to renew the client certificates, the protocol envisages dedicated messages (PUB, HCA and HCS messages) and an automatic mechanism suppressing manual interventions (signed messages do not require additional authentication), the same does not apply to the renewal for the server. Only the HPB message is available and authentication of the certificates received includes a manual stage: matching with their digital fingerprint. Another notable difference is the scope of the operation which may concern several thousand client accesses at the same time.

It therefore seems obvious that a minimum of organisation and precautions are needed to facilitate this intervention.

Due to our expertise in developing and implementing EBICS software, on both the client and server side, we have learnt lessons from our first experiences in renewing these certificates and therefore feel able to make the following recommendations to those in charge of the administration of the EBICS servers:

- Enquiring at the provider about the operating mode for generating and updating the certificates.
- Choosing a good date and time which avoids periods that are usually stressful (end of the month, cut-off, etc.) or when few staff are available at the client (late evening, night-time, weekend, school holidays, etc.). Regarding the dates when the certificates expire, it is possible to anticipate when they need renewing and this will provide a little more leeway.

- Informing clients, well before time, about the date and time retained for setting up the new certificates. It would seem wise to send a reminder a few days beforehand. Here are a few elements that we think would be useful to integrate in this communication:

• Encouraging the client to contact their provider to ensure that their software supports the renewal of the EBICS certificates for the server and to obtain the operation mode, if they do not already have it. It should be noted that we have identified two distinct client software versions that do not allow this operation. In both cases, the clients have had to completely set up their access again.
• Inviting the client to send the mail to any providers to whom they have assigned remote transmission access. The point before also applies to them.
• The digital fingerprint (to aid comprehension, we also recommend mentioning the other denominations currently in use: condensate and hash) of each new certificate must, of course, be specified in the mail to allow it to be authenticated through matching. In addition to the usual presentation with a matrix of 4 rows of 8 bytes, it can also be presented in a line (the 32 bytes on the same row without a separator character) to allow it to be copied and pasted in the client’s software.
• Pointing out to the client that, if they do not update the parameters in time, the first transfer will fail with a reserved error code of value 091008 and with the words EBICS_BANK_PUBKEY_UPDATE_REQUIRED. The new certificates will therefore have to be recovered before restarting the transfer or transfers that have failed.
• A final point could also mention the digital fingerprints of certificates currently in use. This would enable those clients wishing to do so, to familiarise themselves with the steps to be performed in their software, by carrying out a simulation based on these certificates.

Management of the renewal of the server EBICS certificates is one of the last elements of the protocol lacking fluidity. We are confident that, just as with the OrderID, the EBICS company will be able to remedy this in the next 5 years by developing the standard.

Christophe Garnier