签名和验证工作正常，直到第二次对文件进行签名（使用用户的证书）。之后第一个签名不知何故变得无效
正如评论中已经澄清的那样，如果希望第一个签名保持有效，则必须以附加模式（iText 术语）/作为增量更新（PDF 规范术语）应用第二个签名。否则，签名字节很可能会发生变化，并且签名哈希值不再匹配。
- 是否有可能检查文档在两次签名之间是否被修改？
更准确地说，您的问题应该是是否可以检查两个签名之间的文档修改是否超出了嵌入第二个签名的合理更改。
简而言之：在您的用例中这是可能的，但仍然意味着相当多的工作和与 iText 低级 API 的杂耍。详细地：
一般来说，这并不是一件小事，因为添加具有可视化的新签名似乎是合理的
- 更改相关页面的注释，因为签名可视化是小部件注释；
- 更改 PDF 表单定义，因为签名锚定为表单字段；
- 可以为其他表单字段创建外观流，以修复它们在签名文件中的确切外观；
- 可以更改元数据流以记录签名行为；
- 可能会更改文档的数字安全存储；
- 可能会改变更多。
因此，检查更改是否属于这些类别中的任何一个并非易事。
此外，您还必须检查其他作弊行为，例如签名可视化可能会覆盖整个页面并显示该内容的操纵版本......
但你说你的用户
必须使用 Adobe Acrobat 签名
这可能使您的任务有些可行：如果您使用 Adobe Acrobat 将示例签名添加到您之前首先签署的多个文档中，则可以分析 Adobe Acrobat 在签署文档时通常会更改哪些文档。
利用这些知识，您可以实现一个类来检查是否仅存在这些更改。
- 如果不是 - 以编程方式（使用 itextsharp）检查 PDF 文件在生成之后和签名之前是否已更改的替代方法是什么？
如果没有您应用的第一个签名，情况就会变得更加困难，因为用户的 PDF 签名软件没有理由限制文档中的内部结构更改，只要它们不影响其外部行为。所以我会尝试使用双重签名。
或者，您可以尝试将原始文档和用户签名的版本呈现为位图并进行比较。仅应在放置用户签名可视化的区域中存在差异。这不会验证交互式 PDF 功能，但至少会验证打印输出的完整性。
渲染还不是 iText 的一个功能，但解析框架同时已经发展到足以充当渲染功能的基础。
应用第一个签名甚至可以帮助防止意外更改：如果您为用户提供空签名字段并自己使用认证签名，则可以将“允许的更改”限制为仅填充该空签名字段，并且 Adobe Acrobat 通常除非另有明确说明，否则尊重此类限制。
有关集成 PDF 签名的背景，请查看这个答案 https://security.stackexchange.com/a/35131/16096关于信息安全堆栈交换。
