none
BizTalk MIME/SMIME decoder Receive Port: There was an authentication failure. Failed to decode the S/MIME message RRS feed

  • Question

  • I'm trying to send a multipart/mixed message from Postman to a BizTalk WCF-WebHTTP Receive Port. I'm using a custom pipeline with the MIME/SMIME Decoder component. The headers from PostMan are as follows:

    POST /MyService.svc/fhir/Bundle HTTP/1.1
    Connection: Keep-Alive
    Accept-Encoding: gzip,deflate
    MIME-Version: 1.0
    Content-Type: multipart/mixed;  boundary={9FB8E5D9-FF42-4DB4-BEB0-B45EEB7E34A9}
    cache-control: no-cache
    Postman-Token: 2250d5bb-8507-43ab-bc19-1d42c95f6ab9
    Authorization: Basic aWhhXGNkeC1idW1zOjEyMzQ1Ng==
    User-Agent: PostmanRuntime/7.6.1
    Accept: */*
    Host: myhost.com
    content-length: 487

    I'm not doing any encryption and don't intend to (it is an HTTPS endpoint however), but when BizTalk receives the message, the following error occurs from the MIME/SMIME decoder:

    There was a failure executing the receive pipeline: "myPipeline Version=1.0.0.1, Culture=neutral, PublicKeyToken=c8a8104f93b0eaea" Source: "MIME/SMIME decoder" Receive Port: "RP.MyPort.2Way" URI: "/MySubmitService.svc" Reason: There was an authentication failure. "Failed to decode the S/MIME message. The S/MIME message may not be valid.".

    From everything I have Googled, the "authentication failure" relates to certificates, but I'm not using any (that I know of)...is it referring to the fact that this is an HTTPS service, or is there further encryption of the MIME message? If the latter, that is not my intention.

    The message looks like this:

    --3otEV66PR4J93LqTtsFMmmvm8x2KGDE2BrISy0n
    Content-Dis name="xml"
    Content-Type: application/xml+fhir
    Content-Transfer-Encoding: 8bit
    
    <?xml version="1.0" encoding="UTF-8"?>
    <ns1:Bundle xmlns:ns1="http://hl7.org/fhir" xmlns:ns="http://www.w3.org/1999/xhtml">
      <ns1:id value="00ba7375-6d44-4105-988a-23b033bf0628"/>
     ...snip...
    </ns1:Bundle>
    
    --3otEV66PR4J93LqTtsFMmmvm8x2KGDE2BrISy0n
    Content-Dis name="file"; filename="application_info.pdf"
    Content-Type: application/pdf
    Content-Transfer-Encoding: binary
    
    %PDF-1.4
    %Óëéá
    1 0 obj
    <</Creator (Mozilla/5.0 \(Windows NT 10.0; Win64; x64\) AppleWebKit/537.36 \(KHTML, like Gecko\) Chrome/68.0.3440.106 Safari/537.36)
    /Producer (Skia/PDF m68)
    /CreationDate (D:20180914112340+00'00')
    /ModDate (D:20180914112340+00'00')>>
    ...snip...
    %%EOF
    --3otEV66PR4J93LqTtsFMmmvm8x2KGDE2BrISy0n--

    Is there anything I'm missing with this? Do I need to generate some certificates and install them on the BizTalk server? Or is there actually something wrong with the message? Or a way to not do encryption?

    If it comes down to being the certificates and I'm sending from Postman, what certificate would it even be using to encrypt? How would I tell?

    I've seen Seroter's post about certs and encrypting/decrypting, but I honestly have no idea what certs I would even use...I'm not encrypting in PostMan. I even made a console .Net app to submit the message, no encryption and the same error is returned.

    What else can I try?

    I'm trying to send a multipart/mixed message from Postman to a BizTalk WCF-WebHTTP Receive Port. I'm using a custom pipeline with the MIME/SMIME Decoder component. The headers from PostMan are as follows:

    POST /MyService.svc/fhir/Bundle HTTP/1.1
    Connection: Keep-Alive
    Accept-Encoding: gzip,deflate
    MIME-Version: 1.0
    Content-Type: multipart/mixed;  boundary={9FB8E5D9-FF42-4DB4-BEB0-B45EEB7E34A9}
    cache-control: no-cache
    Postman-Token: 2250d5bb-8507-43ab-bc19-1d42c95f6ab9
    Authorization: Basic aWhhXGNkeC1idW1zOjEyMzQ1Ng==
    User-Agent: PostmanRuntime/7.6.1
    Accept: */*
    Host: myhost.com
    content-length: 487
    

    I'm not doing any encryption and don't intend to (it is an HTTPS endpoint however), but when BizTalk receives the message, the following error occurs from the MIME/SMIME decoder:


    • Edited by Bensonio Thursday, April 18, 2019 4:02 PM
    Wednesday, April 17, 2019 10:47 PM