如何在.NET Framework WCF中使用RSA-SHA1构建SOAP消息安全客户端

• 对接目标为老旧IBM Websphere Web服务，要求通过多证书实现传输层与消息层双层安全
• 已在SoapUI完成调试验证：发送使用RSA-SHA1算法签名消息体的SOAP请求可正常获取正确响应
• 在.NET Framework平台C#控制台应用中对接时，尝试不同SecurityBindingElement创建方式均失败：
  • 调用CreateCertificateOverTransportBindingElement()：返回XPath表达式对应Body节点未被签名覆盖的错误
  • 调用CreateCertificateSignatureBindingElement()：触发契约仅支持单向操作的异常
  • 调用CreateMutualCertificateDuplexBindingElement()：返回请求身份验证失败的错误
  • 最接近可用的SecurityBindingElement.CreateMutualCertificateBindingElement()：服务返回SOAP错误ERRO00001 验证类型配置'asymmetric'不允许使用算法'http://www.w3.org/2000/09/xmldsig#hmac-sha1'
• 已尝试所有DefaultAlgorithmSuites预设选项，均无法生成符合要求的RSA-SHA1签名，初步判断与微软停止支持SHA1算法的默认策略有关。

1. 是否可以为WCF自定义配置RSA-SHA1签名算法？
2. 是否可以绕过WCF手动构建SOAP XML，通过SignedXML节点完成消息体签名？
3. 是否存在其他可行的实现方案？

问询附件包含三类材料：SoapUI生成的可正常工作的SOAP报文示例、当前编写的自定义绑定实现代码、代码生成的触发错误响应的SOAP报文，所有代码、技术标识符、XML命名空间、算法标识均保持原始技术形态不变。

1. WCF自定义RSA-SHA1签名配置的可行性 #

可以实现，不需要完全脱离WCF框架。
核心操作步骤：

• 自定义类继承SecurityAlgorithmSuite，重写所有算法映射属性，将非对称签名算法指定为http://www.w3.org/2000/09/xmldsig#rsa-sha1，摘要算法指定为http://www.w3.org/2000/09/xmldsig#sha1，对称加密、非对称加密、密钥派生算法按服务端实际要求匹配即可。
• 在程序配置文件app.config的runtime节点下添加兼容开关，解除.NET Framework对SHA1弱算法的默认封禁：

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=true;Switch.System.IdentityModel.DisableCngCertificates=false" />

• 将自定义算法套件实例赋值给MutualCertificateBindingElement的DefaultAlgorithmSuite属性，同时将MessageSecurityVersion设置为适配旧版WS-*规范的WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10，调用SetKeyDerivation(false)关闭默认的密钥派生逻辑（旧版Websphere不支持该特性），将消息保护级别设置为与服务要求一致。
  之前出现的hmac-sha1报错，本质是默认绑定配置在非对称认证场景下错误使用了对称签名逻辑，完成上述配置后即可生成正确的非对称RSA-SHA1签名。

2. 手动构建SOAP+SignedXML签名的可行性 #

完全可行，这是对接老旧非标准WS-*服务稳定性最高的方案，完全不受WCF默认安全策略限制。
实现注意事项：

• 不依赖WCF客户端代理，直接使用HttpWebRequest或HttpClient发送原始XML格式请求。
• 构造完成SOAP信封XML后，调用System.Security.Cryptography.Xml.SignedXml类完成签名逻辑：加载客户端签名证书的私钥赋值给SigningKey属性，添加对SOAP Body节点的引用，指定摘要算法为SHA1、签名方法为RSA-SHA1、规范化算法为老旧服务通用的http://www.w3.org/2001/10/xml-exc-c14n#。
• 生成签名节点后，必须严格对照SoapUI导出的正常报文结构，将签名插入到SOAP Header的wsse:Security节点对应位置，所有XML命名空间前缀、节点Id属性格式、签名引用URI必须与SoapUI生成的报文完全一致——旧版IBM Websphere的WS-Security实现校验逻辑非常僵化，哪怕是自动生成的命名空间前缀不一致、节点顺序不对都可能触发校验失败。
• 传输层要求的客户端证书认证直接在HTTP请求对象上绑定对应证书即可，与消息层签名逻辑互不干扰。调试时可直接将生成的完整SOAP报文与SoapUI正常报文做逐文本对比，完全对齐后即可正常调用。

3. 其他可落地的实现方案 #

• 采用WCF客户端消息检查器（IClientMessageInspector）方案：不需要完全抛弃WCF生成的客户端代理和序列化逻辑，只在请求发送前拦截WCF生成的原始SOAP消息，移除WCF自动生成的不符合要求的签名节点，调用SignedXml重新生成符合要求的RSA-SHA1签名后插回消息，相比完全手写SOAP可节省大量参数序列化、反序列化的开发工作量。
• 运行环境优先选择.NET Framework 4.7.2及以下版本，不要尝试用.NET Core/.NET 5+版本对接这类旧服务，新版.NET已经移除了大量旧WS-Security规范的兼容逻辑，调试成本极高。
• 如果后续有协调服务端改造的空间，优先推动服务端升级支持SHA256及以上强度的签名算法，SHA1已经存在已知碰撞风险，上述兼容方案仅适用于老旧系统临时对接场景。

内容的提问来源于stack exchange，提问作者Ryano