📚 课程目录第3章日志缺失的常见场景

3. 日志缺失的常见场景

日志缺失这事，说起来好像不是什么惊天动地的大问题。但你在生产环境里待几年就知道了——它往往是一连串故障的起点。今天我就把这四个最常见的场景掰开来讲讲。

说白了，日志一旦断了，你就等于闭着眼睛在修 PKI。下面这张图帮你快速建立全局印象。

3.1 证书颁发失败，日志查不到原因

这是最常见的场景，没有之一。我在好几个客户的现场都遇到过：突然有人报“证书申请失败”，CA 控制台上显示个错误码，但具体为什么失败——不知道。翻日志文件，发现关键的发证日志根本就没写进去。

你想想看，证书颁发失败可能有一百种原因：策略约束没通过、密钥长度不合规、申请者 DN 重复、CRL 分发点配置错误……没有日志，你就只能靠猜。我记得有一次，一个客户折腾了整整两天，最后发现是 CA 的数据库满事务日志把审计记录给截断了。要是早期有日志，半小时就能定位。

  核心观点： 证书颁发日志是 PKI 的“黑匣子”。缺少它，排障成本至少增加 5 倍以上。

我个人习惯在 CA 上线第一天就做一次“失败颁发测试”——故意提交一个不合规的请求，然后检查日志里是否完整记录了：

请求时间、申请人身份
失败的具体策略规则编号
CA 本身是否做过重试

如果这些内容缺失，那你得赶紧调日志级别或修复日志写入链路。

3.2 OCSP 查询无响应，日志一片空白

OCSP 的问题往往比 CRL 更难缠。CRL 大不了手动下载一份看看，OCSP 是实时查询，客户端拿到“无响应”就直接判定证书无效。很多管理员第一反应是去 OCSP Responder 上查日志，结果发现——空的。

为什么会这样？我在项目里踩过这个坑：OCSP 日志默认只记录成功的响应，失败的连接甚至不被写进去。嗯，这里要注意，OCSP 是无状态的 HTTP 协议，客户端发请求过来，Responder 处理完就丢，如果日志没开 debug 级别，连接断开的详细原因根本不会落盘。

我给你一个实用的排查清单：

排查点	日志缺失的表现	可能的原因
OCSP 请求到达数	0 条日志	防火墙拦截、负载均衡未转发
OCSP 签名证书状态	只有成功日志	签名证书过期前未告警
OCSP 响应时间	无超时日志	数据库连接池满，请求被丢弃

我曾经帮一个金融客户排查 OCSP 间歇性无响应的问题。他们开了全日志以后才发现，是后台的 CA 数据库在做全量备份时把 OCSP 的连接池给饿死了。日志里只有一行 “Connection timeout” 的 debug 信息，但之前由于日志级别设成 info，根本看不到。

小经验： OCSP Responder 的日志级别至少调到 info+，并且单独配置一个日志文件。不要和 CA 主日志混在一起，否则你查起来会想哭。

3.3 CRL 未更新，审计时发现日志断档

CRL 的更新是个“看起来简单，做起来到处是坑”的活。按理说 CA 自动发布 CRL，分发点同步一下，完事。但实际环境里，CRL 发布时间、序列号、签名哈希算法改动、分发点服务器故障……哪一环都可能出问题。

最抓狂的是：你觉得自己明明配好了每天凌晨 1 点发布 CRL，结果季度审计时发现中间有一个月 CRL 根本没更新。审计员一看日志——那段时间的发布日志是空的。你说这是没发布呢，还是发布了但日志没写？

我个人建议在 CRL 发布配置中，强制开启“发布失败告警”和“发布成功日志”。很多 CA 产品默认只记录成功发布，失败时什么都不写。我参与过的一个政府项目，就因为 CRL 发布脚本里的磁盘路径写错了，整整 45 天 CRL 没更新，而管理员一直以为正常运行——因为日志里根本没有错误记录。

# 一个典型的不良配置（默认日志）
# 没有针对失败发布的日志输出
CRL_Publishing:
  schedule: "0 1 * * *"
  outputDir: "/var/crl/"
  # 缺少 failureLog: true

# 正确的做法
CRL_Publishing:
  schedule: "0 1 * * *"
  outputDir: "/var/crl/"
  successLog: "/var/log/crl_publish_success.log"
  failureLog: "/var/log/crl_publish_failure.log"
  alertOnFailure: true

特别提醒： CRL 的日志不仅是技术排查工具，更是合规证据。很多行业标准要求 CRL 的完整“发布链”日志保留 3 年以上。缺失哪怕一次，都可能被判定为不合规。

3.4 合规审计要求不满足，日志就是铁证

上面三个场景是技术层面，第四个场景是管理层面的。但往往技术缺失直接导致管理违规。

你去看看国内的等保 2.0、金融行业的《电子认证业务规则》、或者是 PCI-DSS，里面关于日志的要求写得清清楚楚：

PKI 系统中的所有证书生命周期操作必须有审计日志
日志必须防篡改（至少是只追加），保留时间一般不低于 180 天
关键操作（CA 签名、私钥访问、管理员操作）必须记录用户、时间、操作内容、结果

如果日志缺失，审计师会直接开一个“严重不符合项”。我遇到过最夸张的一次，客户被开出的整改项清单里，有一半都跟日志不全有关。比如：CA 管理员的登录日志只保留了一周，但要求是半年；OCSP 的响应日志从来不记录请求者的 IP，无法做访问分析。

说白了，合规审计时，日志就是你的“不在场证明”。你做得再好，没有日志证明，就等于没做。

  一个建议： 不光要保证日志“有”，还要保证日志“能用”。我曾经见到某个客户把 PKI 日志全部往 Syslog 里推，结果 Syslog 服务器磁盘满了，之后一个月的日志全部丢失——然而管理员完全不知道。所以，备一份日志的完整性检查脚本非常有必要。

最后我总结一下这四个场景的共性原因。你仔细看，其实无非两件事：日志级别配太低（该记的没记），或者日志落盘过程有故障（记了但没写进去）。对症下药并不复杂，但前提是你得先知道自己“没看到日志”这个事实本身就是一个严重的告警信号。