ITextSharp 文档签名显示无效

Question

所以最近一直在搞PDF文档的签名，今天遇到了一个新奇的问题。因此，当我签署文档（该文档实际上是在服务器上签署的）并在我的机器上打开该文档时，签名显示有效并且启用了 LTV，因此几乎可以按预期工作。但是当我在我老板的电脑上打开同一个文档时，它显示即使在证书被信任后也无法验证签名的身份，但是如果我打开证书属性它说证书有效并且吊销成功。这可能是什么原因造成的？

图 1：证书本身是可信的。

图 2：中间证书受信任。

图 3：受信任的根证书

签名文件：https://drive.google.com/file/d/0B9RyqgJoa6W8WlBLemVETXJRU0U/view?usp=sharing

另一个奇怪的事情，对于时间戳签名，当我将根证书作为受信任的根证书添加到 adobe 时，它说 LTV 未启用，但是如果我将 GlobalTrustFinder 证书本身添加为受信任的证书，它说LTV 已启用。有什么理由这样做吗？

非常感谢任何帮助

将LTV添加到现有签名块以及添加时间戳签名的代码：

private void SignDocumentSigningBlockAddLTVVerification(PdfStamper stamper, Certificate certificate)
    {
        LtvVerification ltvVerification = stamper.LtvVerification;
        List<string> signatureFieldNames = stamper.AcroFields.GetSignatureNames();
        ITSAClient tsaClient = new TSAClientBouncyCastle(_settingManager["DocumentSigningTimestampingServiceAddress"], String.Empty, String.Empty, Int32.Parse(_settingManager["DocumentSigningEstimatedTimestampSize"]), _settingManager["DocumentSigningEncryptionHashAlgorithm"]);
        IOcspClient ocspClient = new OcspClientBouncyCastle();
        ICrlClient crlClient = new CrlClientOnline(SignDocumentSigningBlockBuildChain(new X509Certificate2(certificate.Bytes, certificate.Password, X509KeyStorageFlags.Exportable)).ToList());

        PdfPKCS7 pkcs7 = stamper.AcroFields.VerifySignature(signatureFieldNames.Last());
        if (pkcs7.IsTsp)
        {
            ltvVerification.AddVerification(signatureFieldNames.Last(), ocspClient, crlClient, LtvVerification.CertificateOption.SIGNING_CERTIFICATE, LtvVerification.Level.OCSP_CRL, LtvVerification.CertificateInclusion.NO);
        }
        else
        {
            foreach (string name in stamper.AcroFields.GetSignatureNames())
            {
                ltvVerification.AddVerification(name, ocspClient, crlClient, LtvVerification.CertificateOption.WHOLE_CHAIN, LtvVerification.Level.OCSP_CRL, LtvVerification.CertificateInclusion.NO);
            }
        }
        ltvVerification.Merge();

        PdfSignatureAppearance appearance = stamper.SignatureAppearance;
        LtvTimestamp.Timestamp(appearance, tsaClient, null);
    }

亲切的问候

Answer 1

无法检查吊销

But when I open the same document on my boss's computer it shows that the identity of the signing could not be verified even after the certificate was trusted, but if I open the certificate properties it says that the certificate is valid and revocation was performed successfully. What could be the cause of this?

由于我查不到你老板的电脑，所以这肯定是猜测。所以...

试一试

你说证书是可信的但是涉及到很多证书。那么，你信任哪一个呢？根据你的截图

您不信任用户证书（如果您信任，则不会根据 CRL 检查该证书，而是在没有进一步测试的情况下被信任）。

可能您已经信任了您老板计算机上的根 CA 证书。如果您已经信任，不仅要检查最终用户证书是否被吊销，还要检查中间人CA证书（SAPOClass4 CA）！可能这就是你的问题所在

因此，当您在吊销选项卡上时，请select中间证书并查看是否可以对其执行吊销检查。如果不是，那就是你运行遇到的问题。

PS: 不是这样的

OP 测试了上面提到的想法但是

So I went back and checked all the certificates, and it seems that the CRL check is performed as expected.

所以，并没有我上面想的那么容易

the difference in setup was that i trusted the certificate that I signed with as the root certificate hence was showing up as successfully signed on my machine, I've now set up my security settings so that I have the same results as on my boss's computer.

好的，所以解释了这两台计算机上的结果之间的差异。

判断是CA证书的吊销状态还是您的用户证书的吊销状态有问题，请您重新配置您的设置并信任CA证书好吗？

如果此更改后问题仍然存在，则问题很可能与您的用户证书有关并正在检查其吊销状态。如果它消失了，问题很可能与检查 CA 证书的吊销状态有关。

I trusted the CA now, it still has the same problem, but if I trust the user cert marking the "Use this certificate as a trusted root" and Certified Documents" checkbox, the signature is shown as valid as well as LTV enabled, but only if I mark it as the root. In all other cases the signature has the warning stating that the revocation checks were not performed.

如果您立即信任您的用户证书，则无需进一步的麻烦就可以肯定地验证签名。毕竟，您确实信任该证书...

先不说，检查用户证书的时候已经出问题了。我会尝试调查更多。

PPS: 所以这就是为什么...

如果所有其他方法都失败了，请开始检查签名 左右我在找不到证书中真正糟糕的东西之后想。我在 ASN.1 转储实用程序中打开签名并...

...
    <30 42>
2174   66:             SEQUENCE {
    <06 09>
2176    9:               OBJECT IDENTIFIER '1 2 840 113583 1 1 8'
    <31 35>
2187   53:               SET {
    <30 33>
2189   51:                 SEQUENCE {
    <A0 31>
2191   49:                   [0] {
    <30 2F>
2193   47:                     SEQUENCE {
    <2D 2D>
2195   45:                       Unknown (Reserved) {
    <2D 2D>
2197   45:                         Unknown (Reserved) {
    <2D 42>
2199   66:                           Unknown (Reserved) {
    <45 47>
2201   71:                             [APPLICATION 5]
         :                   'IN X509 CRL-----.MIIfZzCCHU8CAQEwDQYJKo0...*.H..'
         :                   '............0...Ix<..N+'
         :                   Error: IA5String contains illegal character(s).
Error: Inconsistent object length, 7 bytes difference.
         :                             }
Error: Inconsistent object length, 30 bytes difference.
         :                           }
Error: Inconsistent object length, 32 bytes difference.
         :                         }
Error: Inconsistent object length, 32 bytes difference.
         :                       }
Error: Inconsistent object length, 32 bytes difference.
         :                     }
Error: Inconsistent object length, 32 bytes difference.
         :                   }
Error: Inconsistent object length, 32 bytes difference.
         :                 }
Error: Inconsistent object length, 32 bytes difference.
         :               }
Error: Inconsistent object length, 32 bytes difference.
         :             }
...

所以签名本身存在语法错误，更确切地说是在PDF签名证书吊销信息属性 (OID 1 2 840 113583 1 1 8)。

（用不同的查看器查看该区域，可以看到有一个文本（！）“-----BEGIN X509 CRL-----” - 似乎有一个文本 CRL 表示此处无效。)

Adobe Reader，因此，在签名验证期间尝试检查证书吊销时，检查可用于在签名期间添加吊销信息的签名属性，发现损坏的属性值并且似乎停止验证检查失败...

用于填写证书详细信息的代码window似乎是单独编码的

为什么？

有人可能想知道文本 CRL 表示如何恰好包含在您签名的 PDF 签名证书撤销信息属性中。

我查看了嵌入的“CRL”。它是 PEM 格式，在 47 字节后被截断。因此，我在证书 (https://pki.trustcentre.co.za/crl/sapo_c4ca.crl) 中给出的 URL 处访问了 CRL，并且我确实检索到了 PEM 格式的（完整）文本 CRL。签名创建代码似乎试图按原样包含它，但它被取消了。

PKI 以 PEM 格式而不是 DER 格式提供 CRL 是否错误？或者签名创建代码是否错误地假设在指向的位置找到 DER 编码的 CRL？

Internet X.509 Public 密钥基础设施证书和证书撤销列表 (CRL) 配置文件 (RFC 5280) 的当前规范指定：

When the HTTP or FTP URI scheme is used, the URI MUST point to a single DER encoded CRL as specified in [RFC2585].

(Section 4.2.1.13. CRL Distribution Points)

但它并没有说任何关于 HTTPS URI 方案的等效内容！

由于PKI采用HTTPS方案，因此，PKI可能被认为符合RFC的规定。

尽管 HTTPS 方案本质上只是 HTTP 方案的安全变体，因此 PKI 明确且不必要地违反了 RFC 的精神，但它似乎并未违反其字面意思。

因此，CRL 检索类（如 iText 的 CrlClientOnline）最好检查检索到的 CRL 的格式，并在必要时进行运行sform。

启用或不启用 LTV

一个解释

Another weird thing, for the timestamping signature, when I add the Root certificate as a trusted root certificate to adobe, it says that LTV is not enabled, but if I add the GlobalTrustFinder certificate itself as a trusted certificate it says that LTV is enabled. Any reason that it would do that?

这很明显：

如果您信任根证书，则必须检查中间 CA 和最终实体证书的吊销情况。由于您的文档中没有嵌入它们的 CRL 或 OCSP 响应，因此您的时间戳未启用 LTV。

另一方面，如果您明确信任最终实体证书，即创建时间戳的证书，Adobe 验证器会立即信任时间戳。无需检查明确信任的证书的撤销...因此，在这种情况下，时间戳已启用 LTV。

（术语“启用 LTV”是一个 Adobe 术语，具有非常可变的值。有关此术语和其他 LTV 相关术语的背景，请参见背景部分以及从那里引用的其他答案，)

后续问题

For the timestamping I'm a bit confused, I followed the code examples in the post you recomended, and the code I've used was a variation of that but in principle the same, why would the CRL and the OCSP responses not be embedded?

最大的区别是中的代码不应用文档时间戳，它只是添加验证相关信息（证书、CRL、OCSP 响应）。

Adobe 的专有术语“LTV-enabled” 指的是文档签名或文档时间戳，其中“验证 all[=129] 所需的所有信息=] PDF 中包含验证 Adobe Reader 安全设置上下文中的相关签名（包括签署 CRL、OCSP 响应和验证过程中使用的时间戳的签名）”。您的代码在添加验证相关信息后，添加了一个文档时间戳，因此验证该时间戳所需的信息通常在 PDF 中还没有。

ETSI 的标准化术语“具有 LTV 的 PDF 文档” 指的是带有验证相关信息的签名 PDF（例如“启用 LTV”的 PDF）加上最终文档时间戳。

您使用的 iText 示例代码尝试创建 ETSI“具有 LTV 的 PDF 文档”，因此必须进行调整以尝试创建一个 PDF，其中所有文档签名和时间戳都是 Adobe“启用 LTV” ".

As for adding the crls and ocsps, as far as I understood that for adding LTV, you have to add the validation to all signatures in the document and the final document time stamp, as I did in the code I provided, is this not the case?

LTV 有不同的用例，根据不同的用例，可能需要添加不同的信息。

ITextSharp 文档签名显示无效

ITextSharp Document Signing showing invalid

pdf

signing

itext

itextsharp