We are getting below warning for all invoices that we send to ZATCA for both simulation and production.
X509Certificate (CCSID / PCSID) used for signing is not valid certificate (CCSID / PCSID) for this VAT Registration Number.
This warning is thrown only when an invoice is signed from EGS1 and reported through EGS2, where both EGS1 and EGS2 are registered under same VAT number.
Please help.
We are having exactly the same issue. But our setup does not involve multiple EGS devices.
It was not happening at the time when we integrated, but now we start noticing this strange warning…
The question is: how we can track this issue down to understand what is the real issue/problem here and then fix it.
Best regards,
Sergei
We are getting the exact same issue, in the sandbox environment. Has the credentials accepted by the sandbox suddenly changed, or what is the issue?
Has it been resolved for you Roopa or Sergei?
Many thanks in advance!
Dear sergei,
please make sure that you are using the production CSID and not the compliance CSID for signing invoices.
In the onboarding process, 2 CSIDs (X509 certificates) will be returned.
First one: after requesting the compliance CSID API, (which is the first step to do in onboarding process), we use this certifecate to sign invoices for the compliance checks step (compliance Invoice API), so we only use this certificate to sign invoices for the testing purposes in the compliance checks phase, as invoices in compliane checks are not being sent to ZATCA.
Second one: after requesting the production CSID API, we use this certificate to sign real invoices that are being sent to ZATCA by reporting API for simplified invoices or clearance API for standard invoices, however signing standard invoices is optional & not mandatory.
so what suggested is to make sure that you are using the PCSID X5509 certificate to sign your invoices,and check again.
thank you,
Not yet fixed LuKra,
Hello @Aturkistani ,
Indeed we were using the compliance certificates instead of production.
However now that we changed to use the production certificates, we still have the same error. I have checked the X509 embedded in the signature, and it is the correct one that was granted to us by Zatca during the production/csids call.
So please could you explain what else could trigger this “certificate-issuer-name” error that we get?
Thank you
Ziad
dear @ziadb,
please see below some of the most common mistakes that relates to the certificates:
1- the one I mentioned earlier, which is using CCSID insteas of PCSID in reporting & clearance.
2- if the VAT number that assoicated with the certificate is not the vat number inside the XML body
3- if the certificate has been generated from simulation and used in production or vice versa
4- if you are using an expired certificate to send/sign invoices
if you are signing your invoices with a certificate & upload it to zatca with a diffierent one, but both of the two are under the same VAT number but still facing “accepted with warning”, then please continue as this warning is not blocking you from the uploading process.
if you require any further support, please do not hesitate to reach out, you can also send the problem to your releationship manager describing the issue with the screenshot of the problem & more details & our technical team will help you.
dear @roopa,
what suggested from your side is to please continue uploading invoices as your approach is valid, taxpayer can sign invoices with EGS1 and upload it with EGS2 if both EGS(s) has PCSIDs under the same VAT number.
ignore this accepted with warnings message & please continue as your invoices will be sent successfully to ZATCA.
Dear @LukRa,
can you please add more details to your issue?
have you onboarded devices using production/simulation environment ?
Hi @Aturkistani ,
No, this is the Sandbox testing, using the credentials that have been working for a year. Now all of a sudden all of our tests for Simplified Invoices start failing with this error, since early October.
So something has changed in Sandbox Portal preventing us to test. And we are not running integration tests against Simulation Portal or Production portal, and are thus fully dependent on Sandbox to work as expected.
Please let us know what has changed.
Many thanks in advance!
Hello everyone, we spent few days trying to find the issue and FINALLY we were able to pinpoint the problem and get the fix done.
In our case (please note that there maybe more issues on your side) we had the incorrect order inside <ds:X509IssuerName> tag.
Because we generated this list ourselves, we were not thinking that this field is somehow important (especially at the time of implementation there were no check at all). The issue start appearing after some release of SDK and changes from ZATCA side without prior explanation what they changed or added.
Long story short, after changing the order from
'DC=local, DC=gov, DC=extgazt, CN=TSZEINVOICE-SubCA-1'
to
'CN=TSZEINVOICE-SubCA-1, DC=extgazt, DC=gov, DC=local'
The issue has been solved. 
I am pretty sure that the validation of this field is: it should be 100% the same as ZATCA generated it using some rules which are not documented. Probably they are getting it from Certificate as a string, but in our case we generate all components of issuer and then combine them together.
Cheers! If you still have the issue, post here the UBLExtensions tag part of your XML and we will try to help you guys.
Best regards,
Sergei
Hi Sergei,
Congratulations and great to know that you could find the issue.
In our case we are using zatca jar/dll to sign the invoice and thus UBL tags are generated by the library only.
Moreover, the order is correct in X509IssuerName too.
ds:X509IssuerNameCN=PRZEINVOICESCA3-CA, DC=extgazt, DC=gov, DC=local</ds:X509IssuerName>
It seems the issue is something else in our case.
Regards,
Roopa.
Hi @roopa , if you do not mind and there is nothing secure in your simulation invoice, then could you provide there the formatted UBLExtensions XML, we will look at it together and discuss what can be wrong. As we spent a lot of times already debugging, we have a lot of context and understanding how it should be
This one from example, and we were checking that our ERP (system) generating exactly same values except (signature) as it is different every time.
<ext:UBLExtensions>
<ext:UBLExtension>
<ext:ExtensionURI>
urn:oasis:names:specification:ubl:dsig:enveloped:xades
</ext:ExtensionURI>
<ext:ExtensionContent>
<sig:UBLDocumentSignatures xmlns:sig="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"
xmlns:sac="urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2"
xmlns:sbc="urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2">
<sac:SignatureInformation>
<cbc:ID>urn:oasis:names:specification:ubl:signature:1</cbc:ID>
<sbc:ReferencedSignatureID>urn:oasis:names:specification:ubl:signature:Invoice</sbc:ReferencedSignatureID>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="signature">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
<ds:Reference Id="invoiceSignedData" URI="">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<ds:XPath>not(//ancestor-or-self::ext:UBLExtensions)</ds:XPath>
</ds:Transform>
<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<ds:XPath>not(//ancestor-or-self::cac:Signature)</ds:XPath>
</ds:Transform>
<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<ds:XPath>not(//ancestor-or-self::cac:AdditionalDocumentReference[cbc:ID='QR'])</ds:XPath>
</ds:Transform>
<ds:Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>QnVEexW4nWv4CaE39a/66Jp/OXO/evHQ8pDlG7weq/4=</ds:DigestValue>
</ds:Reference>
<ds:Reference Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties" URI="#xadesSignedProperties">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>YzBjNDk5M2I1MDQyM2NkZjBhYjZiZDIzOGE1ZWU4NTFmODY4Nzk2NzA3NjJkM2ZlNDFmNDMyZjMyMzkyNzQxMA==</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>MEYCIQC9Ke7rU0G+lw1jBtDY1UnGVKfHh0ROAdRn554pEXNbUAIhAPzKiwpPSWHyCK/n40QFvlAsGWlS6t/eRAcfMGWueYPO</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIID9jCCA5ugAwIBAgITbwAAeCy9aKcLA99HrAABAAB4LDAKBggqhkjOPQQDAjBjMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxEzARBgoJkiaJk/IsZAEZFgNnb3YxFzAVBgoJkiaJk/IsZAEZFgdleHRnYXp0MRwwGgYDVQQDExNUU1pFSU5WT0lDRS1TdWJDQS0xMB4XDTIyMDQxOTIwNDkwOVoXDTI0MDQxODIwNDkwOVowWTELMAkGA1UEBhMCU0ExEzARBgNVBAoTCjMxMjM0NTY3ODkxDDAKBgNVBAsTA1RTVDEnMCUGA1UEAxMeVFNULS05NzA1NjAwNDAtMzEyMzQ1Njc4OTAwMDAzMFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEYYMMoOaFYAhMO/steotfZyavr6p11SSlwsK9azmsLY7b1b+FLhqMArhB2dqHKboxqKNfvkKDePhpqjui5hcn0aOCAjkwggI1MIGaBgNVHREEgZIwgY+kgYwwgYkxOzA5BgNVBAQMMjEtVFNUfDItVFNUfDMtNDdmMTZjMjYtODA2Yi00ZTE1LWIyNjktN2E4MDM4ODRiZTljMR8wHQYKCZImiZPyLGQBAQwPMzEyMzQ1Njc4OTAwMDAzMQ0wCwYDVQQMDAQxMTAwMQwwCgYDVQQaDANUU1QxDDAKBgNVBA8MA1RTVDAdBgNVHQ4EFgQUO5ZiU7NakU3eejVa3I2S1B2sDwkwHwYDVR0jBBgwFoAUdmCM+wagrGdXNZ3PmqynK5k1tS8wTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL3RzdGNybC56YXRjYS5nb3Yuc2EvQ2VydEVucm9sbC9UU1pFSU5WT0lDRS1TdWJDQS0xLmNybDCBrQYIKwYBBQUHAQEEgaAwgZ0wbgYIKwYBBQUHMAGGYmh0dHA6Ly90c3RjcmwuemF0Y2EuZ292LnNhL0NlcnRFbnJvbGwvVFNaRWludm9pY2VTQ0ExLmV4dGdhenQuZ292LmxvY2FsX1RTWkVJTlZPSUNFLVN1YkNBLTEoMSkuY3J0MCsGCCsGAQUFBzABhh9odHRwOi8vdHN0Y3JsLnphdGNhLmdvdi5zYS9vY3NwMA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwMwJwYJKwYBBAGCNxUKBBowGDAKBggrBgEFBQcDAjAKBggrBgEFBQcDAzAKBggqhkjOPQQDAgNJADBGAiEA7mHT6yg85jtQGWp3M7tPT7Jk2+zsvVHGs3bU5Z7YE68CIQD60ebQamYjYvdebnFjNfx4X4dop7LsEBFCNSsLY0IFaQ==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<ds:Object>
<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="signature">
<xades:SignedProperties Id="xadesSignedProperties">
<xades:SignedSignatureProperties>
<xades:SigningTime>2022-08-10T17:44:09Z</xades:SigningTime>
<xades:SigningCertificate>
<xades:Cert>
<xades:CertDigest>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>NjlhOTVmYzIzN2I0MjcxNGRjNDQ1N2EzM2I5NGNjNDUyZmQ5ZjExMDUwNGM2ODNjNDAxMTQ0ZDk1NDQ4OTRmYg==</ds:DigestValue>
</xades:CertDigest>
<xades:IssuerSerial>
<ds:X509IssuerName>CN=TSZEINVOICE-SubCA-1, DC=extgazt, DC=gov, DC=local</ds:X509IssuerName>
<ds:X509SerialNumber>2475382876776561391517206651645660279462721580</ds:X509SerialNumber>
</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
</xades:SignedSignatureProperties>
</xades:SignedProperties>
</xades:QualifyingProperties>
</ds:Object>
</ds:Signature>
</sac:SignatureInformation>
</sig:UBLDocumentSignatures>
</ext:ExtensionContent>
</ext:UBLExtension>
</ext:UBLExtensions>
Hi @sergei.shishov , I am also getting this error … my issuer Serial is :<xades:IssuerSerial> <ds:X509IssuerName xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> CN=PEZEINVOICESCA3-CA, DC=extgazt, DC=gov, DC=local </ds:X509IssuerName> <ds:X509SerialNumber xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 379112706134348777045369101887792407241563240 </ds:X509SerialNumber> </xades:IssuerSerial>
Could you post me the full XML’s UBLExtensions as I posted above to check.
One thing I have noticed in your XML, you have an extra whitespaces and I do not know how ZATCA is handling and comparing values.
DC=local </ds:X509IssuerName> # this extra trailing whitespace can be the reason as well
Following is my UBL Extension:
<ext:UBLExtensions>
<ext:UBLExtension>
<ext:ExtensionURI>urn:oasis:names:specification:ubl:dsig:enveloped:xades</ext:ExtensionURI>
<ext:ExtensionContent>
<sig:UBLDocumentSignatures
xmlns:sac="urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2"
xmlns:sbc="urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2"
xmlns:sig="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2">
<sac:SignatureInformation>
<cbc:ID>urn:oasis:names:specification:ubl:signature:1</cbc:ID>
<sbc:ReferencedSignatureID>urn:oasis:names:specification:ubl:signature:Invoice
</sbc:ReferencedSignatureID>
<ds:Signature Id="signature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11">
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256">
</ds:SignatureMethod>
<ds:Reference Id="invoiceSignedData" URI="">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<ds:XPath>not(//ancestor-or-self::ext:UBLExtensions)</ds:XPath>
</ds:Transform>
<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<ds:XPath>not(//ancestor-or-self::cac:Signature)</ds:XPath>
</ds:Transform>
<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<ds:XPath>
not(//ancestor-or-self::cac:AdditionalDocumentReference[cbc:ID='QR'])
</ds:XPath>
</ds:Transform>
<ds:Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256">
</ds:DigestMethod>
<ds:DigestValue>94a8UwPxcpXzGFVuUVhjYmEi1wm2+OBl1gSvzgX43ag=</ds:DigestValue>
</ds:Reference>
<ds:Reference Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"
URI="#xadesSignedProperties">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>
ODA1NGI5MmFiMzEwMzY5ZTQwOWI3Yzk2YjczMTQwZjdkZWM0YmI2MThjNTZjMmI1YjRiMTI4YzM2MjI1NzEzMw==
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
MEYCIQC4Udzg3OF8rk3j/JT4rfsDivMvArXTBTKI3bR9iMP0ewIhANOS6jLU9i0HJsqHU9EXQFrtdKW3RB8ELxT4VCmsNwch
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIID1DCCA3mgAwIBAgITEQAAHGgunPvVhslDfQABAAAcaDAKBggqhkjOPQQDAjBiMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxEzARBgoJkiaJk/IsZAEZFgNnb3YxFzAVBgoJkiaJk/IsZAEZFgdleHRnYXp0MRswGQYDVQQDExJQUlpFSU5WT0lDRVNDQTQtQ0EwHhcNMjMxMTE1MTM0MTQ5WhcNMjgxMTEzMTM0MTQ5WjB8MQswCQYDVQQGEwJTQTEtMCsGA1UEChMkQWxtb3NhZmVyIFRyYXZlbCBhbmQgVG91cmlzbSBDb21wYW55MRMwEQYDVQQLEwozMDIwMDI0OTI4MSkwJwYDVQQDDCBBbG1vc2FmZXJfVHJhdmVsX1RvdXJpc21fQ29tcGFueTBWMBAGByqGSM49AgEGBSuBBAAKA0IABIxl8icBcyll+fMZEUFudJP/4Bs/KoSwwWN6idfHR6vBoE/89SSleJDGiHk+c3KiUAwAmmfUy868TKEFB/9YQ5ijggH1MIIB8TCBmwYDVR0RBIGTMIGQpIGNMIGKMSowKAYDVQQEDCExLUFsbW9zYWZlcnwyLVVuaWZ5fDMtOTM0MzU2NzIzNDgxHzAdBgoJkiaJk/IsZAEBDA8zMDAwNTYyMDk2MTAwMDMxDTALBgNVBAwMBDExMDAxDzANBgNVBBoMBlJpeWFkaDEbMBkGA1UEDwwSVHJhdmVsIGFuZCBUb3VyaXNtMB0GA1UdDgQWBBR7diFzHqBAN5EoIWhWdoxrAjrQgjAfBgNVHSMEGDAWgBSbyqqi7ZqsLJCBc1b6T9j8U/vTZzB7BggrBgEFBQcBAQRvMG0wawYIKwYBBQUHMAKGX2h0dHA6Ly9haWE0LnphdGNhLmdvdi5zYS9DZXJ0RW5yb2xsL1BSWkVJbnZvaWNlU0NBNC5leHRnYXp0Lmdvdi5sb2NhbF9QUlpFSU5WT0lDRVNDQTQtQ0EoMSkuY3J0MA4GA1UdDwEB/wQEAwIHgDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiBhqgdhND7EobtnSSHzvsZ08BVZof6pWWF2YQ+AgFkAgESMB0GA1UdJQQWMBQGCCsGAQUFBwMDBggrBgEFBQcDAjAnBgkrBgEEAYI3FQoEGjAYMAoGCCsGAQUFBwMDMAoGCCsGAQUFBwMCMAoGCCqGSM49BAMCA0kAMEYCIQDMNfC4Ikg8+A8i313EUsBKOaPiAcP0qKjQwwt/jcDpUgIhANtu2iJTiyNU3uG8cg5VRaYFJNHk9ko3I0FJrOnwTQzf
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<ds:Object>
<xades:QualifyingProperties Target="signature"
xmlns:xades="http://uri.etsi.org/01903/v1.3.2#">
<xades:SignedProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
Id="xadesSignedProperties">
<xades:SignedSignatureProperties>
<xades:SigningTime>2023-12-05T14:22:39Z</xades:SigningTime>
<xades:SigningCertificate>
<xades:Cert>
<xades:CertDigest>
<ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
MDAyNTNiNmZlNzhhZWU3YjA3NjJiNGVlZjM5MTYwOGNlNjE5YmNlODc1M2UxOGViNmU5OTQ4MzJiYWIxOGE5Nw==
</ds:DigestValue>
</xades:CertDigest>
<xades:IssuerSerial>
<ds:X509IssuerName
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
CN=PEZEINVOICESCA3-CA, DC=extgazt, DC=gov, DC=local
</ds:X509IssuerName>
<ds:X509SerialNumber
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
379112706134348777045369101887792407241563240
</ds:X509SerialNumber>
</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
</xades:SignedSignatureProperties>
</xades:SignedProperties>
</xades:QualifyingProperties>
</ds:Object>
</ds:Signature>
</sac:SignatureInformation>
</sig:UBLDocumentSignatures>
</ext:ExtensionContent>
</ext:UBLExtension>
</ext:UBLExtensions>
Hello @abdullah.rahim just had time to look into it. I got your certificate from <ds:X509Certificate> and decoded it using OpenSSL, and there I can see all required data to past later under <xades:SigningCertificate>
Inside your certificate I can see the following issuer (comparing to what you add to extensions):
It seems you have incorrect order, BUT ALSO I can see that you have mismatch in CN: PRZEINVOICESCA4-CA != PEZEINVOICESCA3-CA.
I would not recommend you to hardcode it, instead you should extract all data from your certificate every time you generate data as ZATCA updating their codebase and servers and newly generated certificates can have completely different issuers, serial numbers, etc
If you have any questions, please ask.
@roopa , please check your issuer in the certificate as you can have similar issue
Hi @sergei.shishov , Thanks for your suggestion but i am still getting ,"message":"Complied with UBL 2.1 standards in line with ZATCA specifications","status":"PASS"}],"warningMessages":[{"type":"WARNING","code":"certificate-issuer-name", warning. I have changed the issuer name to what we mentioned but still getting this warning.
Dear
now i face the same issue
what did you do please
{“type”:“WARNING”,“code”:“certificate-issuer-name”,“category”:“CERTIFICATE_ERRORS”,“message”:“X509Certificate (CCSID / PCSID) used for signing is not valid certificate (CCSID / PCSID) for this VAT Registration Number.”,“status”:“WARNING”},{“type”:“WARNING”,“code”:“invalid-signing-certificate”,“category”:“CERTIFICATE_ERRORS”,“message”:“X509Certificate (CCSID / PCSID) used for signing is not valid certificate (CCSID / PCSID) for this VAT Registration Number.”,“status”:“WARNING”}],“errorMessages”:,“status”:“WARNING”},“reportingStatus”:“REPORTED”,“clearanceStatus”:null,“qrSellertStatus”:null,“qrBuyertStatus”:null}
Hello, were you able to fix the issue, we are facing the same