CA文档签名证书为何无法在Adobe Reader中显示可信标识？

Question

CA文档签名证书在Adobe Reader中无法显示“可信标识”（如绿色锁形图标或“已验证签名者身份”提示），常见原因包括：证书未由Adobe认可的全球可信根CA（如DigiCert、GlobalSign）签发，或其根证书未预置于Adobe的AATL（Approved Trust List）；证书链不完整（缺少中间CA证书），导致验证失败；签名时未正确嵌入OCSP/CRL响应或时间戳，使Adobe无法实时校验证书状态；证书用途扩展（EKU）未包含“Document Signing”（1.3.6.1.4.1.311.10.3.12）；或使用了仅限内部PKI的私有CA证书（未提交至AATL审核）。此外，Adobe Reader版本过旧、本地信任设置被修改、或PDF签名采用PAdES-LTV封装不规范，亦会导致可信标识缺失。排查需结合Adobe Acrobat的“签名属性→验证详情”逐级分析证书链、吊销状态与策略合规性。

Answer 1

```html

一、现象确认：Adobe Reader中签名“可信标识”缺失的直观表现

用户打开已签名PDF时，签名面板仅显示“签名有效”或“签名已验证”，但无绿色锁形图标、未出现“已验证签名者身份”提示，亦无“由可信证书颁发机构签发”的明确声明。此为表层现象，需区分是“验证通过但不可信”（策略级失败）还是“验证失败”（技术级错误）。

二、基础校验：Adobe Reader版本与本地信任库状态检查

• 验证Adobe Acrobat/Reader DC（2023.003.20365+）或Acrobat 2020（v20.013.20074+）——旧版本不支持AATL v4+及PAdES-LTV增强策略；
• 路径：编辑 → 首选项 → 安全（增强）→ 信任管理器 → 重置为Adobe默认设置；
• 执行certmgr.msc（Windows）检查本地“受信任的根证书颁发机构”是否被手动禁用或策略锁定。

三、证书链完整性分析：从终端证书到根CA的逐级追溯

在Adobe Acrobat中右键签名 → “签名属性” → “验证详情”，展开证书路径。常见断裂点包括：

层级	典型问题	诊断命令示例
终端证书	未携带完整Subject Alternative Name（SAN）或CN含非法字符	openssl x509 -in docsign.crt -text -noout | grep -A1 "Subject:"
中间CA	签名时未嵌入中间证书（如DigiCert SHA2 Secure Server CA），导致链无法上溯	pdfsig -v signed.pdf | grep -A5 "Certificate chain"
根CA	根证书未列入Adobe AATL（如自建Root CA或区域性CA未提交审核）	查阅Adobe AATL公开列表

四、扩展密钥用法（EKU）与证书策略合规性深度核查

Document Signing证书必须显式声明EKU OID 1.3.6.1.4.1.311.10.3.12（Microsoft文档签名），且不得仅含1.3.6.1.5.5.7.3.2（clientAuth）或1.3.6.1.5.5.7.3.4（emailProtection）。使用以下命令验证：

openssl x509 -in docsign.crt -text -noout | grep -A1 "X509v3 Extended Key Usage"
# 正确输出应包含：1.3.6.1.4.1.311.10.3.12 (Document Signing)

五、吊销状态与时间戳：OCSP/CRL嵌入与PAdES-LTV封装规范性

Adobe要求LTV（Long-Term Validation）签名必须内嵌：① 签名时刻有效的OCSP响应或CRL；② 可信时间戳（RFC 3161）；③ 所有中间证书。缺失任一将导致“验证成功但不可信”。验证流程如下：

flowchart TD A[打开PDF签名属性] --> B{验证详情页} B --> C[查看“吊销信息”是否标记为“已验证”] C --> D[检查“时间戳”是否存在且由AATL认可TSAs签发] D --> E[确认“证书链”下所有证书均有对应OCSP响应] E --> F[若任一为“未检查”或“不可用”，则LTV封装失败]

六、私有CA与AATL准入机制：企业PKI如何获得Adobe信任

• 内部CA证书永远无法在默认Adobe Reader中显示绿色标识，除非完成AATL全流程：
• ① 向Adobe提交CA合规性审计报告（WebTrust或ETSI EN 319 411）；
• ② 提供根证书、CPS文档、OCSP服务SLA承诺；
• ③ 通过Adobe第三方实验室渗透测试；
• ④ 进入季度AATL发布清单（平均周期12–18个月）。

七、签名工具链排查：主流SDK对PAdES-BES/LTV的支持差异

不同签名库对PAdES标准实现程度差异显著：

工具/SDK	PAdES-BES支持	LTV封装能力	备注
iText 7.2+	✅ 完整	✅（需调用LtvVerification类）	需显式添加OCSP/CRL响应
OpenSSL + qpdf	⚠️ 仅基础	❌ 不原生支持	需额外脚本注入CMS结构
Adobe Sign API	✅	✅（自动嵌入）	依赖Adobe后端AATL信任链

八、调试黄金组合命令：终端快速定位根因

# 1. 提取签名证书并解析
pdfsig signed.pdf | grep -A20 "Certificate:" | openssl x509 -text -noout

# 2. 检查证书链是否可构建至AATL根
openssl verify -untrusted intermediate.crt -CAfile aatls_roots.pem docsign.crt

# 3. 验证OCSP响应有效性（需提前获取响应DER）
openssl ocsp -respin ocsp.der -CAfile aatls_roots.pem -VAfile intermediate.crt -text

九、企业级解决方案架构建议

面向金融、政务等高合规场景，推荐采用分层签名策略：

• 第一层：使用AATL预置CA（如GlobalSign Document Signing CA）签发终端证书；
• 第二层：部署私有OCSP响应器（与企业LDAP集成），确保吊销实时性；
• 第三层：签名服务集成RFC 3161可信时间戳（如DigiCert TSA或阿里云可信时间戳）；
• 第四层：PDF生成阶段强制启用PAdES-LTV，并通过pdfsig -v与Adobe验证双轨校验。

十、持续监控与自动化验证体系

在CI/CD流水线中嵌入签名可信度门禁：

# Jenkins/GitLab CI脚本片段
if ! pdfsig -v "$PDF_FILE" | grep -q "Signature is valid and trusted"; then
  echo "❌ PDF签名未达Adobe可信标准，阻断发布"
  exit 1
fi
# 同时调用Adobe Verify API（需OAuth2授权）进行云端策略校验

```