SMIME signed message verification

[Michael Richardson]

Harald Koch <root at c-works.net> wrote:
    >> Am 29.10.2020 um 14:12 schrieb Michael Richardson <mcr at sandelman.ca>
    >>> - "Unable to verify content integrity: Missing data"
    >>> - "The system is unable to find out the sign algorithm of the inbound message"
    >>
    >>> I digged a bit deeper into the ASN1 data („cat signature.base64 | base64 -d | openssl asn1parse -inform DER" ), leading to my assumption that the algorithm provided for signature contained differs:
    >>> - openSSL indicates „rsaEncryption"
    >>> - Java indicates „sha512WithRSAEncryption"
    >>
    >> The first error you got seems inconsistent with this problem.
    >> Is is possible that one of you are sending CMS structures with
    >> out-of-band content?

    > Yes, the signed message is contained in a HTTP(S) multipart request
    > with more payload and header information, sure. The only different part
    > is the signed content, all other content has been manually checked,
    > they are exactly the same. May it be possible that the CMS data which
    > openSSL generates is much bigger due to unneeded certificate
    > information, which makes the Java process stumble over the input?

so, do have detached content then?

And MIME and HTTP is involved?  My bet is that you have CRLF/LF issues, which
you might not see unless you look at the raw packets --- after the TLS is
removed, which is a hassle, but there is a way in openssl to get that data
put somewhere, but I can't recall what it is.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20201029/504ef749/attachment.sig>