ITextSharp文档签名显示无效

Question

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

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

图2：中介证书是可信的。

另一个奇怪的事情是，对于时间戳签名，当我将根证书作为受信任的根证书添加到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, LtvVerificathtml" target="_blank">ion.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

...
    <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.
         :             }
...

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

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

Internet X.509公钥基础结构证书和证书吊销列表(CRL)配置文件（RFC 5280）的当前规范指定：

当使用HTTP或FTP URI方案时，URI必须指向[RFC2585]中指定的单个DER编码CRL。

（第4.2.1.13.CRL分发点）

尽管HTTPS方案本质上只是HTTP方案的安全变体，因此PKI肯定地和不必要地违反了RFC的精神，但它似乎并没有违反它的文字。

因此，CRL检索类（如iText的CRLClientOnline)最好检查检索到的CRL的格式，并在必要时转换它。

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

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

另一方面，如果您显式信任最终实体证书，即创建时间戳的证书，Adobe验证器将立即信任时间戳。不需要检查是否吊销显式信任的证书...因此，在这种情况下，时间戳是LTV启用的。

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

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

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

至于添加crls和ocsps，据我所知，对于添加LTV，您必须向文档和最终文档时间戳中的所有签名添加验证，就像我在提供的代码中所做的那样，不是这样吗？