iText 7.1 PDF签名OCSP配置：GetEncoded方法入参与返回null排查

核心入参定义（纠正常见命名误解） #

两个证书参数的本质逻辑和版本命名无关，不存在新版本要求传根证书的规则，iText 7.7版本的参数重命名属于易误导的命名偏差，实际取值规则始终统一：

• 第一个参数（checkCert）：必须传入当前用于PDF签名的终端实体证书，即存储在PKCS11硬件中、最终用来生成PDF签名值的用户证书，禁止传入根证书、中间CA证书。
• 第二个参数（原版本名issuerCert、新版本被误命名为rootCert）：必须传入直接为上述终端实体证书签发证书的父级CA证书，而非证书链最顶端的自签名根证书，更不需要传入OCSP服务端自身的证书。

注：OCSP客户端的交互逻辑不需要预置任何服务端证书，它仅通过终端证书序列号、终端证书直接签发者的公钥哈希组装请求报文，向指定地址发起查询即可。

触发返回null的常见原因 #

结合你的代码场景，无响应返回基本是以下几类问题导致：

• 参数传值错位：尝试将根证书作为待校验证书、终端签名证书作为签发者证书传入，生成的OCSP请求中携带的哈希值完全不匹配服务端校验逻辑，无法获取有效响应。
• 签发者证书层级不匹配：比如证书链结构为「根CA → 中间CA → 终端签名证书」时，错误将最顶端的根证书作为第二个参数传入，会导致请求中携带的签发者公钥哈希和服务端存储的序列信息不匹配，被服务端判定为无效请求。
• OCSP地址不匹配：硬编码的OCSP地址和终端证书AIA扩展字段中声明的OCSP服务地址不一致，或当前运行环境的网络策略拦截了对该地址的访问，导致请求无法送达。

适配你现有签名流程的正确配置方式 #

先梳理你手头的证书链组件，再按规则传参：

1. 提取终端签名证书（即你代码中原本对应的cert变量，就是存在硬件里的签名用证书）作为第一个入参
2. 顺着证书链找到直接给上述终端证书发证的CA证书（通常为中间CA证书，不是rootCertificate变量对应的自签名根）作为第二个入参
3. 读取终端证书的AIA扩展字段，取字段中明确标注的OCSP服务地址作为第三个入参，不要硬编码和证书不一致的地址
   正确调用示例参考：

OCSPVerifier ocspVerifier = new OCSPVerifier(null, null);
IOcspClient ocspClient = new OcspClientBouncyCastle(ocspVerifier);
// 按规则传参，第二个参数传直接签发终端证书的CA，不是根证书
byte[] ocspBytes = ocspClient.GetEncoded(
    terminalSignCert,
    directIssuerCaCert,
    "终端证书AIA中声明的OCSP服务地址"
);

if (ocspBytes == null)
    Console.WriteLine("ocsp is null");
else
    Console.WriteLine("ocsp is not null");

// 后续PKCS7容器构建逻辑保持原有流程即可
PdfPKCS7 sgn = new PdfPKCS7(null, c.ToArray(), HashAlgorithm, false);
byte[] sh = sgn.GetAuthenticatedAttributeBytes(hash, ocspBytes, null, PdfSigner.CryptoStandard.CMS);
byte[] extSignature = GetSignatureFromHashViaPkcs11(sh, pin);
sgn.SetExternalDigest(extSignature, null, DigestEncryptionAlgorithm);
var ret = sgn.GetEncodedPKCS7(hash, tsaClient, ocspBytes, null, PdfSigner.CryptoStandard.CMS);

排查步骤 #

按顺序排查即可定位问题：

• 校验终端证书的AIA扩展内容，确认使用的OCSP地址和证书内置声明完全一致
• 核对第二个入参的证书层级，确保是直接签发终端证书的父级CA，而非最顶端的根证书
• 在签名运行环境直接连通测试OCSP地址，排除网络策略拦截、服务不可用的问题

内容的提问来源于stack exchange，提问作者Manuel