📚 课程目录第3章证书发现的核心挑战

3. 证书发现的核心挑战

证书发现之所以在企业里常常“做不干净”，并不是扫描工具不够多，而是证书这种资产天生具有隐蔽性、分散性和时效性。一台服务器上装了什么软件、开了什么端口、用了哪张证书，往往只有当初部署的人知道；而证书又会随着业务扩容、容器编排、CDN 接入、第三方 SaaS 集成不断扩散。要理解证书发现的设计难点，最有效的方式是把挑战拆成五类相互交织的问题：影子证书、过期证书、弱算法、多 CA 来源、分布式环境。它们不是并列的五个小问题，而是共同构成“发现不全、判断不准、治理不及时”的根因结构。

影子证书：发现盲区的最大来源

影子证书指那些不在任何台账中登记、却真实在用的证书。典型来源包括：开发人员为联调方便自签的证书、测试环境遗留下来被误挂到生产网关的证书、运维临时用 OpenSSL 生成后忘记清理的证书、以及第三方集成时对方提供的证书。它们的共同特征是“有人用、没人管”。

发现影子证书不能只靠“问”，要靠“扫”。一个可落地的做法是：对目标网段做 TLS 握手探测，采集对端返回的证书链，再与已知台账做差集。例如用如下命令批量探测某网段 443 端口：

# 对 10.20.30.0/24 网段做 TLS 证书采集（示例）
for ip in $(seq 1 254); do
  echo | timeout 3 openssl s_client \
    -connect 10.20.30.$ip:443 -servername app.example.com 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256 \
    && echo "HOST=10.20.30.$ip"
done

把输出中的 subject、issuer、notAfter、fingerprint 四个字段抽出来，与 CMDB 或证书台账比对，凡是指纹不在台账中的，就是疑似影子证书。注意：-servername 必须填真实访问域名，否则 SNI 不匹配会拿到默认证书，造成误判。

过期证书：不是“有没有”，而是“还剩多久”

过期证书的难点不在发现，而在提前量。企业证书动辄上千张，有效期从 90 天到 398 天不等。如果只在到期前 7 天才告警，遇到审批慢、变更窗口紧的情况必然出事。合理的做法是按剩余天数分档：剩余 > 60 天为正常，30～60 天为关注，7～30 天为预警，< 7 天为紧急。分档阈值应结合企业变更流程周期设定，而不是照搬。

更隐蔽的是“自动续期失败”。很多团队用了 ACME 自动续期就以为高枕无忧，但续期失败往往静默发生——DNS 验证记录被误删、HTTP-01 挑战路径被 WAF 拦截、账户密钥过期，都会导致续期失败而无人知晓。因此发现系统必须同时采集“证书实际到期时间”和“续期任务最近一次执行结果”，两者缺一不可。

弱算法：从“能用”到“合规”的判定

弱算法问题需要明确判定标准，否则无法自动化。常见判定维度包括：签名算法是否为 SHA-1、密钥长度是否低于 RSA-2048 或 ECC-256、是否使用了已被弃用的协议版本（如 TLS 1.0/1.1）、是否包含不安全扩展。以下是一段可用于批量判定的示例逻辑：

# 判定证书是否使用弱签名算法（示例）
openssl x509 -in cert.pem -noout -text \
  | grep -E "Signature Algorithm|Public-Key"

# 若输出包含 sha1WithRSAEncryption 或 Public-Key: (1024 bit)
# 则判定为弱算法，需纳入整改清单

判定结果应分为三档：不合规（SHA-1、RSA-1024）、待观察（RSA-2048 但协议为 TLS 1.0）、合规。分档的意义在于整改优先级不同，而不是简单打一个“弱”标签。

多 CA 来源：信任链与策略的分散

企业证书可能来自公有 CA（如 DigiCert、Let's Encrypt）、私有 CA（如内部 PKI）、以及自签名证书。多来源带来的核心问题是策略不统一：公有 CA 证书有标准吊销机制（CRL/OCSP），私有 CA 可能没有；自签证书根本没有吊销概念。发现系统需要记录每张证书的“来源类型”，并据此决定后续治理动作——公有 CA 证书重点看吊销状态和 CT 日志，私有 CA 证书重点看内部 CRL 分发点是否可达，自签证书则重点看是否应该被替换。

分布式环境：发现范围的边界问题

分布式环境让“扫哪些资产”本身成为难题。传统数据中心可以按网段扫，但容器环境中 Pod IP 频繁变化、CDN 和边缘节点不暴露源站、第三方 SaaS 的证书根本不在自己手里。可行的策略是分层发现：

已知资产层：从 CMDB、Kubernetes Ingress、负载均衡配置中直接读取证书引用，准确率高但覆盖不全。
主动扫描层：对已知网段和域名做 TLS 探测，覆盖未登记资产，但受限于网络可达性。
被动采集层：从 CT 日志（Certificate Transparency）中按企业域名反查已签发证书，能发现“已签发但未部署”的证书，是影子证书的重要补充来源。

三层结果合并去重后，才能形成相对完整的证书资产视图。需要强调的是，没有任何单一手段能覆盖全部证书，发现率是一个持续逼近的过程，而不是一次扫描就能达到 100%。

实践提示：证书发现的输出不应只是一张清单，而应包含“指纹、主体、签发者、有效期、算法、来源类型、发现方式、责任人”八个字段。其中“发现方式”用于追溯该证书是通过台账、扫描还是 CT 日志发现的，便于后续评估发现覆盖率。

常见误区：把“扫描到证书”等同于“发现完成”。实际上，扫描只能覆盖网络可达的 TLS 端点，对于未部署的证书、内嵌在应用配置文件中的证书、以及仅用于代码签名的证书，扫描完全无效。必须结合配置解析和 CT 日志才能补齐。

综合来看，这五类挑战的治理顺序应当是：先解决“看得见”（影子证书、分布式环境），再解决“判得准”（弱算法、多 CA 来源），最后解决“管得住”（过期证书的提前量与自动续期监控）。顺序颠倒会导致在资产不清的情况下盲目整改，既浪费人力又无法闭环。