Enterprise 版本
签名证书的证书透明度策略
NextPDF Enterprise 让一个签名工作流程在签名之前能够考虑一份签名证书的证书透明度(CT)姿态。CT 是一个公开日志生态系统,证书在其中被记录,以便误签发可被察觉;一份记入 CT 的证书携带一个或多个签名证书时间戳(SCT)。NextPDF Enterprise 把一份证书的 CT 姿态表示为一个结果值——SCT 扩展是否存在、有多少个 SCT 存在且有效,以及它们由哪些日志签发——并提供一项最小 SCT 阈值检查。本页为行为层面:它说明该结果携带什么、阈值检查如何工作,以及 NextPDF 决定与不决定什么。
NextPDF Enterprise 表示并对一个 CT 结果做阈值检查;它不是一个 CT 日志、日志审计方,也不是监控方。该边界陈述于安全与合规。
前提条件已在前置数据中陈述,并在前提条件处重述。
版本与授权
标题为“版本与授权”的章节该能力随 NextPDF Enterprise(nextpdf/enterprise)发行,并通过一份 Enterprise 层级的授权信封激活。没有该授权的部署不会加载该能力的类。比较各版本并获取授权。
该能力做了什么
标题为“该能力做了什么”的章节一份记入 CT 的证书携带 SCT。依据 RFC 6962 §3.1,一个 SCT 携带一个版本、一个日志标识符、一个时间戳,以及该日志对证书条目的签名。依据 RFC 6962 §3,一个日志返回一个 SCT,作为它将该证书纳入其仅追加日志的承诺,而依赖方会拒绝缺少有效 SCT 的证书。证书透明度 2.0 版保持相同模型:依据 RFC 9162 §3,一个日志在提交时返回一个 SCT,提交方在依赖它之前对其进行验证。
NextPDF Enterprise 把一份证书的 CT 姿态表示为一个结果值,携带:
- 该证书是否包含 SCT 扩展;
- 找到的 SCT 总数;
- 签名有效的 SCT 数量;
- 签发这些 SCT 的日志的日志标识符——SHA-256 哈希。
该结果暴露一项最小 SCT 阈值检查:它报告有效 SCT 的数量是否达到或超过所要求的最小值。你设定该最小值以匹配你的策略。一种常见策略对于较短有效期的证书期望至少有来自不同日志的两个 SCT,对较长有效期的证书则期望更多;阈值的取值由你选择。
把该阈值检查用作签名工作流程中的一道门:在签名之前要求一份记入 CT 的证书(有效 SCT 数量足够),否则拒绝。
为何如此设计
标题为“为何如此设计”的章节证书透明度回答一个狭窄的问题:这份证书是否被公开记录,以及被多少个独立日志记录。NextPDF Enterprise 把该答案建模为一个朴素的结果值,而非一个裁决。该结果报告 SCT 扩展标志、SCT 数量与签发日志标识符,然后就此止步。它不决定该姿态是否足够好,因为信任阈值是一项依赖方策略,会随证书有效期与风险而变化。因此最小 SCT 数量的设定权仍归你所有,而 NextPDF 保持置身于日志运营方、审计方与监控方的角色之外。证书透明度只是一个稳妥签名决策中若干项检查之一,而本页把它设为在构造签名器之前的一道显式门。
设计背景:正确验证一份签名。
前提条件
标题为“前提条件”的章节- 安装 NextPDF Core 与 Enterprise 包,并持有一份有效的 Enterprise 授权。
- 持有你想要强制其 CT 姿态的签名证书,连同你的环境从中提取的 SCT 数据。
- 决定你的策略所要求的最小 SCT 阈值。
- 最小 SCT 阈值 —— 一份证书为通过你的策略而必须携带的有效 SCT 数量。把它传给阈值检查。
- 策略放置 —— 决定该门在你的签名工作流程中的何处运行:在构造签名器之前,使一份记入不足的证书绝不会到达签名操作。
分步操作
标题为“分步操作”的章节- 取得你的签名证书的 CT 结果,其携带 SCT 扩展标志、总 SCT 与有效 SCT 数量,以及日志标识符。
- 决定你的策略的最小 SCT 阈值。
- 运行阈值检查;把通过视为“CT 策略已满足”,把未通过视为“拒绝用此证书签名”。
- 在签名器被构造之前,让签名工作流程以该结果为门。
<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Enterprise\Security\CertificateTransparency\CtValidationResult;use Psr\Log\LoggerInterface;
final readonly class CtSigningPolicy{ /** * @param int<1, max> $minimumScts The minimum count of valid SCTs your policy requires. */ public function __construct( private int $minimumScts, private LoggerInterface $logger, ) {}
/** * Decide whether a certificate's CT posture satisfies the policy. * * The gate runs before the signer is constructed, so an under-logged * certificate never reaches a signing operation. A missing SCT extension * is treated as a policy failure, not an exception. * * @param CtValidationResult $result The CT posture of the signing certificate. * * @return bool True when the certificate meets the minimum-SCT threshold. */ public function isAcceptable(CtValidationResult $result): bool { if (! $result->hasSctsExtension) { $this->logger->warning('Signing certificate carries no SCT extension; CT policy not met.');
return false; }
$acceptable = $result->meetsPolicy($this->minimumScts);
if (! $acceptable) { $this->logger->warning('Signing certificate has too few valid SCTs for the CT policy.', [ 'validScts' => $result->validScts, 'minimumScts' => $this->minimumScts, ]); }
return $acceptable; }}- 构建一个 SCT 扩展存在、有效 SCT 数量正好处于你阈值的结果,并确认阈值检查通过。
- 构建一个比你阈值低一的结果,并确认该检查未通过。
- 构建一个 SCT 扩展缺失的结果,并确认无论数量如何该门都拒绝。
- 确认当该门拒绝时,你的签名工作流程不会构造签名器。
安全与合规
标题为“安全与合规”的章节- NextPDF 进行表示与阈值检查;它不运营日志。 NextPDF Enterprise 呈现 CT 姿态与一项最小 SCT 检查。它不是一个 CT 日志、审计方,也不是监控方,且它不向日志提交证书。
- 阈值是你的策略。 最小 SCT 值由你设定;NextPDF 不强加一个数字。SCT 扩展缺失是一个明确的策略未通过。
- 在你签名之前设门。 在构造签名器之前运行该检查,使一份记入不足的证书绝不会到达签名操作。
- SCT 语义遵循标准。 一个 SCT 是一个日志的承诺,依赖方期望它存在且有效(RFC 6962 §3;§3.1 结构;CT v2 RFC 9162 §3)。
本页涉及证书信任。每一项规范性来源都以转述方式呈现;不复现任何规范性原文。
失败处理
标题为“失败处理”的章节- 没有 SCT 扩展。 把一个没有 SCT 扩展的结果当作策略未通过;拒绝签名。
- 有效 SCT 太少。 有效 SCT 数量低于你的阈值会使该检查未通过;拒绝签名。
- 策略放置。 在签名器被构造之前运行该门;一个在签名之后才运行的迟到检查无法保护已生成的文档。
发布边界
标题为“发布边界”的章节本页仅记录外部可观察的行为与受支持的公共 API 接口。内部命名空间路径、辅助类、机制表、运行手册文件名与工单前缀均不在范围之内。
另请参阅
标题为“另请参阅”的章节- Security — NextPDF Enterprise —— 组合后的 Enterprise 安全接口。
- Signature — NextPDF Enterprise —— PAdES B-LT 与 B-LTA 长期生产者。
- HSM signing — NextPDF Enterprise —— PKCS#11 硬件密钥保管。
- Security / Signing (Core) —— Core CMS 签名器与签名策略契约。
- Certificate Transparency · SCT —— 术语表条目。