获取“消息中的 WS 安全标头无效”。调用 ACAGetTransmitterBulkRequestStatus 时答案

【问题标题】：Getting "WS Security Header in the message is invalid." when calling ACAGetTransmitterBulkRequestStatus获取“消息中的 WS 安全标头无效”。调用 ACAGetTransmitterBulkRequestStatus 时
【发布时间】：2016-07-21 11:22:48
【问题描述】：

我已经能够成功调用第一个 ACA Web 服务，我认为获得状态将是一件轻而易举的事。 Bo-o-oy 我怎么错了！

我对状态服务使用了与提交服务相同的设置...我得到“WS Security header is invalid error！”是什么赋予了？！？！签名生成代码与我用于提交的代码相同！如果有人能够阐明这里可能有什么问题，我将不胜感激？我知道，应该对以下标签进行数字签名（我确实对它们进行了签名）：

ACABusinessHeader
ACABulkRequestTransmitterStatusDetailRequest
安全时间戳

这是我的请求：

POST https://la.www4.irs.gov/airp/aca/a2a/1095BC_Status_Request_AATS2016 HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "RequestSubmissionStatusDetail"
Host: la.www4.irs.gov
Content-Length: 5217
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<s:Envelope xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
            <SignedInfo>
                <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" />
                <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
                <Reference URI="#_1">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                    <DigestValue>KBLc15A=</DigestValue>
                </Reference>
                <Reference URI="#_2">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                    <DigestValue>dhkLQhzfkc=</DigestValue>
                </Reference>
                <Reference URI="#TS-ccf5abbbd36940f693d56b21ab489674">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                    <DigestValue>O179zVlJnyo=</DigestValue>
                </Reference>
            </SignedInfo>
            <SignatureValue>REDUCTED</SignatureValue>
            <KeyInfo>
                <wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                    <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">-- Base64ed cert ---</wsse:KeyIdentifier>
                </wsse:SecurityTokenReference>
            </KeyInfo>
        </Signature>
        <u:Timestamp u:Id="TS-ccf5abbbd36940f693d56b21ab489674">
            <u:Created>2016-04-01T15:02:00.505Z</u:Created>
            <u:Expires>2016-04-01T15:12:00.506Z</u:Expires>
        </u:Timestamp>
    </wsse:Security>
    <abh:ACABusinessHeader u:Id="_1" xmlns:abh="urn:us:gov:treasury:irs:msg:acabusinessheader">
        <UniqueTransmissionId xmlns="urn:us:gov:treasury:irs:ext:aca:air:7.0">REDUCTED</UniqueTransmissionId>
        <Timestamp xmlns="urn:us:gov:treasury:irs:common">2016-04-01T11:02:58Z</Timestamp>
    </abh:ACABusinessHeader>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <ACABulkRequestTransmitterStatusDetailRequest u:Id="_2" version="1.0" xmlns="urn:us:gov:treasury:irs:msg:irstransmitterstatusrequest">
        <ACABulkReqTrnsmtStsReqGrpDtl xmlns="urn:us:gov:treasury:irs:ext:aca:air:7.0">
            <ReceiptId xmlns="urn:us:gov:treasury:irs:common">Receit Id</ReceiptId>
        </ACABulkReqTrnsmtStsReqGrpDtl>
    </ACABulkRequestTransmitterStatusDetailRequest>
</s:Body>

更新 1： 我越来越相信，我们的证书和身份服务已经解决了他们的问题。看起来他们无法将收据 ID 映射到正确的证书。至少他们符合，我一直在发送他们的 XML 在结构上没有任何问题。但他们无法确定实际问题。美国国税局要求我再次在电子邮件中向他们提出我的请求，以进行进一步调查，我照做了。现在将等待，c 会发生什么。

【问题讨论】：

你是如何生成 xml 的？我只能通过手动创建我的 SOAP 信封和标头来让我的解决方案与 IRS 一起使用，但主要由 SignedXml 类生成的 Security 元素除外。
@Bon 感谢您的回复！我正在使用 SignedXml 类手动生成签名。所以我认为在那个部门我们是在同一条船上。我不明白为什么提交服务的工作不适用于状态一？我看到你让它为这两种服务都工作，有什么区别使状态服务工作？
我认为对我来说唯一的区别是签署他们 pdf 中指定的不同元素。
@Bon 谢谢你的重播。我知道了。我在想，该服务需要不同的算法来生成签名。显然事实并非如此。作为一根稻草：您可以分享一下请求成功的样子吗？
@Bon 你传入的是已经在 IRS 网站上加载的 KeyIdentifier 字段证书，对吧？

标签： web-services soap ws-security xml-signature irs

【解决方案1】：

（我没有足够的声誉来添加评论）

@fatherOfWine，我注意到您的 Transform 元素中缺少 InclusiveNamespaces 元素。抱歉，您可能已经知道了，包含的命名空间已被纳入 XML 的规范化以及最终 SHA1 摘要的计算中。

向 IRS 的 ACA 技术支持发送电子邮件，并要求他们查看您发送的三个摘要值是否通过或匹配他们的计算。他们至少能够确定您的哪些摘要值通过和未通过检查。让他们知道您发送请求的 TCC 和当地时间。

【讨论】：

感谢您的回复。但是只有当它们的定义在被签名的文档之外时，才需要包含 AFAIK 的命名空间。除此之外，我的提交服务运行良好，它使用相同的签名代码，为我在这个问题中提出的请求生成签名。对鹅有好处的东西应该对鹅有好处，n'es pas？:))

【解决方案2】：

嗯，长话短说。状态服务现在正在运行。毕竟，IRS 开发团队删除了客户端配置，这些配置被标记为已删除，之后，状态服务似乎有了工作的精神。我对如何解决这种情况有点厌烦，但如果它最终开始起作用 - 就让它吧！

【讨论】：