签名无效。签名验证时出错
Invalid Signature. Error during the signature verification
我正在尝试从外部远程服务签署文档。签名过程分两个阶段进行。远程服务在第一阶段期待 base64 编码哈希 并在身份验证后发出令牌，在第二阶段，我们再次传递相同的哈希和接收到的令牌并获得base64 签名哈希。我在这里附上了错误签名的文件。
document
如果有人可以分析它并指导我评估无效签名背后的原因。我正在使用 iText7 执行 pdf 相关操作。
已更新
我根据反馈做了一些修正。该文件现在正在更改。
Altered Document
您的第一个示例文件
本节重点介绍原始示例文件，document - 2021-05-01T170114.722.pdf。
PDF 中有两个明显的问题。由于您不共享您的关键代码，我只能猜测原因。
文件中有两个 PDF
您共享的 111794 字节长的文件实际上是两个 PDF 的串联，第一个 PDF 准备在签名容器占位符中仅使用 00 进行签名，然后是同一个文件，其中包含其他内容.两个 PDF 中的每一个都恰好 55897 字节长。
造成这种情况的一个典型原因是使用文件流作为输出，该文件流以文件模式 Append 而不是 Create 打开，可能与使用相同的文件作为输入和输出相结合。
不正确的签名容器
您使用子过滤器 adbe.pkcs7.detached 创建了签名。这意味着要嵌入到签名占位符中的数据必须是 CMS 签名容器（CMS 是 PKCS#7 的后继者）。但是，在您的签名文件中，只有一个裸签名值，没有签名容器。
一个典型的原因是在签名期间使用 IExternalSignatureContainer 实现（通常在 PdfSigner.signDeferred 或 PdfSigner.signExternalContainer 的上下文中），其 sign 方法不正确 returns 裸签名值，不是签名容器。
一般
您描述的用例，即使用需要哈希和 returns 签名哈希的签名服务，听起来确实像您的服务 returns 只是一个裸签名值，没有签名容器.
一般来说，这是一种典型的情况，其中 不 使用延迟签名，而是使用 PdfSigner.signDetached 和 IExternalSignature 实现，其 sign 方法首先对其参数字节数组进行哈希处理，然后将哈希值传递给服务并检索签名哈希，最后 returns 该签名哈希。
您的第二个示例文件
本节重点介绍您第一次更新时的示例文件，document - 2021-05-03T200650.926.pdf。
正如您所说，您已对第一个文件进行了更正以解决上面列出的问题。在你的第二个文件中找到的问题是详细的。尽管如此，您仍然没有分享您的关键代码，所以我仍然只能猜测问题的原因。
不正确的messageDigest属性值
您在签名中使用了 SHA256 哈希算法。
messageDigest 签名属性具有此值：
80FE8AC2DE959A2C791A72A68176EB312D77BD201F8D07CD5A42CC9A4370AAFB
但这与
的 PDF 签名字节的散列不匹配
83134B9C1C7CAE9E4FB0A1FCB37A30A6783F81AF70F6EF4B68865E83C2E11717
显然，您的哈希计算例程有误，或者您只是对错误的数据进行了哈希处理。由于您没有显示您的代码，我无法判断您做错了什么。
不正确的签名哈希值
您的签名字节签署哈希值
80FE8AC2DE959A2C791A72A68176EB312D77BD201F8D07CD5A42CC9A4370AAFB
但这与签名属性的散列不匹配
9C0D3D2249E69AFA1078F03159332C439B8407A526CBA77C9E9B2701A7EE8131
显然，您的哈希计算例程有误，或者您只是对错误的数据进行了哈希处理。由于您没有显示您的代码，我无法判断您做错了什么。
唯一明显的是，您在两种情况下声明了相同的散列值。但是这些哈希重合是非常难以置信的。
我正在尝试从外部远程服务签署文档。签名过程分两个阶段进行。远程服务在第一阶段期待 base64 编码哈希 并在身份验证后发出令牌，在第二阶段，我们再次传递相同的哈希和接收到的令牌并获得base64 签名哈希。我在这里附上了错误签名的文件。 document
如果有人可以分析它并指导我评估无效签名背后的原因。我正在使用 iText7 执行 pdf 相关操作。
已更新
我根据反馈做了一些修正。该文件现在正在更改。 Altered Document
您的第一个示例文件
本节重点介绍原始示例文件，document - 2021-05-01T170114.722.pdf。
PDF 中有两个明显的问题。由于您不共享您的关键代码，我只能猜测原因。
文件中有两个 PDF
您共享的 111794 字节长的文件实际上是两个 PDF 的串联，第一个 PDF 准备在签名容器占位符中仅使用 00 进行签名，然后是同一个文件，其中包含其他内容.两个 PDF 中的每一个都恰好 55897 字节长。
造成这种情况的一个典型原因是使用文件流作为输出，该文件流以文件模式 Append 而不是 Create 打开，可能与使用相同的文件作为输入和输出相结合。
不正确的签名容器
您使用子过滤器 adbe.pkcs7.detached 创建了签名。这意味着要嵌入到签名占位符中的数据必须是 CMS 签名容器（CMS 是 PKCS#7 的后继者）。但是，在您的签名文件中，只有一个裸签名值，没有签名容器。
一个典型的原因是在签名期间使用 IExternalSignatureContainer 实现（通常在 PdfSigner.signDeferred 或 PdfSigner.signExternalContainer 的上下文中），其 sign 方法不正确 returns 裸签名值，不是签名容器。
一般
您描述的用例，即使用需要哈希和 returns 签名哈希的签名服务，听起来确实像您的服务 returns 只是一个裸签名值，没有签名容器.
一般来说，这是一种典型的情况，其中 不 使用延迟签名，而是使用 PdfSigner.signDetached 和 IExternalSignature 实现，其 sign 方法首先对其参数字节数组进行哈希处理，然后将哈希值传递给服务并检索签名哈希，最后 returns 该签名哈希。
您的第二个示例文件
本节重点介绍您第一次更新时的示例文件，document - 2021-05-03T200650.926.pdf。
正如您所说，您已对第一个文件进行了更正以解决上面列出的问题。在你的第二个文件中找到的问题是详细的。尽管如此，您仍然没有分享您的关键代码，所以我仍然只能猜测问题的原因。
不正确的messageDigest属性值
您在签名中使用了 SHA256 哈希算法。
messageDigest 签名属性具有此值：
80FE8AC2DE959A2C791A72A68176EB312D77BD201F8D07CD5A42CC9A4370AAFB
但这与
的 PDF 签名字节的散列不匹配83134B9C1C7CAE9E4FB0A1FCB37A30A6783F81AF70F6EF4B68865E83C2E11717
显然，您的哈希计算例程有误，或者您只是对错误的数据进行了哈希处理。由于您没有显示您的代码，我无法判断您做错了什么。
不正确的签名哈希值
您的签名字节签署哈希值
80FE8AC2DE959A2C791A72A68176EB312D77BD201F8D07CD5A42CC9A4370AAFB
但这与签名属性的散列不匹配
9C0D3D2249E69AFA1078F03159332C439B8407A526CBA77C9E9B2701A7EE8131
显然，您的哈希计算例程有误，或者您只是对错误的数据进行了哈希处理。由于您没有显示您的代码，我无法判断您做错了什么。
唯一明显的是，您在两种情况下声明了相同的散列值。但是这些哈希重合是非常难以置信的。