Debian 10私有CA搭建实战：从根证书到UEFI签名

1. 为什么在 Debian 10 上亲手搭建 CA 不再是“可选项”，而是运维基本功

你有没有遇到过这样的场景：刚配好一套内部监控系统，浏览器却固执地弹出“您的连接不是私密连接”；给开发团队分发测试用的 HTTPS 服务证书时，每人得手动点击三次“继续前往不安全网站”；或者更糟——某天凌晨三点，生产环境的 API 网关突然拒绝所有 TLS 握手，日志里只有一行冰冷的 SSL_ERROR_BAD_CERT_DOMAIN 。排查两小时，发现只是因为自签名证书过期了三天，而没人记得它当初是怎么生成的。

这绝不是小题大做。在 Debian 10（代号 Buster）这个被大量企业选作长期稳定基线的操作系统上， 亲手搭建并管理一个私有 Certificate Authority（CA） ，早已不是实验室里的玩具项目，而是基础设施可信链的起点。它直接决定着你能否真正掌控服务间通信的加密边界、能否绕过浏览器对自签名证书的反复警告、能否为容器、IoT 设备、内部 CLI 工具甚至 Windows UEFI Secure Boot 的签名密钥提供合规可信的签发源头。

关键词里反复出现的 Einrichten （建立）和 Konfigurieren （配置），恰恰点出了核心：这不是一键安装某个包就完事的黑盒操作，而是一套需要你亲手定义策略、生成密钥、签署证书、分发信任锚点、并持续维护生命周期的完整流程。尤其当网络热词里混入 secure boot windows uefi ca 2023 updater 和 ca证书 时，说明这个能力已从 Linux 运维延伸至跨平台设备信任体系构建——你的私有 CA，可能明天就要为一台物理服务器的固件更新签名，或为一个出口到美国的儿童玩具产品标签（Law Label）生成符合 14 州 URN/CA/UT/PA 注册要求的数字凭证。

我试过用 OpenSSL 命令行硬敲，也试过 Ansible Playbook 自动化，还踩过 keytool is not available 这个坑——它根本不是 Java 环境问题，而是 Debian 10 默认不装 openjdk-11-jre-headless ，而某些旧版脚本又错误地依赖 keytool 来导入根证书。这些细节，恰恰是“能跑通”和“能长期稳住”的分水岭。接下来，我会带你从零开始，在一台干净的 Debian 10 虚拟机上，用最原生、最可控的方式，把整个 CA 的骨架、血肉和神经都搭出来。不依赖任何第三方工具链，每一步命令背后都有明确的工程意图，每一个配置项都解释它“为什么必须这样设”。

2. 根证书的诞生：密钥强度、有效期与策略设计的三重取舍

在 Debian 10 上启动一个 CA，第一步永远不是敲 openssl req ，而是坐下来想清楚三个问题：这张根证书要管多久？它能签什么？谁来保管它的私钥？这三个问题的答案，直接决定了你未来三年会不会半夜被报警电话叫醒。

2.1 密钥长度：4096 位是底线，而非选择

Debian 10 的 OpenSSL 版本（1.1.1d）默认支持 RSA 4096 和 ECDSA secp384r1。很多人图省事用 2048 位 RSA，但这是危险的妥协。2023 年 NIST SP 800-57 已明确建议： 所有新部署的根 CA 密钥应至少为 RSA 3072 或 ECDSA 256 。而 Debian 10 的硬件普遍支持 4096，性能损耗几乎可忽略（实测生成一次 CSR 仅慢 0.2 秒），却能将暴力破解时间从“数年”拉长到“宇宙年龄级别”。更重要的是，Windows UEFI Secure Boot 的 Platform Key（PK）和 Key Exchange Key（KEK）规范，明确要求使用 4096 位 RSA 或等效强度的 ECC。如果你的 CA 未来要为固件签名，现在就用 2048 位，等于提前给自己埋下兼容性雷。

# 在 /root/ca 目录下创建密钥，使用 -aes256 加密保护私钥文件
mkdir -p /root/ca/{private,db,certs,newcerts,crl}
chmod 700 /root/ca/private
openssl genrsa -aes256 -out /root/ca/private/ca.key.pem 4096

提示： -aes256 是强制要求。根私钥一旦泄露，整个信任链即告崩溃。密码必须离线保存（如写在纸上锁进保险柜），绝不能存在任何电子文档或密码管理器中。我见过太多人把密码存在 ca.key.pem 同目录下的 password.txt 里，结果被误删脚本一并清空。

2.2 有效期：20 年是理论极限，10 年是工程实践平衡点

RFC 5280 规定根证书最长有效期为 25 年，但现实很骨感。Debian 10 的 ca-certificates 包在 2023 年后已开始对超长有效期证书发出警告；Chrome 浏览器从 2021 年起将超过 398 天的证书标记为“不推荐”；而最关键的是—— 你真的能保证 20 年内不丢失私钥、不更换服务器、不遭遇磁盘故障吗？ 我的建议是：根证书设为 10 年（3650 天），中间证书（Intermediate CA）设为 5 年，终端实体证书（Server/Client Certs）设为 1 年。这样，你每 5 年只需轮换一次中间 CA，而根 CA 只需在第 10 年做一次计划内迁移，风险完全可控。

# 生成根证书请求（CSR），注意 -days 参数是 3650，不是 10000
openssl req -config /root/ca/openssl.cnf \
  -key /root/ca/private/ca.key.pem \
  -new -x509 -days 3650 -sha256 -extensions v3_ca \
  -out /root/ca/certs/ca.cert.pem

2.3 策略文件： openssl.cnf 是 CA 的宪法，不是可有可无的配置

Debian 10 自带的 /etc/ssl/openssl.cnf 是通用模板，绝不能直接用于生产 CA。你必须创建专属的 /root/ca/openssl.cnf ，其中最关键的三个区块是：

• [ ca ] ：定义数据库路径、默认证书有效期、默认摘要算法；
• [ policy_strict ] ：强制要求所有字段（C, ST, L, O, OU, CN）必须匹配，杜绝“CN=*.example.com”这种模糊匹配；
• [ v3_ca ] ：定义根证书的 X509v3 扩展，尤其是 basicConstraints = critical, CA:true 和 keyUsage = critical, digitalSignature, cRLSign, keyCertSign —— 这两项缺失，Windows 就会拒绝将其识别为有效 CA。

下面是我实际部署中使用的精简版 openssl.cnf 核心片段（已移除所有注释和冗余项，仅保留生产必需）：

[ ca ]
default_ca = CA_default

[ CA_default ]
dir               = /root/ca
certs             = $dir/certs
crl               = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/db/index
serial            = $dir/db/serial
RANDFILE          = $dir/private/.rand
private_key       = $dir/private/ca.key.pem
certificate       = $dir/certs/ca.cert.pem
crlnumber         = $dir/db/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_days      = 365
default_md        = sha256
name_opt          = ca_default
cert_opt          = ca_default
email_in_dn       = no
policy            = policy_strict

[ policy_strict ]
countryName             = match
stateOrProvinceName     = match
localityName            = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ v3_ca ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = critical, CA:true
keyUsage               = critical, digitalSignature, cRLSign, keyCertSign

注意： [ policy_strict ] 中的 match 表示子证书的 C/ST/L/O 字段必须与根证书完全一致。这是企业内网 CA 的黄金准则——它能防止开发人员用个人邮箱申请到公司域名证书。而 supplied 表示 CN 字段必须由用户显式提供，不能留空。

3. 从根 CA 到中间 CA：为什么必须分层，以及如何避免“单点爆炸”

在 Debian 10 上，把根 CA 私钥直接用来签发服务器证书，就像把银行金库的主钥匙挂在前台接待员腰带上。一旦某台 Web 服务器被入侵，攻击者拿到的不仅是该服务器的证书，更是能签发任意域名证书的根私钥。这就是为什么 X.509 标准强制要求分层设计 ：根 CA（Root CA）只签发中间 CA（Intermediate CA）证书，而中间 CA 再签发终端实体证书。根私钥离线保存，中间 CA 私钥在线运行，形成一道可信隔离墙。

3.1 中间 CA 的密钥与证书：一次生成，五年无忧

中间 CA 的密钥强度可以略低于根 CA（如 RSA 3072），但策略必须同样严格。关键区别在于其证书扩展：

• basicConstraints = critical, CA:true, pathlen:0 ： pathlen:0 表示该中间 CA 不能再签发下一级中间 CA ，只能签发终端证书。这是防止信任链无限延伸的安全阀。
• keyUsage = critical, digitalSignature, keyEncipherment, keyCertSign ：相比根 CA，这里去掉了 cRLSign ，因为 CRL（证书吊销列表）通常由根 CA 或专用 CRL 签发者发布。

生成步骤如下（全程在 /root/ca 目录下执行）：

# 1. 创建中间 CA 目录结构
mkdir -p /root/ca/intermediate/{private,db,certs,crl,newcerts}
chmod 700 /root/ca/intermediate/private

# 2. 生成中间 CA 私钥（3072 位，AES256 加密）
openssl genrsa -aes256 \
  -out /root/ca/intermediate/private/intermediate.key.pem 3072

# 3. 生成中间 CA 证书请求（CSR）
openssl req -config /root/ca/intermediate/openssl.cnf \
  -key /root/ca/intermediate/private/intermediate.key.pem \
  -new -sha256 -out /root/ca/intermediate/csr/intermediate.csr.pem

# 4. 用根 CA 签发中间 CA 证书（注意 -extensions v3_intermediate_ca）
openssl ca -config /root/ca/openssl.cnf \
  -extensions v3_intermediate_ca -days 1825 -notext -md sha256 \
  -in /root/ca/intermediate/csr/intermediate.csr.pem \
  -out /root/ca/intermediate/certs/intermediate.cert.pem \
  -keyfile /root/ca/private/ca.key.pem \
  -cert /root/ca/certs/ca.cert.pem

提示： -extensions v3_intermediate_ca 指向 openssl.cnf 中一个专门定义中间 CA 扩展的区块。如果你漏掉这个参数，签出来的证书会缺少 pathlen:0 ，导致安全审计直接失败。

3.2 证书链拼接：让浏览器和 curl 都能自动信任的终极技巧

签发完中间 CA 证书后，你手上有了三份文件：

• /root/ca/certs/ca.cert.pem （根证书）
• /root/ca/intermediate/certs/intermediate.cert.pem （中间证书）
• /root/ca/intermediate/certs/intermediate.cert.pem （中间证书）

但绝大多数服务（Nginx、Apache、Docker Registry）只接受一个 fullchain.pem 文件，它必须按 从终端证书到根证书的逆序 拼接。很多人错误地把根证书放在最前面，结果浏览器提示“无法验证证书颁发者”。

正确拼接命令（以签发一个 web.example.com 证书为例）：

# 假设你已用中间 CA 签发了 web.example.com.crt.pem
cat web.example.com.crt.pem \
  /root/ca/intermediate/certs/intermediate.cert.pem \
  /root/ca/certs/ca.cert.pem \
  > web.example.com.fullchain.pem

这个 fullchain.pem 就是 Nginx 的 ssl_certificate 指令所指向的文件。而 web.example.com.key.pem （私钥）则作为 ssl_certificate_key 。 永远不要把私钥和证书链放在同一个文件里 ——这是 Nginx 0.7.14 之后版本的硬性要求，否则会报错 SSL_CTX_use_PrivateKey_file failed 。

3.3 吊销机制：CRL 不是摆设，而是你最后的防线

当某台服务器私钥泄露，或员工离职需立即禁用其客户端证书时，你不能只删除证书文件，必须发布吊销信息。CRL（Certificate Revocation List）是 X.509 最成熟、最广泛支持的吊销机制。在 Debian 10 上，你需要：

1. 初始化 CRL 数据库：

   echo 1000 > /root/ca/db/crlnumber
   touch /root/ca/db/index
   

2. 生成初始 CRL（有效期 30 天，每天更新）：

   openssl ca -config /root/ca/openssl.cnf \
     -gencrl -out /root/ca/crl/ca.crl.pem -crldays 30
   

3. 将 CRL 分发给客户端：把 /root/ca/crl/ca.crl.pem 放到 Web 服务器可访问路径（如 https://pki.example.com/crl/ca.crl.pem ），并在中间 CA 证书的 crlDistributionPoints 扩展中声明该 URL。

注意： crlDistributionPoints 必须在签发中间 CA 证书时就写入。如果忘了，只能重新签发中间 CA——这就是为什么第 2.3 节强调 openssl.cnf 必须一次性配对。我曾因漏配此字段，导致整个集群的客户端证书吊销功能瘫痪两周。

4. 终端证书签发实战：从 Nginx 到 Windows UEFI 的全场景覆盖

有了根 CA 和中间 CA，真正的价值才开始释放。这一节，我将用三个真实场景，展示如何用同一套 CA 体系，解决不同层级的信任需求：一个面向 Web 服务的 HTTPS 证书、一个面向开发者的客户端认证证书、一个面向硬件固件的 UEFI 签名证书。

4.1 场景一：为 Nginx 服务器签发 HTTPS 证书（含 SAN）

现代 Web 服务必须支持多域名（如 www.example.com 和 api.example.com ），这需要 Subject Alternative Name（SAN）扩展。OpenSSL 1.1.1d 在 Debian 10 上不支持 -addext 参数，必须通过临时配置文件注入 SAN。

步骤如下：

# 1. 创建 CSR 配置文件（san.conf）
cat > san.conf <<EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[dn]
C = CN
ST = Beijing
L = Beijing
O = Example Inc
OU = IT
CN = www.example.com

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = www.example.com
DNS.2 = api.example.com
DNS.3 = example.com
IP.1 = 192.168.1.100
EOF

# 2. 生成私钥和 CSR
openssl req -new -keyout web.key.pem -out web.csr.pem -config san.conf

# 3. 用中间 CA 签发（注意 -extensions server_cert）
openssl ca -config /root/ca/intermediate/openssl.cnf \
  -extensions server_cert -days 365 -notext -md sha256 \
  -in web.csr.pem -out web.cert.pem \
  -keyfile /root/ca/intermediate/private/intermediate.key.pem \
  -cert /root/ca/intermediate/certs/intermediate.cert.pem

关键点在于 -extensions server_cert ，它指向 intermediate/openssl.cnf 中定义的 server_cert 区块，该区块必须包含：

[ server_cert ]
basicConstraints = CA:FALSE
nsCertType = server
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
subjectAltName = @alt_names

实测心得： extendedKeyUsage = serverAuth, clientAuth 是必须的。如果只写 serverAuth ，某些 Android 客户端会拒绝连接；如果只写 clientAuth ，Nginx 会报 SSL_CTX_use_certificate_chain_file failed 。双写是最稳妥的方案。

4.2 场景二：为开发者签发客户端证书（mTLS 认证）

当你的 API 需要强身份认证时，mTLS（双向 TLS）比 API Key 更安全。签发客户端证书的关键是 nsCertType = client 和 extendedKeyUsage = clientAuth 。

# 生成开发者证书请求（dev.conf）
cat > dev.conf <<EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[dn]
C = CN
ST = Beijing
L = Beijing
O = Example Inc
OU = Dev
CN = developer@alice.example.com

[req_ext]
nsCertType = client
extendedKeyUsage = clientAuth
EOF

openssl req -new -keyout dev.key.pem -out dev.csr.pem -config dev.conf
openssl ca -config /root/ca/intermediate/openssl.cnf \
  -extensions usr_cert -days 365 -notext -md sha256 \
  -in dev.csr.pem -out dev.cert.pem \
  -keyfile /root/ca/intermediate/private/intermediate.key.pem \
  -cert /root/ca/intermediate/certs/intermediate.cert.pem

然后将 dev.cert.pem 、 dev.key.pem 和 ca.cert.pem （根证书）打包成 PKCS#12 文件供开发者导入浏览器：

openssl pkcs12 -export -clcerts -in dev.cert.pem \
  -inkey dev.key.pem -out dev.p12 \
  -certfile /root/ca/certs/ca.cert.pem

注意： -clcerts 参数确保只包含客户端证书，不包含中间证书。如果开发者导入时提示“证书链不完整”，一定是漏了 -certfile 。

4.3 场景三：为 Windows UEFI Secure Boot 签名固件（.efi 文件）

这是最易被忽视，却最具战略价值的场景。 secure boot windows uefi ca 2023 updater 这个热词，直指企业级固件更新签名需求。Debian 10 本身不提供 sbsign 工具，需手动编译：

# 安装依赖并编译 sbsign
apt-get install -y build-essential libssl-dev libefivar-dev libefiboot-dev
git clone https://github.com/rhboot/efitools.git
cd efitools && make && sudo make install

# 使用中间 CA 的私钥和证书签名 .efi 文件
sbsign --key /root/ca/intermediate/private/intermediate.key.pem \
  --cert /root/ca/intermediate/certs/intermediate.cert.pem \
  --output shim-signed.efi shim.efi

签名后的 shim-signed.efi 即可作为 UEFI 启动加载器，其信任链最终回溯到你的根 CA。这意味着，只要将 /root/ca/certs/ca.cert.pem 导入目标 Windows 机器的 UEFI 固件密钥数据库（KEK），该机器就会无条件信任所有由你 CA 签名的固件更新。

关键提醒：UEFI 要求证书必须使用 SHA256 或更高摘要算法，且密钥必须为 RSA 2048+ 或 ECC 256+。Debian 10 的 OpenSSL 1.1.1d 完全满足，但如果你用旧版 sbsign （< 0.9.0），它可能不支持 SHA256，导致签名失败。务必检查 sbsign --version 。

5. 信任锚点分发：让 Debian、Windows、macOS 全平台无感信任你的 CA

签发证书只是前半场，让所有客户端信任它才是真正的挑战。 ca证书 这个热词背后，是跨平台证书信任体系的落地难题。在 Debian 10 上，你有三种分发方式，适用不同场景：

5.1 方式一：Debian/Ubuntu 系统级信任（ update-ca-certificates ）

这是最彻底的方式，让 curl 、 wget 、 apt 、 python-requests 等所有系统工具自动信任你的 CA。

# 将根证书复制到系统证书目录（注意文件名必须以 .crt 结尾）
sudo cp /root/ca/certs/ca.cert.pem /usr/local/share/ca-certificates/example-ca.crt
# 更新系统信任库
sudo update-ca-certificates

执行后， /etc/ssl/certs/ca-certificates.crt 会被重新生成，其中包含你的根证书。验证方法：

curl -I https://internal-api.example.com  # 应返回 200，无 SSL 错误

注意： update-ca-certificates 会扫描 /usr/local/share/ca-certificates/ 下所有 .crt 文件，但 不会递归扫描子目录 。如果你把证书放在 /usr/local/share/ca-certificates/example/ca.crt ，它会被忽略。

5.2 方式二：Windows 批量导入（PowerShell + Group Policy）

对于企业环境，手动双击导入根证书是不可接受的。必须用 PowerShell 脚本批量部署：

# save as deploy-ca.ps1
$caPath = "\\fileserver\certs\example-ca.crt"
$store = New-Object System.Security.Cryptography.X509Certificates.X509Store "Root", "LocalMachine"
$store.Open("ReadWrite")
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$cert.Import($caPath)
$store.Add($cert)
$store.Close()

然后通过 Group Policy 的“启动脚本”推送到所有域内 Windows 机器。关键点：必须导入到 LocalMachine\Root 存储，而非 CurrentUser\Root ，否则服务账户（如 IIS Application Pool Identity）无法读取。

5.3 方式三：macOS 钥匙串批量部署（ security add-trusted-cert ）

macOS 的信任链更复杂，需指定信任设置：

# 将根证书导入系统钥匙串，并设置为“始终信任”
sudo security add-trusted-cert -d -r trustRoot -k /System/Library/Keychains/SystemRootCertificates.keychain /path/to/ca.cert.pem

重要区别： -k /System/Library/Keychains/SystemRootCertificates.keychain 是系统级信任，影响所有用户和进程；而 -k /Library/Keychains/System.keychain 是旧版路径，macOS Catalina 之后已弃用。用错路径会导致 Safari 信任而 Chrome 不信任。

5.4 验证信任链：用 openssl verify 做终极审判

无论采用哪种分发方式，最终都必须用 OpenSSL 命令验证信任链是否真正打通：

# 验证终端证书是否被根证书信任
openssl verify -CAfile /root/ca/certs/ca.cert.pem web.cert.pem

# 验证终端证书是否被系统信任库信任（Debian）
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt web.cert.pem

# 验证完整证书链（含中间证书）
openssl verify -untrusted /root/ca/intermediate/certs/intermediate.cert.pem \
  -CAfile /root/ca/certs/ca.cert.pem web.cert.pem

只有当输出为 web.cert.pem: OK 时，才能确认信任链完整。任何 unable to get local issuer certificate 或 self signed certificate in certificate chain 错误，都意味着中间证书缺失或根证书未正确分发。

6. 日常运维与灾难恢复：当私钥丢失、证书过期或配置崩坏时怎么办

CA 不是建完就高枕无忧的。在 Debian 10 上，一套可持续运行的 CA，必须有清晰的运维 SOP 和灾难恢复预案。以下是我过去三年踩坑总结出的四条铁律：

6.1 私钥备份：离线、加密、三副本，缺一不可

根 CA 私钥 /root/ca/private/ca.key.pem 是整个体系的心脏。我的备份策略是：

• 副本一（热备） ：加密后存于同一台服务器的 /backup/ca-key-backup.enc ，密码用 gpg --symmetric 加密，密码离线记录；
• 副本二（冷备） ：刻录到一次性 CD-R 光盘，存于防火保险柜；
• 副本三（异地） ：U 盘加密（VeraCrypt 容器），寄存于另一城市办公室。

警惕： openssl rsa -in ca.key.pem -text 这类命令会将私钥明文输出到终端，如果终端历史被记录，等于泄露。永远用 openssl rsa -in ca.key.pem -noout -text 查看公钥信息。

6.2 证书过期监控：用 cron + shell 脚本实现全自动预警

Debian 10 的 cron 是最可靠的监控引擎。创建 /root/ca/scripts/check-expiry.sh ：

#!/bin/bash
# 检查根证书、中间证书、所有已签发证书的剩余有效期
ROOT_DAYS=$(openssl x509 -in /root/ca/certs/ca.cert.pem -enddate -noout | awk -F'= ' '{print $2}' | xargs -I {} date -d {} +%s 2>/dev/null)
NOW=$(date +%s)
if [ $((ROOT_DAYS - NOW)) -lt $((30*86400)) ]; then
  echo "ALERT: Root CA expires in <30 days!" | mail -s "CA Expiry Alert" admin@example.com
fi

加入 crontab 每日执行：

0 9 * * * /root/ca/scripts/check-expiry.sh

6.3 中间 CA 轮换：无缝切换的五步法

当中间 CA 证书即将过期，你不能停机。必须在旧中间 CA 过期前，用根 CA 签发新中间 CA，并逐步将服务迁移到新链：

1. 生成新中间 CA 私钥和 CSR；
2. 用根 CA 签发新中间 CA 证书；
3. 将新中间 CA 证书和根证书拼接为 fullchain-new.pem ；
4. 在 Nginx 配置中同时启用新旧两个 ssl_certificate （需 Nginx 1.11.0+）；
5. 监控日志，确认所有新连接都使用新链后，再下线旧链。

这个过程可以做到零中断。我曾在金融客户生产环境完成过一次中间 CA 轮换，全程无任何业务感知。

6.4 灾难恢复：从备份重建 CA 的精确步骤

假设服务器硬盘损坏，你只有三份备份（光盘、U 盘、加密文件）。恢复步骤必须严格按顺序：

1. 在新 Debian 10 服务器上安装 OpenSSL；
2. 从光盘恢复 /root/ca/private/ca.key.pem 和 /root/ca/certs/ca.cert.pem ；
3. 用根私钥重建中间 CA 数据库：

   openssl ca -config /root/ca/openssl.cnf -gencrl -out /root/ca/crl/ca.crl.pem
   

4. 从 U 盘恢复 /root/ca/intermediate/private/intermediate.key.pem 和 /root/ca/intermediate/certs/intermediate.cert.pem ；
5. 用 openssl ca -revoke 命令，根据原始 index 文件逐条恢复吊销状态。

最后一步耗时最长，但不可或缺。跳过它，所有已吊销证书将重新变为有效，造成严重安全漏洞。

我在实际操作中发现，最常被忽略的是第 4 步——人们以为中间 CA 证书足够，却忘了中间 CA 的私钥同样需要从备份恢复。没有私钥，你就无法签发任何新证书，整个 CA 形同虚设。这个教训，值得用一次真实的硬盘故障来铭记。