Fixing IRBM’s DS320 Error #IRBIntegration #DS320 #XAdESSigning #DigitalCertificate #UBLFix #LaravelMyInvois #TINBRN

SEO Title: Fixing IRBM DS320 Error in e-Invoice Signing – Complete Laravel Guide
Focus Keyphrase: IRB DS320 error
Meta Description: Learn what causes the IRB DS320 digest error in Malaysia’s e-invoice system and how to fix it using proper XML signing, canonicalization, and certificate subject formatting in Laravel.

🧾 What is DS320?

DS320 is a digital signature digest mismatch error returned by IRBM (Inland Revenue Board of Malaysia) during e-Invoice submission. It usually relates to:

• A mismatch in the digest value of <xades:SignedProperties>, or
• An issue with your signing certificate metadata, especially its Subject name

❓ Why does DS320 happen?

DS320 means:

“Digest value of SignedProperties does not match, or certificate subject does not follow IRBM format.”

It happens due to:

• ❌ Incorrect canonicalization of <xades:SignedProperties>
• ❌ Missing URI, Type, or Transforms in <ds:Reference>
• ❌ Missing or malformed certificate subject name (e.g., TIN/BRN not present or incorrect order)

🕒 When do you get this error?

During POST /invoices, after:

1. Generating and signing UBL XML
2. Wrapping the signature in <ext:UBLExtensions>
3. Submitting to IRBM’s MyInvois API

👨‍💻 Who is affected?

• Laravel or PHP developers using xmlseclibs or custom signature logic
• Anyone submitting signed e-invoices to IRBM
• Integrators using self-converted .p12 or PEM files

🌐 Where is the problem?

Two places:

1. Inside the <xades:SignedProperties> digest block
2. Inside the certificate’s Subject name (used in <ds:X509IssuerName> and <xades:SignerRole>)

🛠 How to Fix DS320 in Laravel (2 Scenarios)

✅ 1. Canonicalization / Digest Mismatch Fix

As explained previously:

• Use exclusive C14N on <xades:SignedProperties>
• Set correct Id="SignedProperties"
• Reference it with:
  • URI="#SignedProperties"
  • Type="http://uri.etsi.org/01903/v1.3.2#SignedProperties"
  • Transform = http://www.w3.org/2001/10/xml-exc-c14n#

$canonicalXml = $signedPropertiesNode->C14N(true, false);
$digest = base64_encode(hash('sha256', $canonicalXml, true));

✅ 2. Fix Certificate Subject Formatting

IRBM validates the Subject Name of your digital certificate. If it does not contain TIN, BRN, and the Company Name in the expected format — you’ll also get DS320.

🔍 Example of IRBM-compliant subject:

C=MY, O=Example Tech Sdn. Bhd. (1234567-X), SERIALNUMBER=BRN:1234567X, TIN:C10234567890

Common mistakes:

• ❌ SERIALNUMBER missing or using only one ID
• ❌ TIN not present
• ❌ Values in wrong order or using lowercase attribute names
• ❌ Company name in CN instead of O

✅ How to check your certificate subject

Run this command:

openssl x509 -in storage/certs/irb_client_cert.pem -noout -subject

Example output:

subject= C = MY, O = Example Tech Sdn. Bhd., SERIALNUMBER = BRN:1234567X, TIN:C10234567890

✅ IRBM requires:

• Country: C=MY
• Organization: O= (Company Name)
• SerialNumber must include both BRN and TIN, e.g.:
  SERIALNUMBER=BRN:1234567X, TIN:C10234567890

If your subject is missing these, request a corrected certificate from your CA.

🔐 How to Replace or Regenerate

If your cert is invalid:

1. Contact your CA (e.g., Digicert, Trustgate)
2. Request a MyInvois-compatible client certificate
3. Specify: you need TIN and BRN embedded in SERIALNUMBER

✅ Summary Checklist for DS320

📌 Final Thoughts

DS320 is one of the hardest IRB errors because it mixes technical signature issues with regulatory cert metadata.

✅ Fix both digest and certificate format and you’ll pass validation.
✅ Log all digest hashes and subjects during debugging.
✅ Always verify your cert before production use.

Tags:
#IRBIntegration #DS320 #XAdESSigning #DigitalCertificate #UBLFix #LaravelMyInvois #TINBRN