4. 证书导入与信任链：导入根证书、中间证书、服务器证书，验证链完整性

在生产环境中，服务器证书（叶证书）很少由根证书直接签发，而是通过一个或多个中间证书（Intermediate CA）完成签发。客户端（如浏览器、Java 应用、curl）验证服务器证书时，必须补全整条信任链，否则会报 PKIX path building failed 或 unable to find valid certification path to requested target。本章以标准化流程解决“如何正确导入三级证书并验证链完整性”这一核心问题。

4.1 适用场景

• 私有 PKI 环境：企业内部 CA 签发的证书，客户端缺省不信任自建根证书，需手动导入。
• 多级中间 CA 架构：大型组织使用两级或三级中间证书，部署时需补全完整链。
• Java/Spring Boot 应用：通过 keytool -importcert 或 trustStore 配置信任链。
• 反向代理 / WAF：Nginx、Apache、HAProxy 等需配置链证书（chain.pem）才能通过移动端/浏览器校验。
• 容器与微服务：Docker、K8s 的 mTLS 场景，每个 Pod 信任库必须包含完整的 CA 链。

4.2 前置条件

4.3 操作步骤

Step 1 — 获取并校验证书文件

1. 从 CA 管理员或安全渠道获取三份证书文件：ca.pem、intermediate.pem、server.pem。
2. 使用 openssl x509 查看每份证书的指纹、签发者与主题，确认文件未损坏或被篡改。

# 查看根证书详细信息
openssl x509 -in ca.pem -text -noout | head -20

# 提取并比对 SHA-256 指纹（与官方发布的指纹逐字符核对）
openssl x509 -in ca.pem -fingerprint -sha256 -noout

Step 2 — 验证证书层级从属关系

1. 检查服务器证书的签发者（Issuer）是否等于中间证书的主题（Subject）。
2. 检查中间证书的签发者（Issuer）是否等于根证书的主题（Subject）。
3. 根证书的签发者与主题相同（自签名）。

# 提取服务器证书的签发者
openssl x509 -in server.pem -issuer -noout

# 提取中间证书的主题
openssl x509 -in intermediate.pem -subject -noout

# 提取中间证书的签发者
openssl x509 -in intermediate.pem -issuer -noout

# 提取根证书的主题与签发者（应为同一值）
openssl x509 -in ca.pem -subject -issuer -noout

Step 3 — 按序导入信任库

根据目标平台选择导入方式。以下以 Java Keystore (JKS) 和 Linux 系统信任库 (PEM 格式) 为例。

方式 A：导入为 Java TrustStore (JKS)

# 1. 导入根证书（别名为 root-ca）
keytool -importcert -trustcacerts -alias root-ca \
  -file ca.pem -keystore truststore.jks -storepass changeit -noprompt

# 2. 导入中间证书（别名为 intermediate-ca）
keytool -importcert -trustcacerts -alias intermediate-ca \
  -file intermediate.pem -keystore truststore.jks -storepass changeit -noprompt

# 3. 导入服务器证书（别名为 server-cert）
keytool -importcert -trustcacerts -alias server-cert \
  -file server.pem -keystore truststore.jks -storepass changeit -noprompt

方式 B：导入 Linux 系统信任库 (PEM 格式)

# 1. 将三份证书合并为一个链文件（按根→中间→服务器顺序）
cat ca.pem intermediate.pem server.pem > fullchain.pem

# 2. 复制到系统证书目录
sudo cp fullchain.pem /usr/local/share/ca-certificates/my-ca-chain.crt

# 3. 更新系统信任库
sudo update-ca-certificates

# 4. 验证是否已注册
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
  | openssl pkcs7 -print_certs -text -noout \
  | grep -A 2 "my-ca-chain"

Step 4 — 验证链完整性

1. 使用 openssl verify 检查完整链是否可达。
2. 使用 keytool -list -v 查看信任库中证书的链关系。
3. 通过 TLS 连接测试，确认服务器证书在握手时不被报错。

# 方式一：openssl 验证（需要显式指定中间证书和根证书）
openssl verify -CAfile ca.pem -untrusted intermediate.pem server.pem

# 预期输出：server.pem: OK

# 方式二：通过 s_client 测试实际 TLS 握手
openssl s_client -connect your-server.com:443 -CAfile truststore.jks \
  -showcerts 2>/dev/null | grep "Verify return code"

# 预期输出：Verify return code: 0 (ok)

4.4 输入输出物

4.5 责任边界

• CA 管理员：提供根证书和中间证书的官方文件与指纹摘要，确保证书在有效期内且未被吊销。
• 应用运维 / 平台工程师：按照 SOP 执行导入操作，完成验证并记录日志；不得跳过指纹比对步骤。
• 安全审计员：抽查信任库中是否存在过期、自签发或非授权证书；审核记录材料的完整性。
• 开发人员：确认应用代码中引用的 trustStore 路径、密码与运维实际配置一致。

4.6 记录材料

每次导入操作后，必须在变更记录中留存以下信息：

1. 证书清单：根证书、中间证书、服务器证书的序列号、SHA-256 指纹、有效期起止。
2. 操作日志：执行命令的完整输出，包含 openssl verify 返回的 OK 状态。
3. 变更单号：关联 ITSM/ITIL 变更请求编号，注明操作人、操作时间、目标环境（测试/预发/生产）。
4. 回滚方案：备份旧 truststore 的路径与校验和，应急回退步骤。

# 记录模板（建议以 Markdown 或 Confluence 页面保存）
---
变更时间：2025-04-11 14:30 UTC+8
操作人：张三
环境：生产
证书链：
  - Root CA   : serial=12345678, fingerprint=SHA256:abcd...
  - Interm CA : serial=9ABCDEF0, fingerprint=SHA256:ef01...
  - Server    : serial=11223344, fingerprint=SHA256:2345...
验证结果：openssl verify — 返回 OK
回滚文件：/backup/truststore.jks.20250411.bak
---

4.7 异常处理

4.8 验收标准

1. 链完整性校验通过：openssl verify -CAfile ca.pem -untrusted intermediate.pem server.pem 返回 server.pem: OK。
2. 信任库列表可查：keytool -list -v -keystore truststore.jks 中三条证书均存在，且 Certificate chain length 正确显示为 3。
3. TLS 握手正常：openssl s_client -connect host:port 的 Verify return code 为 0 (ok)。
4. 无过期证书：所有证书的 notAfter 日期 > 当前时间 + 30 天（满足运维缓冲期）。
5. 文档归档完整：记录材料中已包含指纹、序列号、操作日志与回滚备份路径。