CA 系统架构与日志产生位置
做 CA 运维这些年，我最深刻的体会就是——日志在哪，答案就在哪。你想想看，一个证书签发出问题了，用户说「我提交了 CSR 但拿不到证书」，你第一反应肯定是去查签发服务的日志。但签发服务的日志在哪？它在整个 CA 架构里处于什么位置？这要是搞不清楚，排查起来就像没头苍蝇。
这一节，咱们就把 CA 的四大核心组件——签发服务（CA 服务器）、OCSP 响应器、CRL 发布点和RA 注册机构——的日志产生点彻底捋一遍。我会告诉你每个组件在什么时机写日志、写什么内容、日志通常存在哪里。
CA 整体架构图：日志从哪里来？
先看一张总图。这张图里每个方块都是一个会产生日志的组件，箭头代表日志流向或业务流转方向。我个人习惯把这张图贴在工位旁边，每次排错先对着它定位位置。
1. CA 签发服务 — 日志最密集的地方
签发服务是 CA 的心脏。所有证书的生命周期操作都要经过它。我记得有一次某客户的证书批量申请失败，查了两天发现是签发服务的日志轮转把旧日志覆盖了，关键错误信息被冲掉了。从那以后，我对签发服务的日志采集格外敏感。
日志产生点主要有这些：
- 接收 CSR 时：记录请求来源 IP、CSR 指纹、公钥算法、请求 DN。
- 身份验证时：记录验证方式（密码 / 证书 / 令牌）、验证结果。
- 密钥对生成时：如果由 CA 生成密钥对，会记录密钥类型、长度、存储标识。
- 证书签发时：记录序列号、主题、签发者、有效期、扩展项（SAN、EKU）。
- 证书续签时：记录原证书序列号、续签原因、新旧指纹对比。
- 证书吊销时：记录吊销原因、吊销时间、操作管理员。
我的个人经验：签发服务的日志字段一定要包含 request_id 或 transaction_id。没有这个 ID，你根本没法把 CSR 请求和签发的证书关联起来。我曾经在一个金融客户现场，就因为日志里没有关联字段，排查一个「证书已签发但客户端拿不到」的问题花了整整一个下午。
典型的签发日志条目（参考格式）：
2025-03-15 14:23:18.456 [CA-SIGN] INFO cert_issue::handler -
RequestID=REQ-2025-0315001,
CSR_Fingerprint=sha256$A1B2C3...,
Subject="CN=api.example.com,OU=IT,O=ACME",
Serial=0x1A2B3C4D5E,
Status=ISSUED,
Validity=2025-03-15/2026-03-15,
Duration=4ms2. OCSP 响应器 — 在线状态查询日志
OCSP 的作用是让客户端实时查询证书是否被吊销。日志相对简单，但并发量可能巨大——尤其是在高流量场景下。
关键日志点：
- 收到 OCSP 请求（记录来源 IP、请求证书序列号、哈希算法）。
- 查询本地状态数据库（记录命中/未命中、数据库响应时间）。
- 返回 OCSP 响应（记录响应状态：good / revoked / unknown、签名算法）。
- 签名失败或数据库异常（记录具体错误码）。
避坑指南：OCSP 日志很容易因为请求量太大而撑爆磁盘。我曾经在部署时没有限流，结果 OCSP 的日志文件一天涨了 20GB，最后把系统盘写满了。建议你一定要给 OCSP 日志单独分区，并设置合理的轮转策略（比如按小时滚动）。
2025-03-15 14:25:01.123 [OCSP] INFO ocsp_handler::process -
ClientIP=192.168.1.100,
Serial=0x1A2B3C4D5E,
HashAlgo=SHA256,
Status=REVOKED,
RevocationTime=2025-03-10T08:00:00Z,
ResponseTime=3ms3. CRL 发布点 — 定期更新日志
CRL（证书吊销列表）是 CA 定期生成的一份被吊销证书的清单。它的日志产生频率比 OCSP 低得多，但每次发布的数据量很大。
日志产生点：
- CRL 生成触发：记录触发方式（定时 / 手动 / 吊销事件触发）。
- CRL 数据组装：记录本次包含的吊销证书数量、下次更新时间。
- CRL 签名：记录使用的签名证书标识、签名算法。
- CRL 发布：记录发布目标路径（文件系统 / HTTP / LDAP）、文件大小。
- CRL 分发点访问：记录下载请求来源、请求的文件名、请求结果（成功/失败）。
有个细节：很多人只关注 CRL 是否生成成功，却忘了检查 CRL 的「下一次更新」时间是否合理。如果这个时间被错误地设置到了过去，所有客户端都会认为 CRL 已过期而拒绝信任证书——我在项目里帮客户排查过这种「一朝回到解放前」的惨案。
4. RA 注册机构 — 前端业务的日志枢纽
RA 通常部署在企业内部，负责审核用户身份并转发 CSR 给 CA。日志偏向业务操作和审计。
主要日志点：
| 事件类型 | 日志内容 | 典型字段 |
|---|---|---|
| 注册请求 | 用户提交证书申请，包含个人信息、组织信息 | UserID, Email, Dept, RequestTime |
| 身份验证 | 验证用户身份（如 AD 登录、短信验证码） | AuthMethod, AuthResult, AuthProvider |
| 审核操作 | 管理员批准/拒绝证书申请 | Operator, Action, Reason, ApprovalTime |
| 流程状态变更 | 申请流程在各环节流转 | FromStatus, ToStatus, Duration |
2025-03-15 14:30:55.789 [RA-AUDIT] INFO ra_workflow::approve -
RequestID=REQ-2025-0315001,
Operator=zhangsan@corp.com,
Action=APPROVED,
SubjectDN="CN=api.example.com",
PreviousStatus=PENDING,
CurrentStatus=APPROVED,
Comment="业务需要，审核通过"RA 日志还有一个重要作用——审计合规。金融、政务场景下，RA 的审核日志必须保留至少 5 年，并且做到不可篡改。我见过很多厂商直接在 RA 日志上叠加区块链哈希链，就是为了满足监管要求。
各组件日志特点对比
| 组件 | 日志量级 | 关键关注点 | 常见存储路径 |
|---|---|---|---|
| CA 签发服务 | 中等（每分钟数百～数千条） | 序列号唯一性、签名耗时、异常码 | /var/log/ca/sign/*.log |
| OCSP 响应器 | 高（可能每秒上万条） | 响应时间、状态命中率、错误率 | /var/log/ca/ocsp/*.log |
| CRL 发布点 | 低（每天几次到几十次） | 发布完整性、下次更新时间、分发点可达性 | /var/log/ca/crl/*.log |
| RA 注册机构 | 低～中等（与业务申请量成正比） | 审计追溯、流程时间线、操作合规 | /var/log/ca/ra/*.log |
日志采集前你要想清楚的事
嗯，这里我要多啰嗦两句。很多新手一上来就想着「我要把所有日志都采集到 ELK 里」，结果被 OCSP 的日志洪水冲垮了 Kafka 集群。
- 分优先级：CA 签发日志必须实时采集（<1s 延迟），OCSP 可以延迟 1-2 分钟聚合上传，CRL 和 RA 日志可以按小时批量同步。
- 注意时间同步：所有组件的系统时间必须 NTP 对齐。我遇到过一台 CA 服务器时间慢了 3 分钟，导致 OCSP 响应里显示的状态时间戳和实际吊销时间错位，客户投诉「证书被吊销了 OCSP 还说 good」。
- 日志格式统一：尽量采用 JSON 或结构化文本，字段名保持一致。最好在日志配置里就写好模板，不要靠后处理去猜字段。