OCSP 在线证书状态协议：它是什么，如何保障签名安全

在线证书状态协议（Online Certificate Status Protocol，OCSP）是一种互联网协议，让客户端向证书签发机构查询某份数字证书当前是否仍然有效或已被吊销，并收到一份经过签名的实时答复——无需下载整份吊销列表。实际应用中，当你打开一份已签名的 PDF 或访问 TLS 加密站点时，OCSP 就是决定该签名所依托的证书此刻能否被信任的检查项之一。本指南介绍 OCSP 的工作原理、与证书吊销列表的对比、对数字签名和电子签名的意义，以及它在哪些局限下需要配套的补充机制。

什么是在线证书状态协议？

OCSP 由 RFC 2560 正式确立（后经 RFC 6960 更新），作为证书吊销列表（CRL）更轻量、更快速的替代方案。客户端不必下载一份可能很庞大的、包含 CA 签发过的所有已吊销证书的列表，OCSP 允许客户端只问一个针对性问题："你们 CA 签发的序列号为 X 的证书还有效吗？"CA 的响应服务器——即 OCSP 响应服务器——返回一份签名答复，表明"良好""已吊销"或"未知"。

可能的响应状态有三种：

良好（Good）。 证书未被吊销。这并不保证证书在各方面都有效，只代表 CA 尚未吊销它。
已吊销（Revoked）。 CA 在证书到期前将其吊销，通常是因为密钥泄露、CA 出错，或证书持有人的状态发生变化。
未知（Unknown）。 响应服务器没有该证书的信息，常见于响应服务器不覆盖签发该证书的 CA。

由于响应由 CA 或其授权的响应服务器加密签名，客户端可以验证其真实性。若想更全面地了解签发与管理这些证书的机构，我们的证书颁发机构列表说明了 CA 在浏览器和电子签名信任链中扮演的角色。

OCSP 工作原理：证书验证流程

OCSP 交换是 HTTP（或 HTTPS）上简单的请求-响应过程，流程通常如下：

客户端收到一份证书。 可能是浏览器连接中的 TLS 服务器证书，也可能是已签名 PDF 中嵌入的签名证书。
客户端提取证书的序列号和 OCSP 响应服务器地址。 该地址发布在证书自身的一个字段中，即权限信息访问（AIA）扩展。
客户端发送 OCSP 请求。 请求包含证书的序列号和签发者名称，为提高效率通常经过哈希处理。
OCSP 响应服务器检查数据库，返回带有效状态和新鲜度时间戳的签名响应。
客户端验证响应签名，确认其对应正确的证书，并核实响应足够新、可以信任。

对于浏览器 TLS 连接，这一往返只需毫秒级时间，但同样的机制也支撑着文档工作流中的签名验证。如果你想了解产生这些供 OCSP 检查的证书的完整签署流程，我们的数字签名在业务工作流中的运作方式指南从密钥生成到验证全程讲解。

OCSP 与证书吊销列表的对比

CRL 和 OCSP 解决的是同一问题——告知信赖方某份证书不应再被信任——但方式不同。两者没有绝对的优劣之分，选择取决于数据量、对延迟的容忍度以及离线需求。

维度	CRL	OCSP
机制	CA 发布已吊销证书列表	客户端逐张证书向响应服务器查询
数据量	可能很大（上千条记录）	小，单证书响应
新鲜度	按计划更新（数小时或数天）	近乎实时
网络开销	下载一次后缓存	每次验证一次请求
离线使用	下载后即可用	需要联网（除非使用 stapling）
最适用于	低频、离线、批量检查	实时、按连接检查

在现代网页与文档签名基础设施中，OCSP 是交互式检查的默认选择，而 CRL 在响应服务器不可达时充当后备。许多客户端两者都实现，哪个先到就用哪个。

OCSP 对数字签名与电子签名的意义

当你用数字证书签署文件时，签名的法律与技术价值取决于证书在签署时是否有效——以及日后有人验证该文件时证书是否仍然有效。OCSP 正是回答这两个问题的机制。

设想一张签发给了某企业的签名证书。如果该企业的私钥泄露，CA 会吊销证书。没有 OCSP，任何在吊销之后验证用该证书签署的文件的人，都无法得知证书已不可信。有了 OCSP，验证者能立刻得到经过签名的答复。

这在受监管的签署场景中尤为重要——eIDAS 框架下的合格电子签名、印度的数字签名证书等——签署证书的可信是法律可执行性的前提。我们的 DSC 代表什么指南说明了数字签名证书如何融入这些工作流；而针对这一切背后的安全问题——电子签名安全吗——OCSP 是结构性答案之一：它提供吊销检查，让信任链在签发之后保持可信。

OCSP 的局限与需留意之处

OCSP 很有效，但不是万灵药。有四个局限值得关注：

延迟与可用性。 如果 OCSP 响应服务器缓慢或不可达，客户端必须决定是"开放失败"（接受证书）还是"关闭失败"（拒绝证书）。浏览器历史上采用"开放失败"以避免破坏站点，这会削弱保护。
隐私。 普通的 OCSP 请求会直接发给 CA，因此 CA 能知道用户在检查哪个站点或证书。OCSP stapling——服务器在 TLS 握手时附带预先获取的 OCSP 响应——通过省去客户端到 CA 的往返来缓解这一问题。
新鲜度窗口。 缓存的 OCSP 响应只在有限时间内有效。如果证书在缓存刷新之间被吊销，依赖过期响应的客户端可能接受一份已吊销的证书。
"未知"响应。 如果响应服务器返回"未知"，客户端得不到确切答案，只能回退到 CRL 或直接拒绝证书。

对构建签署工作流的团队而言，这些局限意味着 OCSP 应是纵深防御中的一层，而非唯一检查。把它与防篡改检测——参见我们的如何识别伪造或篡改的数字签名指南——以及 AES-256 加密标准指南中覆盖的强加密实践配合使用，你就能获得更完整的安全态势。

证书状态检查清单

在评估某个签署平台或文档工作流是否正确处理证书吊销时，用这份清单确认覆盖情况：

[ ] 平台将签名证书的证书链验证回受信任的根 CA。
[ ] 吊销通过 OCSP 检查，响应服务器不可达时以 CRL 作为后备。
[ ] 签署平台在签署时把 OCSP 响应（或带时间戳的吊销状态）记录进审计轨迹。
[ ] 长期验证（LTV）嵌入验证数据，使签名在多年后仍可验证，即使 CA 或响应服务器已下线。
[ ] OCSP 响应检查新鲜度——不超过平台设定的最大时限。
[ ] OCSP 检查失败触发既定策略：高价值交易采取"关闭失败"，低风险工作流采取"开放失败"并记录日志。

能逐项满足的平台，能给你证据证明签名在签署时有效、事后仍可验证——这正是审计师和法院所看重的。

Nota Sign 让每份签名都带有证书级信任

证书吊销检查不是抽象问题——它决定了签名能否被强制执行，还是无法自证。Nota Sign，法大大旗下的全球电子签名平台，把这种信任建进签署管线：每份签名都依托可验证的证书链，审计记录捕获信赖方需要的证据，签名在 100 多个国家和地区产生法律效力。

在 IDC 中国电子签名软件市场历届年度报告中排名第一的 Nota Sign，把亚太合规做成了出厂配置，而不是留给客户自行拼装：香港 iAM Smart 和新加坡 Singpass 身份核验、SES 到 AES 到 QES 的签名等级、对接数据驻留预期的区域数据中心。定价是另一个惊喜——不按席位收费，同样的证书级签署严谨度小团队用得起，中端市场和大型企业客户可选择定制方案。如果你需要经受得住吊销审查的签名，联系 Nota Sign，看看在你所在司法辖区的落地流程。