Status invalid Type for "http://uri.etsi.org/01903#SignedProperties"

[hafedh-trimeche]

Hello,

I'm using this Pascal code to verify xml signed file which is valid on https://www.aleksey.com/xmlsec/xmldsig-verifier.html and generated this file: xmldsigverify.txt

The verification generated by Pascal code gave an invalid Status : xmlSecDSig.Log

Which modification to be made to achieve VALID verification?

function TXMLSec.Verify(const xmlContent:string;Flags:Integer;Signer:string):xmlDSigStatus;
var
  xmlDoc   : xmlDocPtr;
  rootNode : xmlNodePtr;
  refNode  : xmlNodePtr;
  signNode : xmlNodePtr;
  refStr   : string;
function VerifyNode(signNode:xmlNodePtr):xmlDSigStatus;
var
  xSignature             ,
  xEncapsulatedTimeStamp ,
  xEncapsulatedOCSPValue : xmlNodePtr;
  ObjectNode             : xmlNodePtr;
  SigValue               : TBytes;
  TSPValue               : TBytes;
  OCSPValue              : TBytes;
  dsigCtx                : xmlSecDSigCtxPtr;
  X509DataNode           : xmlNodePtr;
  certNode               : xmlNodePtr;
  iCerts                 : Integer;
  inCerts                : array of string;
  sCert                  : string;
  mngr                   : xmlSecKeysMngrPtr;
  SignerId               : string;
  DerCert                : TBytes;
procedure Clear;
begin
  if Assigned(mngr)    then xmlSecKeysMngrDestroy(mngr);
  if Assigned(dsigCtx) then xmlSecDSigCtxDestroy(dsigCtx);
end;
begin
  Result := xmlDSigStatus(xmlSecDSigStatusUnknown);
  if not Assigned(signNode) then Exit;
  xSignature := xmlSecFindNode(signNode,xmlSecNodeSignatureValue,xmlSecDSigNs);
  if not Assigned(xSignature) then Exit;
  SigValue               := Mime64Decode(NodeGetValue(xSignature));
  ObjectNode             := xmlSecFindNode(signNode,StrPtr('Object'),xmlSecDSigNs);
  xEncapsulatedTimeStamp := selectNodeByName(ObjectNode,EncapsulatedTimeStampNodeName);
  if Assigned(xEncapsulatedTimeStamp) then TSPValue := Mime64Decode(NodeGetValue(xEncapsulatedTimeStamp))
                                      else TSPValue := nil;
  xEncapsulatedOCSPValue := selectNodeByName(signNode,EncapsulatedOCSPValueNodeName);
  if Assigned(xEncapsulatedOCSPValue) then OCSPValue := Mime64Decode(NodeGetValue(xEncapsulatedOCSPValue))
                                      else OCSPValue := nil;
  mngr    := nil;
  dsigCtx := nil;
  iCerts  := 0;
  SetLength(inCerts,iCerts);
  X509DataNode := xmlSecFindNode(signNode,xmlSecNodeX509Data,xmlSecDSigNs);
  if Assigned(X509DataNode) then
  begin
    mngr := xmlSecKeysMngrCreate;
    xmlSecCryptoAppDefaultKeysMngrInit(mngr);
    certNode := xmlSecFindNode(X509DataNode,xmlSecNodeX509Certificate,xmlSecDSigNs);
    while Assigned(certNode) do
    begin
      sCert   := NodeGetValue(certNode);
      DerCert := Mime64Decode(sCert);
      sCert   := '-----BEGIN CERTIFICATE-----'+sCert+CRLF+'-----END CERTIFICATE-----'+CRLF;
      Inc(iCerts);
      SetLength(inCerts,iCerts);
      inCerts[iCerts-1] := sCert;
      if Signer='' then
      begin
        SignerId := GetAttribute(certNode,'id');
        if SignerId<>'' then Signer := sCert;
      end;
      if xmlSecCryptoAppKeysMngrCertLoadMemory(mngr,BytePtr(DerCert),Length(DerCert),xmlSecKeyDataFormatCertDer,xmlSecKeyDataTypeTrusted)<0 then
      begin
        Clear;
        Exit;
      end;
      certNode := certNode.next;
    end;
  end;
  dsigCtx := xmlSecDSigCtxCreate(mngr);
  if Assigned(dsigCtx) then
  begin
    dsigCtx.flags := Flags;
    if xmlSecDSigCtxVerify(dsigCtx,signNode)=0 then Result := xmlDSigStatus(dsigCtx.status)
                                               else Result := xmlDSigStatus(xmlSecDSigStatusInvalid);
    if Result<>xmlDSigStatusSucceeded then xmlSecDSigCtxDebugDump(dsigCtx,xmlSecDSigOutput);
  end;
  Clear;
end;
begin
  InitUnit;
  Result   := xmlDSigStatus(xmlSecDSigStatusUnknown);
  xmlDoc   := xmlParseMemory(StrPtr(xmlContent),Length(xmlContent));
  rootNode := xmlDocGetRootElement(xmlDoc);
  if Assigned(rootNode) then
  begin
    if SameText(PtrToStr(rootNode.name),'ThreeDSecure') then
    begin
      refNode := xmlSecFindNode(rootNode,StrPtr('PARes'),nil);
      if Assigned(refNode) then
      begin
        PatchId(refNode,refStr);
        Flags := Flags or XMLSEC_DSIG_FLAGS_USE_VISA3D_HACK;
      end;
    end;
    signNode := xmlSecFindNode(rootNode,xmlSecNodeSignature,xmlSecDSigNs);
    while Assigned(signNode) do
    begin
      Result   := VerifyNode(signNode);
      signNode := signNode.next;
    end;
  end;
  xFreeDoc(xmlDoc);
end;

Best regards.

[lsh123]

1) Can you verify that the signature is valid using the xmlsec1 command line tool?

2) What error did you get back?

3) Admittedly last time I wrote something in Pascal was in 1992 if I remember correctly, thus my knowledge is outdated. But reading the code it seems that you are doing some hacks around certificates and around fixing IDs / Visa3D. I don't think you need cert hack and I would love to understand what PatchID() method is doing.

4) Looks like you are re-using the same context for verifying multiple signature nodes. This is not supported. You need to create new context for each verification.

[hafedh-trimeche]

Thank you for your prompt response.

Please note the attached file to be verified:

xmlsec.txt

A log generated by command line using MSYS2 libraries:

SignedInfo References (ok/all): 3/3
Manifests References (ok/all): 0/0
= VERIFICATION CONTEXT
== Status: succeeded
== flags: 0x00000000
== flags2: 0x00000000
== Id: "DSIG-FB6C90792F"
== Key Info Read Ctx:
= KEY INFO READ CONTEXT
== flags: 0x00000000
== flags2: 0x00000000
== enabled key data: all
== RetrievalMethod level (cur/max): 0/1
== TRANSFORMS CTX (status=0)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: NULL
=== uri xpointer expr: NULL
== EncryptedKey level (cur/max): 0/1
=== KeyReq:
==== keyId: rsa
==== keyType: 0x00000001
==== keyUsage: 0x00000002
==== keyBitsSize: 0
=== list size: 0
== Key Info Write Ctx:
= KEY INFO WRITE CONTEXT
== flags: 0x00000000
== flags2: 0x00000000
== enabled key data: all
== RetrievalMethod level (cur/max): 0/1
== TRANSFORMS CTX (status=0)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: NULL
=== uri xpointer expr: NULL
== EncryptedKey level (cur/max): 0/1
=== KeyReq:
==== keyId: NULL
==== keyType: 0x00000001
==== keyUsage: 0xffffffff
==== keyBitsSize: 0
=== list size: 0
== Signature Transform Ctx:
== TRANSFORMS CTX (status=2)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: NULL
=== uri xpointer expr: NULL
=== Transform: exc-c14n (href=http://www.w3.org/2001/10/xml-exc-c14n#)
=== Transform: rsa-sha256 (href=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256)
=== Transform: membuf-transform (href=NULL)
== Signature Method:
=== Transform: rsa-sha256 (href=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256)
== Signature Key:
== KEY
=== method: RSAKeyValue
=== key type: Public
=== key usage: -1
=== key not valid before: -1744982296
=== key not valid after: 1736050408
=== rsa key: size = 4096
=== list size: 1
=== X509 Data:
==== Key Certificate:
=== X509 Certificate
==== Subject Name: ebank.strong-data.com
==== Issuer Name: US, Let's Encrypt, R3
6a:b2:d4:ff:c1:d5:e5:32:b1:42:78:a3:6f:97:48:f8:68:04
==== Certificate:
=== X509 Certificate
==== Subject Name: Digital Signature Trust Co., DST Root CA X3
==== Issuer Name: Digital Signature Trust Co., DST Root CA X3
6b:40:f8:2e:86:39:30:89:ba:27:a3:d6:80:b0:af:44
==== Certificate:
=== X509 Certificate
==== Subject Name: US, Let's Encrypt, R3
==== Issuer Name: Digital Signature Trust Co., DST Root CA X3
df:cd:16:0c:a9:84:8c:21:c8:a4:14:83:04:75:01:40
==== Certificate:
=== X509 Certificate
==== Subject Name: ebank.strong-data.com
==== Issuer Name: US, Let's Encrypt, R3
6a:b2:d4:ff:c1:d5:e5:32:b1:42:78:a3:6f:97:48:f8:68:04
== SignedInfo References List:
=== list size: 3
= REFERENCE VERIFICATION CONTEXT
== Status: succeeded
== Id: "REF-SIG-FB6C90792F"
== URI: "#xpointer(/)"
== Type: "http://www.w3.org/2000/09/xmldsig#"
== Reference Transform Ctx:
== TRANSFORMS CTX (status=2)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: NULL
=== uri xpointer expr: #xpointer(/)
=== Transform: enveloped-signature (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
=== Transform: exc-c14n (href=http://www.w3.org/2001/10/xml-exc-c14n#)
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
=== Transform: membuf-transform (href=NULL)
== Digest Method:
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
= REFERENCE VERIFICATION CONTEXT
== Status: succeeded
== Id: "REF-XAdES-FB6C90792F"
== URI: "#XAdES-FB6C90792F"
== Type: "http://uri.etsi.org/01903#SignedProperties"
== Reference Transform Ctx:
== TRANSFORMS CTX (status=2)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri:
=== uri xpointer expr: #XAdES-FB6C90792F
=== Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
=== Transform: exc-c14n (href=http://www.w3.org/2001/10/xml-exc-c14n#)
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
=== Transform: membuf-transform (href=NULL)
== Digest Method:
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
= REFERENCE VERIFICATION CONTEXT
== Status: succeeded
== Id: "REF-KEY-INFO-FB6C90792F"
== URI: "#KEY-INFO-FB6C90792F"
== Reference Transform Ctx:
== TRANSFORMS CTX (status=2)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri:
=== uri xpointer expr: #KEY-INFO-FB6C90792F
=== Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
=== Transform: exc-c14n (href=http://www.w3.org/2001/10/xml-exc-c14n#)
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
=== Transform: membuf-transform (href=NULL)
== Digest Method:
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
== Manifest References List:
=== list size: 0

The Visa3D hack is used to patch the PaRes file used for 3DSecure (file attached). The Visa Id is different from XML specified id. The Patch can help! 3D.txt

Please also note that a new context is exclusively used for a verification for a single signature. A lookup is set to find multiple signatures inside the same document. Signatures will be verified one by one. Please also note that the file to be verified includes only one signature.

An UBL (http://docs.oasis-open.org/ubl/UBL-2.1.html) Invoice would be signed by multiple entities. It consists on an XML file embedded into a PDF one: The PDF is PAdES compliant and the XML file embedded should be compliant with XAdES.

Best regards.

[hafedh-trimeche]

The Log related to Verification is:

--------------------
Msg          : data and digest do not match
ErrorObject  : sha256
ErrorSubject : 
Func         : xmlSecOpenSSLEvpDigestVerify
--------------------

[hafedh-trimeche]

Hello,

Solved for then file https://github.com/lsh123/xmlsec/files/6174205/3D.txt.

xmlsec.xml still INVALID.

Problem solved by invoking xmlSecDSigCtxInitialize or setting enabledReferenceUris to xmlSecTransformUriTypeAny:

    ret := xmlSecDSigCtxInitialize(dsigCtx,mngr); {dsigCtx.enabledReferenceUris := xmlSecTransformUriTypeAny;}
    if ret<>0 then
    begin
      Clear;
      Exit;
    end;

But I still getting Errors generated by Error Function Callback:

Msg          :  
ErrorObject  : 
ErrorSubject : xmlSecPtrListIsValid(list)
Func         : xmlSecPtrListFinalize

Best regards.

[lsh123]

The xmlsec usually prints a stack trace of errors. Any chance you can try to see the whole trace?

[hafedh-trimeche]

Please find attached Log Files xmlSec.Log xmlSecDSig.Log

[hafedh-trimeche]

Updated xmlSec log file to include more information.

[hafedh-trimeche]

Hello,

Trying to switch to NSS Crypto but the verification failed! Openssl passed.

D:\msys\mingw64\bin>xmlsec1 --verify --crypto nss --store-references D:\Developer\lib\LibXML\Verify\invoice.xml > C:\xmlsec.log
OK
SignedInfo References (ok/all): 2/2
Manifests References (ok/all): 0/0

D:\msys\mingw64\bin>xmlsec1 --verify --crypto nss --store-references D:\Developer\lib\LibXML\Verify\xmlsec.xml > C:\xmlsec.log
func=xmlSecNssX509StoreVerify:file=../../../xmlsec-xmlsec-1_2_31/src/nss/x509vfy.c:line=264:obj=x509-store:subj=unknown:error=71:certificate verification failed:subject="CN=DST Root CA X3,O=Digital Signature Trust Co."; reason=-8101
func=xmlSecKeysMngrGetKey:file=../../xmlsec-xmlsec-1_2_31/src/keys.c:line=1253:obj=unknown:subj=xmlSecKeysMngrFindKey:error=1:xmlsec library function failed:
func=xmlSecDSigCtxProcessKeyInfoNode:file=../../xmlsec-xmlsec-1_2_31/src/xmldsig.c:line=793:obj=unknown:subj=unknown:error=45:key is not found:details=NULL
func=xmlSecDSigCtxProcessSignatureNode:file=../../xmlsec-xmlsec-1_2_31/src/xmldsig.c:line=508:obj=unknown:subj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec library function failed:
func=xmlSecDSigCtxVerify:file=../../xmlsec-xmlsec-1_2_31/src/xmldsig.c:line=346:obj=unknown:subj=xmlSecDSigCtxProcessSignatureNode:error=1:xmlsec library function failed:
Error: signature failed
ERROR
SignedInfo References (ok/all): 0/0
Manifests References (ok/all): 0/0
Error: failed to verify file "D:\Developer\lib\LibXML\Verify\xmlsec.xml"

D:\msys\mingw64\bin>xmlsec1 --verify --crypto openssl --store-references D:\Developer\lib\LibXML\Verify\xmlsec.xml > C:\xmlsec.log
OK
SignedInfo References (ok/all): 3/3
Manifests References (ok/all): 0/0

But using this file Invoice.txt Verification done without problem!

D:\msys\mingw64\bin>xmlsec1 --verify --crypto nss --store-references D:\Developer\lib\LibXML\Verify\invoice.xml > C:\xmlsec.log
OK
SignedInfo References (ok/all): 2/2
Manifests References (ok/all): 0/0

[lsh123]

NSS is more strict about certificates, in particular error -8101 means that the certificate type not approved for application. This might help: https://bugzilla.mozilla.org/show_bug.cgi?id=1049176

Unfortunately the log file shows only the last error. Based on the fact that xmlsec command line utility works just fine, I suspect that there is something un-initialized somewhere by Pascal. Make sure you call all the "init"/"shutdown" functions same way the C examples are doing it.

[hafedh-trimeche]

Hello,

I figured out that problem would be generated by Big-endian Little-endian byte order Problem: The log generated by xmlsec1 compiled under MSYS2 mingw64/mingw-w64-x86_64-xmlsec 1.2.31-1, which includes a successful validation, identifies the signing key as:

==== Key Certificate:
=== X509 Certificate
==== Subject Name: ebank.strong-data.com
==== Issuer Name: US, Let's Encrypt, R3
6a:b2:d4:ff:c1:d5:e5:32:b1:42:78:a3:6f:97:48:f8:68:04

The one generated using the same MSYS2 libraries (dynamically loaded by Pascal Module) identifies it as:

==== Key Certificate:
==== Subject Name: /CN=ebank.strong-data.com
==== Issuer Name: /C=US/O=Let's Encrypt/CN=R3
==== Issuer Serial: 468F848976FA37842B132E5D5C1FFD4B26A

The Issuer Serial numbers are not equal (inverted order ) and I don't know why log is different between Command Line & API Mode?

Thus, would the digest is computed with wrong or non-existent certificate ; hence, the xmlSecOpenSSLEvpDigestVerify error message.

The 3D.xml file is valid because there is no key reference and the signer key is identified as first one in the certificates list. For the problematic file, the key is identified by its id <X509Certificate xml:id="KEY-INFO-FB6C90792F">

Best regards.

Best regards.

[hafedh-trimeche]

Please also note that initialization is the same as set in C examples:

procedure InitUnit;
{$IFDEF DEBUG}
var
  xmlSecDSigFile : string;
{$ENDIF}
begin
  if @xmlSecInit<>nil then Exit;
  uLibXML2.InitUnit;
  uLibXMLSec.InitUnit;
  {$IFDEF DEBUG}
  xmlSecDSigFile := ApplicationMainPath+'xmlSecDSig.Log';
  FileDelete(xmlSecDSigFile);
  xmlSecDSigOutput := _fopen(PAnsiChar(StrPtr(xmlSecDSigFile)),'w+');
  xmlSecErrorsSetCallback(@DebugErrors);
  {$ENDIF}
  xmlInitParser;
  xmlSubstituteEntitiesDefault(1);
  __xmlIndentTreeOutput^ := 1;
  xmlSecInit;
  xmlSecCryptoDLLoadLibrary(StrPtr('openssl'));
  xmlSecCryptoAppInit(nil);
  xmlSecCryptoInit;
  __xmlLoadExtDtdDefaultValue^ := XML_DETECT_IDS or XML_COMPLETE_ATTRS;
  xmlKeepBlanksDefault(0);
  signKeyTemplate := xmlSecCryptoAppPkcs12LoadMemory(BytePtr(CMSP12Template),Length(CMSP12Template),'',nil,nil);
end;

[hafedh-trimeche]

Hello,

Please note that the Dump generated by OpenSSL confirms that the serial number is 04:68:f8:48:97:6f:a3:78:42:b1:32:e5:d5:c1:ff:d4:b2:6a and not 6a:b2:d4:ff:c1:d5:e5:32:b1:42:78:a3:6f:97:48:f8:68:04

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:68:f8:48:97:6f:a3:78:42:b1:32:e5:d5:c1:ff:d4:b2:6a
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = R3
        Validity
            Not Before: Feb 12 20:45:21 2021 GMT
            Not After : May 13 20:45:21 2021 GMT
        Subject: CN = ebank.strong-data.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:bb:5f:99:3b:48:66:9f:eb:8a:e6:5e:c9:b2:25:
                    7c:42:c5:e8:6d:26:a0:3c:a3:88:d0:6e:4f:4e:65:
                    dc:38:ac:29:9c:ee:83:7a:80:69:7e:f0:c2:1d:e8:
                    ac:6c:f8:52:dc:29:fe:6f:72:14:f7:96:b8:15:d2:
                    7a:83:ea:82:da:aa:07:35:8e:b5:f0:b1:ab:a6:72:
                    51:85:54:c9:19:b4:fb:ee:6b:b3:8e:a6:0b:98:d3:
                    85:b8:a5:13:d4:c9:7a:83:95:ba:34:88:0b:b4:ce:
                    98:32:45:5d:91:73:a9:a1:af:77:53:8a:68:7a:7b:
                    3a:d2:89:ad:24:13:bb:50:74:d2:a0:cb:e4:3f:18:
                    b1:4c:77:a7:d6:c2:f7:8f:f6:1b:9f:52:3e:33:0c:
                    8f:ba:52:62:9f:ff:e8:25:c6:d2:ca:78:56:c2:17:
                    cc:19:d4:b7:71:6f:d0:6a:4b:eb:7d:0e:4d:98:82:
                    9e:c3:11:82:b6:e9:49:b3:23:7e:1b:48:00:0f:e0:
                    77:cd:f1:41:c0:5b:e4:89:34:c1:89:14:4b:96:2b:
                    c5:07:d1:b4:f8:cc:15:3a:0f:a7:54:f6:19:59:4d:
                    5b:83:15:99:44:14:97:1b:ca:5e:0e:36:52:55:09:
                    c3:23:eb:72:23:46:f5:46:fe:78:2b:46:e1:e2:2c:
                    cb:66:cc:bf:5c:12:94:e3:fa:ba:c9:b6:96:89:58:
                    fb:61:c4:55:24:43:1f:6c:d9:e4:01:1d:5b:5d:a8:
                    94:a9:f3:f6:c0:51:03:c2:da:e1:11:f4:ac:82:10:
                    6a:29:a6:02:b6:eb:49:64:9d:10:c3:c4:68:32:aa:
                    24:c2:e2:65:e0:02:8a:f3:f6:a4:8d:ca:5e:df:2d:
                    c7:c8:f2:12:74:f9:1a:38:cf:e9:ec:17:68:13:f5:
                    4a:42:b2:40:8f:4a:4d:67:d3:00:48:48:fd:96:d9:
                    3a:cc:dd:8b:55:09:c2:58:3a:02:e4:ca:78:f2:fb:
                    70:dd:e3:1c:cf:68:bf:33:21:18:62:f5:01:e5:0a:
                    85:7e:1e:b1:23:22:08:8a:da:f9:3c:88:03:91:3a:
                    fc:86:83:32:30:72:f4:17:42:ee:ba:d2:66:76:a2:
                    66:f2:94:6e:dd:7a:4b:56:2e:42:e2:55:ef:95:ef:
                    3e:f4:0b:d9:cd:86:6e:cc:56:c7:78:d7:9a:ab:c5:
                    8b:e2:c7:14:1e:ae:ab:10:f2:99:fb:51:a8:c3:d3:
                    f0:d8:a4:08:27:3f:b0:f5:6f:e8:a2:f7:b6:50:6a:
                    d1:df:da:79:4f:b3:81:5a:80:52:ab:bc:3a:b2:5f:
                    be:fd:ae:aa:ca:96:ed:1e:14:3e:3a:b9:f7:11:0e:
                    e5:97:6f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                1B:70:2B:A0:E3:60:EB:54:F0:E2:65:22:9D:DF:FA:CA:A0:D2:36:BE
            X509v3 Authority Key Identifier:
                keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

            Authority Information Access:
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/

            X509v3 Subject Alternative Name:
                DNS:ebank.strong-data.com
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org

            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 94:20:BC:1E:8E:D5:8D:6C:88:73:1F:82:8B:22:2C:0D:
                                D1:DA:4D:5E:6C:4F:94:3D:61:DB:4E:2F:58:4D:A2:C2
                    Timestamp : Feb 12 21:45:21.786 2021 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:46:62:F0:6B:81:C7:25:0D:34:6E:4C:4D:
                                C9:A1:E7:A8:1A:D7:F7:0E:CA:75:74:46:1E:89:E9:35:
                                14:CD:50:80:02:21:00:A5:E1:61:D3:66:A3:20:D3:B4:
                                88:1A:59:F4:86:E8:97:78:A1:54:6D:3A:2E:FE:75:6F:
                                D5:11:8A:58:0C:6F:1A
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 7D:3E:F2:F8:8F:FF:88:55:68:24:C2:C0:CA:9E:52:89:
                                79:2B:C5:0E:78:09:7F:2E:6A:97:68:99:7E:22:F0:D7
                    Timestamp : Feb 12 21:45:21.839 2021 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:43:43:08:C4:A8:FD:B8:1F:3B:66:38:59:
                                B8:76:04:67:F6:3F:55:A5:3A:69:F5:C3:94:DC:D1:65:
                                80:16:4F:92:02:21:00:C6:3D:82:1E:F9:60:10:3E:2B:
                                FD:0D:34:ED:77:7B:FE:7E:CA:CC:89:15:44:34:36:0E:
                                6A:D6:91:EA:4F:47:4C
    Signature Algorithm: sha256WithRSAEncryption
         84:f4:d8:28:18:be:8f:93:2e:d0:8f:fa:a0:af:94:a7:cd:bd:
         88:bc:75:0a:5a:26:57:85:64:85:c9:f5:b4:3c:dd:a6:40:92:
         25:15:78:e1:14:ba:c2:72:1e:da:71:92:9e:81:11:03:aa:a6:
         c4:c8:fd:16:d7:6c:c9:1e:24:bd:9c:e6:a0:08:59:3c:e7:eb:
         46:cb:1d:e2:66:61:ec:78:55:b6:30:c8:50:ee:45:6f:81:a8:
         b5:52:c6:1b:a4:1d:b6:25:6c:90:4b:6e:1d:5b:91:a7:80:83:
         04:d5:e0:16:c3:6d:fc:e3:af:66:78:d5:64:97:18:3a:7c:36:
         77:c5:b6:e3:fd:b6:86:04:42:3a:1f:cd:f1:bf:29:a8:80:e5:
         b5:a5:1d:7c:a9:d2:c8:27:12:e6:a6:fc:7b:8a:52:a1:42:af:
         a8:73:38:25:61:99:12:8a:46:c0:af:29:0a:87:c8:9a:98:69:
         e1:e0:78:aa:0d:39:d5:43:f0:04:15:4b:c8:48:7d:c6:53:5d:
         bb:3a:af:27:ec:03:6e:ac:d5:ce:0e:57:8b:1a:a2:76:6d:e7:
         97:53:39:1f:93:39:2b:14:98:ad:37:3c:e9:ca:2f:29:5a:a9:
         b2:ae:6f:53:9a:5d:bb:3b:5f:6d:00:f7:73:a1:99:fc:44:cb:
         21:0b:92:0b

[hafedh-trimeche]

Hello, I am amazed to see the difference between the GOOD and VALID digest representations.

For the GOOD one CRLF are preserved:

= REFERENCE VERIFICATION CONTEXT
== Status: succeeded
== Id: "REF-XAdES-FB6C90792F"
== URI: "#XAdES-FB6C90792F"
== Type: "http://uri.etsi.org/01903#SignedProperties"
== Reference Transform Ctx:
== TRANSFORMS CTX (status=2)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: 
=== uri xpointer expr: #XAdES-FB6C90792F
=== Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
=== Transform: exc-c14n (href=http://www.w3.org/2001/10/xml-exc-c14n#)
=== Transform: membuf-transform (href=NULL)
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
=== Transform: membuf-transform (href=NULL)
== Digest Method:
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
== PreDigest data - start buffer:
<xades:SignedProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Id="XAdES-FB6C90792F">
<xades:SignedSignatureProperties>
<xades:SigningTime>2021-03-19T04:46:53.884Z</xades:SigningTime>
<xades:SigningCertificateV2>
<xades:Cert>
<xades:CertDigest>
<DigestMethod xmlns="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">xfGnAKJzKef7Wpx+tR/byYvYD/A=</DigestValue>
</xades:CertDigest>
<xades:IssuerSerialV2>MEwwNqQ0MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJSMwISBGj4SJdvo3hCsTLl1cH/1LJq</xades:IssuerSerialV2>
</xades:Cert>
</xades:SigningCertificateV2>
</xades:SignedSignatureProperties>
<xades:SignedDataObjectProperties>
<xades:DataObjectFormat ObjectReference="#REF-SIG-FB6C90792F">
<xades:MimeType>text/xml</xades:MimeType>
</xades:DataObjectFormat>
<xades:DataObjectFormat ObjectReference="#REF-KEY-INFO-FB6C90792F">
<xades:MimeType>text/xml</xades:MimeType>
</xades:DataObjectFormat>
</xades:SignedDataObjectProperties>
</xades:SignedProperties>
== PreDigest data - end buffer

On the other hand, the INVALID one is compact despite the usage of the same Transfomrs

=== uri xpointer expr: #XAdES-FB6C90792F
=== Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
=== Transform: exc-c14n (href=http://www.w3.org/2001/10/xml-exc-c14n#)
=== Transform: membuf-transform (href=NULL)
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
=== Transform: membuf-transform (href=NULL)

and

=== uri xpointer expr: #XAdES-FB6C90792F
=== Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
=== Transform: exc-c14n (href=http://www.w3.org/2001/10/xml-exc-c14n#)
=== Transform: membuf-transform (href=NULL)
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
=== Transform: membuf-transform (href=NULL)

= REFERENCE VERIFICATION CONTEXT
== Status: invalid
== Id: "REF-XAdES-FB6C90792F"
== URI: "#XAdES-FB6C90792F"
== Type: "http://uri.etsi.org/01903#SignedProperties"
== Reference Transform Ctx:
== TRANSFORMS CTX (status=2)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: 
=== uri xpointer expr: #XAdES-FB6C90792F
=== Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
=== Transform: exc-c14n (href=http://www.w3.org/2001/10/xml-exc-c14n#)
=== Transform: membuf-transform (href=NULL)
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
=== Transform: membuf-transform (href=NULL)
== Digest Method:
=== Transform: sha256 (href=http://www.w3.org/2001/04/xmlenc#sha256)
== PreDigest data - start buffer:
<xades:SignedProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Id="XAdES-FB6C90792F"><xades:SignedSignatureProperties><xades:SigningTime>2021-03-19T04:46:53.884Z</xades:SigningTime><xades:SigningCertificateV2><xades:Cert><xades:CertDigest><DigestMethod xmlns="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod><DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">xfGnAKJzKef7Wpx+tR/byYvYD/A=</DigestValue></xades:CertDigest><xades:IssuerSerialV2>MEwwNqQ0MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJSMwISBGj4SJdvo3hCsTLl1cH/1LJq</xades:IssuerSerialV2></xades:Cert></xades:SigningCertificateV2></xades:SignedSignatureProperties><xades:SignedDataObjectProperties><xades:DataObjectFormat ObjectReference="#REF-SIG-FB6C90792F"><xades:MimeType>text/xml</xades:MimeType></xades:DataObjectFormat><xades:DataObjectFormat ObjectReference="#REF-KEY-INFO-FB6C90792F"><xades:MimeType>text/xml</xades:MimeType></xades:DataObjectFormat></xades:SignedDataObjectProperties></xades:SignedProperties>
== PreDigest data - end buffer

[hafedh-trimeche]

Hello,

Solved by removing xmlKeepBlanksDefault(0) form Initialization process.

Thank you and sorry for disturbing.

[lsh123]

Good catch! Glad you solved it!