H005 INI

[AnasKay]

Hello,
since you mentioned in the repository’s README that it was tested with ZKB, I assumed it should also work well with LUKB.
We have now received feedback from LUKB’s technical support regarding the INI request in H005:
"We suspect that this is a client-side error. Since you wrote “Version is H005,” this concerns EBICS 3.0. Unlike EBICS 2.5, the INI letter must contain the SHA-256 hash value of the certificate (DER-encoded) — not the hash value of the public key contained in the certificate. This then is verified in accordance with the EBICS specification, chapter 4.4.1.2.3."

Shouldn’t the INI workflow also fail with ZKB then, since the INI request does not comply with the EBICS 3.0 specification? @uwemaurer

[uwemaurer]

So we were already signed up with ZKB using EBICS 2.5 and then switched to EBICS 3 without repeating this process.
However I went through all the steps on their testplattform (https://testplattform.zkb.ch/) and it worked there.
So did you get this feedback when you sent in these INI letters to the bank?

[AnasKay]

Yes exactly this feedback was after sending the letters - but i just have inspected the letter generation part again and see that there is a
if (user.getPartner().getBank().useCertificate())
take hash of cert
else
take hash of pub key

I will debug this now and come back with feedback :)

[AnasKay]

in anycase as far as I can see currently useCertificates is allways false.

[uwemaurer]

I let claude code investigate and it said this

 Investigation result

  Your LUKB contact is right, and there's a real bug here — but it's worth being precise about which part is wrong, because that's exactly what explains the ZKB-vs-LUKB difference.

  There are two separate artifacts in the INI step, and they're built by different code paths:

  1. The electronic INI request (the XML sent over the wire) — this is correct/compliant.

  In SignaturePubKeyOrderDataElement.build() (src/main/java/org/kopi/ebics/xml/SignaturePubKeyOrderDataElement.java:46-62), the order data always embeds the full X.509 certificate via X509Data, using getA005Certificate() (which returns getEncoded() — the DER
  bytes). The pubkey-value alternative is commented out. The request is sent in the urn:org:ebics:H005 namespace (INIRequestElement.java:58), i.e. EBICS 3.0. So the request the bank receives is fine, and the bank server accepts it and returns OK. This is the same
  for ZKB and LUKB — which is why it "worked" with ZKB.

  2. The INI letter (the printed/signed document) — this is where the bug is.

  The letter hash is built conditionally on a useCertificate() flag (A005Letter.java:46-71, same in E002Letter/X002Letter):
  - useCertificate() == true → getHash(certificate) = SHA-256 of the DER-encoded certificate ✅ (the H005 way)
  - useCertificate() == false → getHash(publicKey) = SHA-256 of the public key (modulus+exponent, the old EBICS 2.5 / A005 way) ❌

  And the flag defaults to false:
  - CLI: hard-coded boolean useCertificates = false; (EbicsClient.java:515)
  - Parameterized launcher: resolveUseCertificate() returns false unless EBICS_USE_CERTIFICATE=true or EBICS_SIGNATURE_VERSION=A006 (ParameterizedEbicsClientLauncher.java:227-234)

  So with the defaults, the letter prints the SHA-256 of the public key, while the request transmits an X.509 certificate. Per EBICS 3.0 spec ch. 4.4.1.2.3, the bank verifies that the hash on the letter matches the certificate it received — and these two don't
  match.

  Fix options

  - Quick workaround (no code change): run with the certificate hash forced on — e.g. EBICS_USE_CERTIFICATE=true for the parameterized launcher, then re-generate and re-send the INI/HIA letters.
  - Proper fix: since the INI/HIA requests unconditionally send the X.509 certificate under H005, the letters should unconditionally hash the certificate too — i.e. drop the useCertificate() branch in A005Letter/E002Letter/X002Letter (or default it to true) so the
   printed digest is always SHA-256 of the DER cert.

[uwemaurer]

I will do the Proper fix suggestion

[AnasKay]

I will check with the bank now if the new generated letters with useCertificates = TRUE are correct now and will give you feedback

[uwemaurer]

I will wait for your feedback. I have a change ready to remove the useCertificates variable and treat it always as true

[AnasKay]

merge it :)
Just got the feedback that it worked