📚 课程目录第4章证书生命周期管理

4. 证书生命周期管理：签发、有效期、CRL 与 OCSP

在 Kong 网关的 TLS 运维中，证书并非一次性配置即可高枕无忧。证书从签发、部署、监控到最终吊销或续期，构成一个完整的生命周期。任何环节的疏漏都可能导致 TLS 握手失败、客户端报错甚至安全漏洞。本章聚焦证书生命周期的四个核心环节：签发、有效期监控、吊销列表（CRL）与在线证书状态协议（OCSP），并结合 Kong 网关的运维场景给出实战建议。

4.1 证书签发与信任链

证书签发是生命周期的起点。Kong 网关作为服务端，通常使用由受信任的证书颁发机构（CA）签发的证书，或内部 PKI 体系签发的证书。签发过程决定了证书的信任链结构。

签发类型	适用场景	信任链长度	Kong 配置要点
公共 CA（如 Let's Encrypt）	面向公网的服务	2~3 级（根CA → 中间CA → 服务器证书）	需配置完整证书链（含中间证书）
企业内部 CA	微服务间通信、内部 API	2~4 级（根CA → 策略CA → 中间CA → 服务器证书）	客户端需信任企业根证书
自签名证书	开发测试环境	1 级（仅服务器证书）	需在客户端手动导入信任

实战建议：Kong 的 certificates 实体支持配置 cert（服务器证书）与 key（私钥）。若使用中间 CA，务必在 cert 字段中将服务器证书与中间证书拼接，顺序为：服务器证书在前，中间证书在后。否则部分客户端（如 Java 应用）可能因信任链不完整而拒绝连接。

4.2 有效期监控与续期策略

证书有效期是生命周期中最直观的指标。现代 CA 签发的证书有效期已从 3 年缩短至 1 年甚至 90 天（如 Let's Encrypt）。Kong 网关运维团队必须建立有效期监控机制，避免因证书过期导致服务中断。

4.2.1 有效期监控指标

剩余天数：建议在证书到期前 30 天、14 天、7 天、1 天分级告警。
证书指纹变化：检测证书是否被意外替换或篡改。
OCSP 响应状态：确认证书未被吊销。

4.2.2 Kong 中的证书更新流程

使用新证书和私钥创建新的 certificates 实体（或更新现有实体）。
通过 Admin API 执行 POST /certificates 或 PATCH /certificates/{id}。
Kong 会自动将新证书加载到内存，并应用于关联的 snis（服务器名称指示）。
验证新证书是否生效：openssl s_client -connect kong.example.com:443 -servername kong.example.com。
观察 Kong 日志与监控指标，确认无握手错误。

  关键指标：Kong 的 latencies 指标中，request_latency 在证书更新后不应出现明显抖动。若发现 TLS 握手耗时增加超过 20%，需检查证书链完整性或 OCSP 响应延迟。

4.3 吊销列表（CRL）

证书吊销列表（CRL）是 CA 发布的已吊销证书序列号清单。Kong 网关在 TLS 握手时，可以通过 CRL 验证客户端证书是否已被吊销。虽然 Kong 原生不直接解析 CRL 文件，但可以通过 Nginx 配置或自定义插件实现。

4.3.1 CRL 工作原理

CA 定期发布 CRL 文件（通常为 DER 或 PEM 格式）。
CRL 包含：CA 签名、发布时间、下次更新时间、已吊销证书序列号列表。
验证方需下载并缓存 CRL，在握手时比对客户端证书序列号。

4.3.2 Kong 集成 CRL 的两种方式

方式	实现路径	优点	缺点
Nginx 原生配置	在 Kong 的 `nginx.conf` 中添加 `ssl_crl` 指令	性能高，无需额外插件	CRL 文件需手动更新，不支持动态加载
自定义插件	开发 Lua 插件，通过 `ngx.ssl` 模块在握手阶段校验 CRL	支持动态 CRL 更新、可集成告警	开发成本较高，需处理缓存与并发

注意：CRL 的实时性较差。CA 通常每 24 小时更新一次 CRL，若证书在两次 CRL 发布之间被吊销，客户端将无法及时感知。对于高安全场景，建议优先使用 OCSP。

4.4 在线证书状态协议（OCSP）

OCSP 解决了 CRL 实时性不足的问题。客户端在 TLS 握手时，直接向 CA 的 OCSP 响应器查询证书状态，获得“良好”、“吊销”或“未知”的实时响应。

4.4.1 OCSP 工作流程

客户端（或服务端）构造 OCSP 请求，包含目标证书的序列号和颁发者信息。
将请求发送至 CA 的 OCSP 响应器 URL（通常从证书的 Authority Information Access 扩展中获取）。
OCSP 响应器返回签名响应，包含证书状态与下次更新时间。
验证方解析响应，决定是否继续握手。

4.4.2 OCSP Stapling（OCSP 装订）

在 Kong 网关中，更推荐使用 OCSP Stapling 技术。由服务端（Kong）定期从 CA 获取 OCSP 响应，并在 TLS 握手时“装订”到 Certificate 消息中，客户端无需再主动查询 OCSP 响应器。

对比项	传统 OCSP	OCSP Stapling
查询发起方	客户端	服务端（Kong）
握手延迟	增加 1 次 HTTP 查询延迟	无额外延迟（响应已缓存）
隐私保护	CA 可追踪客户端访问的域名	CA 无法获知客户端信息
Kong 支持	需自定义插件	通过 Nginx 配置 `ssl_stapling` 开启

Kong 配置示例：在 Kong 的 nginx.conf 或 kong.conf 的 nginx_http_* 配置段中启用 OCSP Stapling：

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

注意：ssl_trusted_certificate 必须包含完整的 CA 证书链，否则 OCSP 响应验证会失败。

4.5 证书生命周期管理架构图

下图展示了从证书签发、部署、监控到吊销/续期的完整生命周期，以及 CRL 与 OCSP 在其中的位置。

4.6 实战：Kong 中配置 OCSP Stapling

以下是在 Kong 网关中启用 OCSP Stapling 的完整步骤，适用于 Kong 2.x 及 3.x 版本。

4.6.1 修改 Kong 配置

编辑 kong.conf 或通过环境变量设置：

# 启用 OCSP Stapling
nginx_http_ssl_stapling = on
nginx_http_ssl_stapling_verify = on
nginx_http_ssl_trusted_certificate = /etc/ssl/certs/ca-certificates.crt
nginx_http_resolver = 8.8.8.8 8.8.4.4 valid=300s
nginx_http_resolver_timeout = 5s

4.6.2 验证 OCSP Stapling 是否生效

使用 OpenSSL 客户端测试：

openssl s_client -connect kong.example.com:443 -servername kong.example.com -status

在输出中查找以下内容：

OCSP response: 行显示 OCSP Response Status: successful (0x0)。
OCSP Response Data: 下方包含证书状态为 good。
若显示 OCSP response: no response sent，说明 Stapling 未生效，需检查配置或网络连通性。

  性能收益：在生产环境中，启用 OCSP Stapling 后，TLS 握手时间平均降低 30%~50%（取决于客户端与 CA 响应器之间的网络延迟）。对于高并发网关，这是显著的性能优化。

4.7 证书生命周期管理清单

阶段	操作项	频率	负责人
签发	生成 CSR、提交 CA、下载证书与链	按需（续期时）	安全团队 / 运维
部署	上传证书到 Kong、配置 SNI 映射	每次签发后	运维
监控	检查剩余有效期、证书指纹、OCSP 状态	每日	监控平台
吊销检测	配置 CRL 或 OCSP Stapling	一次性配置 + 定期验证	运维
续期	重新签发、部署、验证	到期前 30 天启动	安全团队 / 运维

常见陷阱：

证书链不完整：只上传服务器证书，未包含中间证书，导致部分客户端握手失败。
OCSP 响应器不可达：Kong 无法连接 CA 的 OCSP 响应器时，Stapling 会降级为无响应，客户端可能回退到传统 OCSP 查询。
CRL 缓存过期：未设置 CRL 自动更新机制，导致使用过时的吊销列表。

通过系统化的证书生命周期管理，Kong 网关可以在保证安全性的同时，最大化 TLS 握手性能。下一环节将深入 TLS 1.3 协议特性与 Kong 的适配优化。