问题描述
我正在尝试从外部远程服务签署文档。签署过程分两个阶段进行。远程服务在第一阶段期待 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 方法错误地返回了一个裸签名值，不是签名容器。
一般情况
您描述的用例，即使用需要散列并返回签名散列的签名服务，听起来您的服务确实只返回一个裸签名值，没有签名容器。
一般来说，这是一种典型情况，其中不使用延迟签名，而是使用 PdfSigner.signDetached 和 IExternalSignature 实现，其 sign 方法首先散列它的参数字节数组，然后将哈希值传达给服务并检索签名哈希，最后返回签名哈希。
您的第二个示例文件
本节重点介绍您第一次更新 document - 2021-05-03T200650.926.pdf 中的示例文件。
正如您所说，您已进行更正以解决上面列出的第一个文件的问题。要在您的第二个文件中找到的问题是详细信息。尽管如此，你仍然没有分享你的关键代码，所以我仍然只能猜测问题的原因。
不正确的 messageDigest 属性值
在您的签名中，您使用 SHA256 哈希算法。
messageDigest 签名属性具有以下值：
80FE8AC2DE959A2C791A72A68176EB312D77BD201F8D07CD5A42CC9A4370AAFB
但这与 PDF 的签名字节的哈希不匹配
83134B9C1C7CAE9E4FB0A1FCB37A30A6783F81AF70F6EF4B68865E83C2E11717
显然，您的散列计算例程中存在错误，或者您只是散列了错误的数据。由于您没有展示您的代码，我无法判断您做错了什么。
签名哈希值不正确
您的签名字节对哈希值进行签名
80FE8AC2DE959A2C791A72A68176EB312D77BD201F8D07CD5A42CC9A4370AAFB
但这与签名属性的哈希不匹配
9C0D3D2249E69AFA1078F03159332C439B8407A526CBA77C9E9B2701A7EE8131
显然，您的散列计算例程中存在错误，或者您只是散列了错误的数据。由于您没有展示您的代码，我无法判断您做错了什么。
唯一明显的是，您在两种情况下都声明了相同的哈希值。但这些哈希值重合是极不可信的。