Yesterday we encountered the following warning during clearance:
{“type”:“WARNING”,“code”:“invalid-digital-signature”,“category”:“SIGNATURE_ERRORS”,“message”:“The certificate in the invoice implies that it was signed with a private key different from the one associated with this device”,“status”:“WARNING”}
We are already signing the invoice using the exact same private key that was used to generate the CSR for the Production CSID certificate — i.e., the private key that matches the public key inside the Production certificate issued by ZATCA.
However, we still receive this warning.
Question:
Does this warning indicate any additional validation requirement beyond using the matching CSR private key?
We appreciate your guidance to ensure full compliance.
The issue appeared only on October 27th and then stopped. I understand that ZATCA have paused validation, but I would like to confirm whether this was due to a temporary suspension on their side or if there is still an error in the validation process that needs to be resolved.
I would like to confirm that the issue has now been fully resolved on our side.
After a detailed review, we discovered that the problem was caused by double hashing the invoice before generating the digital signature in our signing function.
The Correct Digital Signature Generation Process
Step 1 – Use the raw invoice hash bytes
Start from the 32-byte SHA-256 hash of the canonicalized invoice XML (the result of the “Generate Invoice Hash” step).
If you have the hash as Base64, first decode it to obtain the original 32 bytes.
Do not sign the Base64 text or re-hash the hash.
Step 2 – Normalize the private key string
Ensure the private key is in valid PEM format with the proper headers and footers:
-----BEGIN EC PRIVATE KEY-----
(base64 key content)
-----END EC PRIVATE KEY-----
Step 3 – Read the EC private key
Load the PEM using a proper PEM reader (for example, BouncyCastle PemReader) and extract the EC private key (AsymmetricCipherKeyPair.Private).
Step 4 – Create the ECDSA signer
Initialize an ECDSA signer without an internal digest, for example:
Algorithm = NONEwithECDSA.
Call BlockUpdate with the raw 32-byte hash, then generate the signature.
Step 5 – Return ds:SignatureValue as Base64
Base64-encode the ECDSA signature bytes and place this value inside ds:SignatureValue…</ds:SignatureValue> in the invoice XML.
After removing the redundant hashing (i.e., avoiding SHA-256withECDSA on an already SHA-256-hashed value), the digital signature was generated correctly and the
“invalid-digital-signature” / “Wrong signature value” warnings no longer appeared during ZATCA SDK validation.
Thank you again for your assistance and clarification.
I think that the issue was resolved by ZATCA to reverting their changes. Therefore I would like the confirmation from your side… Could you please revert YOUR changes regarding double hashing and try to report (simulation), would you still have the same issue or not?
I am asking because we had exactly th same issue on our end and it was resolved without changes on our side (ZATCA reverted their changes).
Yes, ZATCA did revert their recent validation changes related to invoice submission (both reporting and clearance). However, these additional validation checks are expected to be re-applied at a later stage.
In our case, the ZATCA SDK validation continued to show the same “invalid-digital-signature” warning until we identified and fixed the actual root cause on our side — the issue was caused by double hashing the invoice hash during the digital signing process.
After correcting our signing function, the signature validated successfully.
So regarding your question:
The issue may have appeared resolved when ZATCA reverted their changes, but it will likely return once those validations are enabled again. I recommend testing again using the ZATCA SDK validation, as it will confirm whether the warning still appears or not.
Hi @SP_AlMizan , good to know. It seems we start receiving errors again… Going to check what is wrong in our case and post the updates here to help other people.
To provide comprehensive support as usual, can I kindly ask you to share the full request and response via below mail, along with the exact steps that you followed?
I will try to share the process and the response we got via email.
Sharing the production request might be difficult since this is an already working and implemented system that has been in use for more than a year, so getting OTP for production from clients frequently is difficult.
We can share the request for development. (but that is working without any issues)
We too have mailed you the details 2 days back, Please expedite your help to solve the issue.
Few of our clients are waiting for completion of onboardiing.