MSIS7093：未使用预期的签名算法对邮件进行签名。（但它是）
我有一个信任SP的ADFS。
我为我的信赖方信任添加了签名验证证书，但我收到以下错误：
MSIS7093：MSIS7093：消息未使用预期签名算法签名。消息使用签名算法http://www.w3.org/2000/09/xmldsig#rsa-sha1.预期签名算法http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
这看起来很清楚，但与实际上下文不一致：签名验证证书是由SHA-256生成的，而不是SHA-1。
如果我按照错误消息，将安全散列算法从SHA-256改为SHA-1，它就能工作，并且我可以执行SSO认证。但我对此并不满意，原因有二:
- SHA1不再安全了。
- 我不知道为什么要将安全哈希算法设置为SHA-1，而实际使用的证书是SHA-256
证书是使用 openssl 生成的：
openssl req-x509-node-sha256-day 365-newkey rsa： 2048-keyoutsamlkratos.key-outsamlkratos.crt
有人知道为什么会这样吗？
共有1个答案
证书的哈希与用于拥有数据的哈希并不真正相关。
例如，当对XML进行签名时，使用许多受支持的散列算法之一对规范的XML进行散列。然后，用签名算法(如http://www.w3.org/2000/09/xmldsig#rsa-sha1算法)更新XML，告诉服务器这是使用过的算法。
在服务器端，IdP通常有一个指定签名算法的设置。本质上是告诉IdP它应该用特定的算法验证请求
如果要发送 sha1 并且错误是它期望 sha256，则存在不匹配，并且 SP（应用程序）可能需要更改设置。
你通常可以使用SAML解码器插件从浏览器中看到正在发送的内容。
同样，这取决于SP应用程序配置为发送什么，以及IdP配置为接受什么（如果适用），并且与证书（RSA-sha256中的RSA）的关系非常密切。它需要基于RSA的证书，但只要支持组合，则可以是许多事情（例如，DSA证书不能支持sha512，因为规范不允许）
-
下面是C 17形式的规则([basic.lval]/8)，但它在其他标准中看起来很相似(C 98中是“lvalue”而不是“glvalue”): 8如果程序试图通过以下类型之一以外的glvalue访问对象的存储值，则行为未定义： (8.4)-对应于对象动态类型的有符号或无符号类型 这条规则听起来像是“除非你做X，否则你会得到UB”，但这并不意味着如果你做了X，你就不会得到UB，正如人们所期望的那样
-
我正在开发一个非google play应用程序，它将作为一个未签名的发行版apk交付给设备制造商，他们将用自己的私有系统密钥签名来签名。 系统签名是必不可少的，因为应用程序使用具有保护级别signatureOrSystem的权限。由于该应用程序不会作为系统特权应用程序安装，因此必须使用系统的签名进行签名。 由于我无法访问最终签名的apk（或签名密钥本身），我不知道如何测试我正在交付的产品（在真实的
-
我试着从一封签名邮件中提取一个或多个PDF文件。我尝试将smime.p7m加载到 mimeMessage=mimeMessage.Load(mem)；//mem是使用File.WriteAllBytes（File,FileAttachment.Content）创建的文件的MemoryStream；（EWS文件附件） 这不起作用,因为文件的开头是： 所以我试着用 convert.FromBase64
-
您好，我可以使用iText 5对PDF文档进行数字签名。我需要再次签署PDF，而在验证PDF时，它表明初始签名无效。您可以在此处查看再次签名的文件。 请参见下面用于标记的代码， 请让我知道出了什么问题。
-
我正在尝试用DSS签署PDF文档，我的问题是我无法在服务器a中计算文档的哈希值，然后在服务器B中签署它。 知道服务器A包含PDF文档，我们在服务器B中检索用于签名的证书 我的问题是如何在不需要证书的情况下计算服务器a中文档的哈希值。然后在服务器B上发送签名？ 更新： ******散列的准备和计算******** ******散列签名******** ********PDF错误：*********
-
签名算法描述如下： 1.将请求参数按参数名升序排序； 2.按请求参数名及参数值相互连接组成一个字符串：...； 3.将应用密钥分别添加到以上请求参数串的头部和尾部：<请求参数字符串>； 4.对该字符串进行MD5（全部大写），MD5后的字符串即是这些请求参数对应的签名； 5.该签名值使用sign参数一起和其它请求参数一起发送给服务开放平台。 参数示例 { "name": "file.uplo