When using the .NET 8 SDK in a Windows environment, everything works as expected. However, when the same application is published and deployed to a Linux environment, an issue occurs during the signing and reporting of simplified XML invoices.
Error Message Returned by SDK:
[Error] Parsing EInvoice Certificate
[Error] Populating Signed Signature Properties
Root Cause:
After investigation, the issue seems to originate from the ParseCertificateMiddleware class. Specifically, the following code:
X509Certificate2 X509Certificate2 = new X509Certificate2(
(byte[])(object)(from x in Encoding.UTF8.GetBytes(eInvoiceData.CertificateContent)
select (sbyte)x).ToArray());
This works on Windows but fails on Linux due to differences in how certificate content is handled. It appears that the certificate content is base64-encoded, and decoding it with Encoding.UTF8.GetBytes leads to an invalid byte array on Linux.
Suggested Fix:
Changing the code to use proper base64 decoding instead resolves the issue across both environments:
X509Certificate2 X509Certificate2 = new X509Certificate2(
(byte[])(object)(from x in Convert.FromBase64String(eInvoiceData.CertificateContent)
select (sbyte)x).ToArray());
This approach correctly handles the certificate bytes and resolves the signing and validation issues when deployed on Linux.
Request:
Kindly review and consider updating the SDK to ensure platform-independent handling of certificates. This will help avoid deployment issues in Linux-based environments.
Without this modification, the dlls that sign and encrypt the invoice have different additional files depending on the operating system type and are usually located in a folder runtime
I solved my issue in Linux with same method that kyoussef suggested without knowing that there is a post like this in the community.
My certificate content: “MIICszCCAligAwIBAgI…” which is Base64 string.
Encoding.UTF8.GetBytes() produces bytes of letters M, I, I, C Not the actual decoded DER.
When they feed that to: new X509Certificate2(bytes)
.NET says: “This is not valid ASN.1. Wrong tag. Corrupted.” but only in Linux because windows can correct some fields of the certificate but not all.
The prove of that , If you debug the resulting object in windows from this line: new X509Certificate2(bytes) you will see some fields says that it has error , but the execution will complete.
In Linux the same command new X509Certificate2(bytes) is handled by OpenSSL which give an exception and no object is created.
However , I have a problem now in all my invoices which is this:
X509Certificate (CCSID / PCSID) used for signing is not valid certificate (CCSID / PCSID) for this VAT Registration Number.
I doubt that handling the certificate in Zatca servers is the same as the code in the SDK and that the reason why the problem rise.
I request the same as kyoussef asked which is trying the SDK in a Linux environment and the team of Zatca will notice the problem there.
runtime