iTextSharp未呈现数字签名

Question

我已经阅读了I-TEXT数字签名e-text，以及MKL之前回复的帖子(他似乎和Bruno一起在这个主题上是权威)。

本质上，我有一个Azure应用程序服务，它从公司的签名API获得数字签名(Base64)和证书链。该公司的签名应用编程接口返回Base64格式的签名以及证书链。

我只想将签名对象/容器插入到pdf中，这样当最终用户打开pdf时，它就会显示在签名面板中。我更喜欢使用延迟签名。

我已经从第4章的“客户端签名示例”转到了MKL的“如何在不提前知道签名者证书的情况下创建PDF签名”中的延迟签名。

Company API返回一个“纯”签名，我非常确定，它还返回一个由3个字符串组成的证书链。

我需要注意的是，我已经预先准备好了根证书和子证书(2个.cer文件)，但是我现在并没有使用它们来“准备”pdf进行哈希处理，因为延迟签名的例子显然没有使用它们。对于容器构造代码(在从Company API获得响应之后)，我使用了从公司API返回的3certs链，但我也尝试了两个.cer文件，但都没有用。

我的代码和示例中的代码之间唯一的区别是，我构建了3个X509CertificateParser().ReadCertificate(certificateBytes)；，而不是byte[] certificateBytes = THE_RETRIEVED_CERTIFICATE_BYTES；X509Certificate x509Certificate = new x509Certificates (从Company API返回的链中的每个字符串对应一个。

不幸的是，事情不能工作，我在Acrobat中得到这些错误:签名是无效的，有错误的格式或信息包含在这个签名，签名的身份还没有被验证，签名时间是从时钟上的签名者的computer...also如果我点击下面的证书详细信息下面这个错误在Acrobat是空白的。这几乎就是我在尝试"clientserversigning example“时遇到的错误。

我真的很努力，想知道会是什么.我是不是应该试着从12000开始修改预估大小，并将其提高？或者我在Acrobat中得到的错误，也许他们暗示来自Company API的证书链没有被签名延迟容器构造代码拾取……我正在努力，但任何建议都将不胜感激

埃文

为了清楚起见，我遵循的是第4章的客户端服务器签名示例，但一旦使用公司API的签名重新创建了pdf，我就会得到以下内容。

​

​

它说: 1)信息的格式有误2)签名者的身份没有被验证3)签名时间来自签名者计算机上的时钟

现在，至于在散列发送签名之前对pdf进行“准备”，我在ClientSigning示例中没有看到任何专门准备它的东西，我可以假设IText库在幕后准备它吗？

Answer 1

在你的问题和评论中，你似乎特别感兴趣的是

• 是否可以使用仅将证书与签名一起返回的签名API，以及
• 何时要延迟签名。

是否可以使用仅在签名后提供用户证书的签名API

要回答这个问题，首先必须弄清楚所讨论的签名应用程序接口创建了哪种类型的签名，是普通签名值(例如CMS签名)还是完全成熟的PKCS#1签名容器。

如果它创建了完整的CMS签名容器，您可以根据任意签名配置文件创建签名，只要签名容器符合要求(通常都是这样)。他们唯一的限制是您不能在签名可视化中获得来自签名者证书的信息，因为该可视化是在PDF的签名数据中定义的。

如果它只创建普通签名值，那么您可以做的最好的事情就是创建并嵌入简单的CMS容器，这些容器在签名属性中不包含指向签名者证书的指针(如果它们一开始都有签名属性的话)。许多感兴趣的签名策略确实需要这样的指针，但至少Adobe Reader接受没有这些指针的签名。

如果你在这种情况下，想尝试用这样简单的签名容器创建签名，你可以使用this answer中的代码，“如何在不知道签名者证书的情况下创建签名”一节。

何时使用延迟签名

延迟签名和其他iText签名调用之间的区别是而不是，延迟签名需要更少的信息(与ExternalContainer签名相比)。

与其他iText签名方法不同，signDeferred重用最外层的已填充签名字段进行签名，仅替换其中的签名容器。

方法名称来自于它最常见的用例：

• 在第一步中，使用signExternalContainer来填充签名字段(可能首先创建，然后)，其中IExternalSignatureContainer实现计算要签名的文档散列，但还不返回最终的CMS容器，仅返回一些(通常)空数组。然后，将所生成的具有填充的签名域(尽管没有最终签名容器)的PDF临时存储(在文件系统或database).
• In中)。在第二步骤中，请求并(可能异步地)等待用于所确定的文档散列的签名容器。在最后一步中，使用
• 将检索到的签名容器注入到在第一步骤中准备的PDF中。

这种延迟签名过程通常在这样的设置中是优选的，在该设置中，第二步，即签名容器的创建和检索，可能花费比希望保持签名中的文档所需的资源被阻塞的时间更长的时间。这特别包括由远程服务器或客户端生成的签名，特别是当签名过程等待某些第三方许可或激活时。