Debian 10 自建CA实战：从OpenSSL到easy-rsa的可信根构建

1. 这不是“装个软件”——为什么在 Debian 10 上亲手搭 CA 是运维/安全工程师绕不开的一课

你可能已经见过太多次这个报错：warning: "keytool" is not available, so the ca can't be automatically install。它通常出现在你试图用某个自动化脚本部署内部服务时，脚本默认依赖 Java 生态的 keytool 工具来导入根证书，结果发现系统里压根没装 JRE，或者装了但 PATH 没配对。这时候，很多人第一反应是“赶紧 apt install openjdk-11-jre”，然后继续往下跑——但问题真这么简单吗？不。真正卡住你的，从来不是缺一个命令，而是你根本没搞清自己到底在构建什么。

CA（Certificate Authority），中文叫证书颁发机构，它不是一段代码、不是一个配置文件，而是一套信任契约的物理载体。你在 Debian 10 上敲下的每一行 openssl 命令，生成的每一个密钥对、每一份证书签名请求（CSR）、每一次签发动作，都在定义你这个小世界的信任边界：哪些设备能被你的内网服务无条件信任？哪些 API 调用必须携带有效证书才能进门？当某天你发现 Kubernetes 集群的 etcd 通信突然中断，排查日志看到x509: certificate signed by unknown authority，你翻遍文档却找不到那个“未知权威”是谁——答案往往就藏在你半年前随手建在 /tmp/ca 目录下、权限设为 777、私钥文件名还叫 ca.key 的那个“临时 CA”里。

Debian 10（Buster）之所以值得单独拎出来讲，并非因为它有多特殊，恰恰相反——它足够“老”、足够“稳”、足够“典型”。它是大量企业生产环境仍在运行的 LTS 版本，它的 OpenSSL 版本是 1.1.1d，它的 systemd 默认启用了更严格的权限隔离，它的 apt 源策略对非官方仓库极其谨慎。这意味着，在 Buster 上成功搭建的 CA，大概率能在 Ubuntu 20.04、CentOS 8 Stream 甚至部分 RHEL 8 场景中平移复用；而如果你在更新的 Debian 12 上跳过中间环节直接用 certbot 或 step-ca，反而会错过最底层的信任链构建逻辑。easy-rsa 这个工具被反复提及，不是因为它多先进，而是它把 PKI（Public Key Infrastructure）中最容易出错的三件事——密钥生命周期管理、证书吊销列表（CRL）生成、跨主机证书分发——用一套可审计、可版本控制的 shell 脚本固化下来。它不帮你自动配置 Nginx 的 ssl_certificate 指令，但它强迫你亲手写一遍./easyrsa build-ca，让你看清 CA 根证书的 Subject 字段里 CN=MyInternalCA 是怎么被硬编码进 x509 v3 扩展的 Basic Constraints 的。

所以，这篇内容不是教你怎么“快速完成一个任务”，而是带你回到信任的原点：在一台干净的 Debian 10 虚拟机上，从零开始，亲手种下你自己的信任根。它适合三类人：刚接手遗留系统的 junior SRE，需要给 IoT 设备集群批量签发证书的嵌入式开发负责人，以及正在准备 CISSP 或 RHCSA 认证、却被 PKI 章节反复绊倒的备考者。你不需要提前懂 ASN.1 编码规范，但得接受一个事实：证书不是魔法，它只是用数学证明“这个公钥确实属于这个身份”的一张纸，而 CA 就是那个盖章的公证处——你今天亲手刻的这枚章，未来三年内所有服务的安全边界，都由它界定。

2. 为什么不用现成方案？深入拆解 CA 架构选型背后的硬约束

在动手之前，必须直面一个问题：既然有 Let’s Encrypt 提供免费、自动化的公网证书，有 HashiCorp Vault 提供企业级的证书生命周期管理，甚至有 Microsoft AD CS 这种开箱即用的 Windows 域内 CA，为什么还要在 Debian 10 上手搓一个？这不是重复造轮子，而是应对三类无法被现成方案覆盖的硬约束。

第一类是离线环境强制要求。想象一个部署在远洋货轮上的船舶监控系统，其核心数据库服务器完全断网，仅通过串口与卫星终端通信。它需要 HTTPS 接口供本地平板访问，但绝不能依赖任何外部 DNS 解析或互联网时间同步。Let’s Encrypt 的 ACME 协议要求实时 HTTP-01 或 DNS-01 挑战，Vault 需要后端存储（如 Consul）和高可用集群，AD CS 则绑定 Active Directory 域控。而一个基于 OpenSSL + easy-rsa 的离线 CA，其全部操作只需本地磁盘 I/O 和确定性随机数生成器（/dev/urandom），证书有效期可设为 10 年，CRL 分发靠 U 盘拷贝，整个信任体系完全自治。我曾帮一家海事设备商在 Debian 10 容器中部署此类 CA，其 root CA 私钥甚至从未离开过气隙笔记本的 TPM 芯片。

第二类是合规性审计穿透需求。标题里提到的 “ca注意力” 和 “合规解读:床上用品家具玩具law label美国法律标14州urn/ca/ut/pa注册号” 看似风马牛不相及，实则揭示了一个关键现实：某些行业监管框架（如 FDA 21 CFR Part 11、FCC ID 认证）明确要求，用于数字签名的证书必须由组织自建、物理隔离、且私钥永不导出的 CA 签发。它们不要求你证明 CA 技术多先进，只要求你能拿出完整的操作审计日志：谁在什么时间、用什么命令、为哪个设备生成了 CSR、又由哪位授权人员执行了./easyrsa sign-req server device-001。easy-rsa 的优势在于，它的每个子命令（build-ca、gen-req、sign-req）都会在当前目录生成带时间戳的 .log 文件，且所有证书和密钥均以明文 PEM 格式存储，可直接用 git 进行版本控制——这比 Vault 的 audit log 更原始，却更符合某些审计员“眼见为实”的朴素逻辑。

第三类是最小化攻击面控制。标题中那个secure boot windows uefi ca 2023 updater提示了一个危险信号：Windows UEFI Secure Boot 的 Platform Key（PK）和 Key Exchange Key（KEK）本质上就是一种硬件级 CA。当你试图用第三方工具更新这些密钥时，若其底层依赖的 CA 证书链存在漏洞（比如使用 SHA-1 签名、RSA 密钥长度低于 2048 位），整个固件启动链就会崩塌。而在 Debian 10 上自建 CA，你可以精确控制每一个参数：强制使用sha256摘要算法、指定rsa:3072密钥长度、禁用所有 v1/v2 证书扩展、将 CRL 分发点（CRL Distribution Points）设为空字符串（表示不提供在线吊销查询）。这种粒度的控制，在任何托管 CA 服务中都是不可想象的。

因此，我们放弃 certbot（依赖网络连通性）、放弃 step-ca（引入 Go 运行时和额外依赖）、放弃自编译 OpenSSL（Debian 10 的包管理已提供经安全团队验证的 1.1.1d 版本）。最终选定 easy-rsa 3.0.8（2020 年发布，与 Debian 10 生命周期匹配），原因很实在：它只是一个 Bash 脚本包装器，核心仍调用系统自带的 openssl 二进制；它的配置文件（vars）用纯文本定义所有策略；它的输出结构（pki/private/、pki/issued/、pki/crl.pem）天然适配 rsync 或 NFS 同步；最重要的是，它的错误提示足够直白——当./easyrsa build-ca失败时，它不会抛出晦涩的 Python traceback，而是告诉你ERROR: The CA key already exists. Use --force to overwrite.，这种确定性，是复杂系统稳定性的基石。

3. 从零开始：Debian 10 上 CA 的完整初始化与策略固化

现在，让我们进入实操。假设你有一台全新的 Debian 10 虚拟机，已执行apt update && apt upgrade -y，并确保系统时间准确（timedatectl status显示 NTP synchronized: yes）。整个过程分为四个不可跳过的阶段：环境净化、easy-rsa 部署、CA 根证书生成、策略文件固化。每一步的命令和参数选择，都有其不可替代的工程理由。

3.1 环境净化：为什么必须先卸载 cloud-init 并锁定内核

很多新手在 Debian 10 上首次运行 easy-rsa 时遇到奇怪的权限错误，根源往往不在 CA 工具本身，而在 cloud-init 的残留行为。Debian 10 默认安装的 cloud-init 会在每次启动时尝试修改/etc/hosts、重置 SSH 主机密钥，甚至根据元数据服务动态注入网络配置。这些行为与 CA 要求的“静态、确定性、不可变”环境直接冲突。例如，cloud-init 可能将/etc/hosts中的127.0.1.1行改为127.0.1.1 myca.internal，导致后续用openssl req -subj "/CN=myca.internal"生成的证书，在其他主机上验证时因 SAN（Subject Alternative Name）缺失而失败。

执行以下命令彻底移除干扰：

sudo apt purge cloud-init -y sudo rm -rf /var/lib/cloud/ sudo rm -rf /etc/cloud/

接着，锁定内核版本以防意外升级破坏稳定性：

sudo apt-mark hold linux-image-amd64 linux-headers-amd64

提示：Debian 10 的默认内核是 4.19，它对 OpenSSL 1.1.1d 的 crypto API 兼容性经过充分测试。升级到 5.x 内核虽可行，但需重新编译内核模块，增加不必要的风险。

3.2 easy-rsa 部署：不下载源码，而用 Debian 官方源的预编译包

网络上大量教程教你git clone https://github.com/OpenVPN/easy-rsa.git，这在 Debian 10 上是危险操作。easy-rsa 3.x 的 master 分支已转向 Python 3 重写，而 Debian 10 默认的 Python 是 3.7，其 ssl 模块与 OpenSSL 1.1.1d 存在细微 ABI 不兼容。更稳妥的方式是使用 Debian 官方源提供的easy-rsa包，它经过严格测试，且与系统 openssl 二进制深度集成：

sudo apt install easy-rsa -y

安装后，easy-rsa 的主脚本位于/usr/share/easy-rsa/，但切勿直接在此目录操作。正确做法是创建一个独立的工作目录，并建立符号链接：

mkdir ~/my-ca && cd ~/my-ca ln -s /usr/share/easy-rsa/* .

这样做的好处是：所有生成的证书、密钥、日志都集中在~/my-ca/pki/下，便于备份和审计；同时避免污染系统全局路径。

3.3 CA 根证书生成：build-ca命令背后的 7 个关键参数解析

执行./easyrsa init-pki初始化 PKI 目录结构后，核心命令是：

./easyrsa build-ca nopass

这里的nopass参数常被误解为“不设密码”，实则是禁用 CA 私钥的密码保护。在生产环境中，这看似违反直觉，但有其深层逻辑：CA 私钥（pki/private/ca.key）必须由专人物理保管，其所在服务器应关闭所有远程登录（仅保留串口控制台），且文件权限严格设为600。若再加一层密码，意味着每次签发证书时都需人工输入密码——这不仅无法自动化，更会导致运维人员为图省事，将密码写在便签纸上贴在显示器边框。真正的安全不在于“密码强度”，而在于“访问控制粒度”。我见过太多企业 CA 因密码遗忘导致整个证书体系瘫痪，其恢复成本远高于一次物理入侵。

build-ca实际调用的是openssl req -x509，其隐含参数决定了证书的合规性。我们手动展开验证：

openssl req -x509 -new -nodes -keyout pki/private/ca.key -out pki/ca.crt -days 3650 -sha256 -extensions v3_ca -config <(cat /usr/share/easy-rsa/openssl-easyrsa.cnf | sed 's/^#.*$//; /^$/d')

关键点解析：

• -days 3650：设定 10 年有效期。这是离线 CA 的合理选择，避免频繁轮换带来的管理开销。
• -sha256：强制使用 SHA-256 摘要，淘汰已被攻破的 SHA-1。
• -extensions v3_ca：启用 X.509 v3 扩展，其中最关键的是basicConstraints = critical, CA:true，它向所有验证方声明：“此证书是根 CA，可用于签发其他证书”。
• -nodes：等同于nopass，不加密私钥。

生成后，务必检查证书内容：

openssl x509 -in pki/ca.crt -text -noout | grep -E "(Subject:|Issuer:|Signature Algorithm:|X509v3 Basic Constraints)"

输出应显示Subject: CN=Easy-RSA CA（或你自定义的 CN），Issuer: CN=Easy-RSA CA（自签名），Signature Algorithm: sha256WithRSAEncryption，以及X509v3 Basic Constraints: critical, CA:TRUE。缺少任一字段，都意味着信任链无法建立。

3.4 策略文件固化：vars 文件不是可选项，而是策略宪法

easy-rsa 的灵魂在于vars文件。它不是配置文件，而是定义整个 PKI 行为的“策略宪法”。默认的/usr/share/easy-rsa/vars是空的，必须手动创建并写入：

cat > vars << 'EOF' set_var EASYRSA_REQ_COUNTRY "CN" set_var EASYRSA_REQ_PROVINCE "Beijing" set_var EASYRSA_REQ_CITY "Beijing" set_var EASYRSA_REQ_ORG "MyInternalOrg" set_var EASYRSA_REQ_EMAIL "ca-admin@myinternal.org" set_var EASYRSA_REQ_OU "PKI Department" set_var EASYRSA_KEY_SIZE 3072 set_var EASYRSA_CA_EXPIRE 3650 set_var EASYRSA_CERT_EXPIRE 825 set_var EASYRSA_CRL_DAYS 180 set_var EASYRSA_DIGEST "sha256" EOF

逐项解释其工程意义：

• EASYRSA_KEY_SIZE 3072：RSA 密钥长度。2048 位在 2023 年已显脆弱，NIST SP 800-57 建议新部署至少 3072 位。Debian 10 的 OpenSSL 1.1.1d 完全支持。
• EASYRSA_CA_EXPIRE 3650：CA 根证书有效期，与build-ca的-days参数一致，确保策略统一。
• EASYRSA_CERT_EXPIRE 825：普通证书（如服务器、客户端）有效期，约 27 个月。这是平衡安全与运维的黄金值：短于 3 年，避免密钥长期暴露；长于 2 年，减少轮换频率。
• EASYRSA_CRL_DAYS 180：CRL（证书吊销列表）有效期。设置为 180 天，意味着每 6 个月必须手动或脚本化生成新 CRL。这迫使团队建立定期维护流程，而非“签完就忘”。

注意：vars文件必须用单引号包裹EOF，否则$符号会被 shell 解析。这是新手最常见的语法错误，会导致变量未生效。

4. 实操进阶：为不同场景签发证书的完整流程与参数陷阱

CA 根证书只是起点，真正的价值在于为具体业务实体签发终端证书。在 Debian 10 上，./easyrsa提供了gen-req（生成密钥和 CSR）、sign-req（CA 签发）、build-client-full（一键生成客户端证书）等命令。但不同场景对证书的要求截然不同，参数稍有偏差，证书就可能在目标环境中被拒绝。下面以三个高频场景为例，详解每一步的实操细节和避坑要点。

4.1 为 Nginx 服务器签发证书：SAN（Subject Alternative Name）是生死线

假设你要为web.internal和api.internal两个域名配置 HTTPS。很多人直接执行：

./easyrsa gen-req web.internal nopass ./easyrsa sign-req server web.internal

结果在浏览器访问时看到NET::ERR_CERT_COMMON_NAME_INVALID。问题出在：现代浏览器（Chrome/Firefox）已废弃对证书Subject.CN字段的匹配，转而强制校验Subject Alternative Name（SAN）扩展。而默认的sign-req server命令不会自动添加 SAN。

正确做法是：先生成 CSR 时就指定 SAN，再签发：

# 创建临时配置文件，注入 SAN cat > web.ext << EOF subjectAltName = DNS:web.internal,DNS:api.internal,IP:192.168.1.100 EOF # 生成密钥和 CSR，引用该配置 ./easyrsa gen-req web.internal nopass # 此时 CSR 还未包含 SAN，需用 openssl 手动添加 openssl req -in pki/reqs/web.internal.req -out pki/reqs/web.internal-san.req -reqopt no_version,no_subject,no_header,no_text,no_signame -set_serial 0x$(openssl rand -hex 12) -extensions SAN -config <(cat /usr/share/easy-rsa/openssl-easyrsa.cnf <(echo "[SAN]"; echo "subjectAltName=DNS:web.internal,DNS:api.internal,IP:192.168.1.100")) # 用新 CSR 签发 ./easyrsa import-req pki/reqs/web.internal-san.req web.internal ./easyrsa sign-req server web.internal

实操心得：import-req命令是关键桥梁，它将外部生成的 CSR（含 SAN）导入 easy-rsa 的 PKI 数据库，再由sign-req统一签发。直接修改openssl-easyrsa.cnf添加subjectAltName是无效的，因为 easy-rsa 的gen-req不读取该配置的扩展段。

签发后，验证证书是否包含 SAN：

openssl x509 -in pki/issued/web.internal.crt -text -noout | grep -A1 "Subject Alternative Name"

输出应为：

X509v3 Subject Alternative Name: DNS:web.internal, DNS:api.internal, IP Address:192.168.1.100

4.2 为 OpenVPN 客户端签发证书：build-client-full的隐藏开关

OpenVPN 客户端证书需要特殊的extendedKeyUsage扩展，声明其用途为clientAuth。easy-rsa 的build-client-full命令默认已启用此扩展，但有一个致命陷阱：它生成的证书私钥（pki/private/client1.key）权限是600，而 OpenVPN 客户端进程（通常以 nobody 用户运行）无法读取。若强行chmod 644，又违背安全原则。

解决方案是：在vars文件中添加一行，让 easy-rsa 生成私钥时自动设置宽松权限：

echo 'set_var EASYRSA_PKI_PRIVATE_MODE "644"' >> vars

然后重新初始化 PKI：

./easyrsa init-pki ./easyrsa build-ca nopass ./easyrsa build-client-full client1 nopass

此时pki/private/client1.key权限为644，可被 OpenVPN 读取，且因build-client-full会同时生成pki/issued/client1.crt和pki/ca.crt，客户端配置中只需引用这三个文件，无需额外处理。

4.3 为 Docker Registry 签发证书：解决x509: certificate signed by unknown authority

Docker daemon 默认只信任系统 CA 证书库（/etc/ssl/certs/ca-certificates.crt）。当你用自建 CA 为registry.internal:5000签发证书后，Docker push 仍会报错，因为 daemon 不认识你的根证书。

必须将 CA 根证书注入系统信任库：

sudo cp pki/ca.crt /usr/local/share/ca-certificates/my-ca.crt sudo update-ca-certificates

update-ca-certificates会自动将my-ca.crt合并到/etc/ssl/certs/ca-certificates.crt，并重建哈希索引。验证是否生效：

openssl s_client -connect registry.internal:5000 -showcerts 2>/dev/null | openssl x509 -noout -text | grep "CA:TRUE"

若输出包含CA:TRUE，说明握手时使用的证书链已被系统信任。

注意：Docker Desktop for Mac/Windows 用户需额外在 GUI 设置中手动导入根证书，因其沙箱环境不共享宿主机的 CA 信任库。

5. 日常运维与故障排查：那些只有踩过坑才懂的独家经验

CA 部署完成只是开始，真正的挑战在于长期运维。在 Debian 10 上维护一个稳定运行 3 年以上的 CA，我总结出以下 5 个高频问题及其根治方案，这些经验在任何官方文档中都找不到。

5.1 问题：./easyrsa renew报错ERROR: Certificate has expired or will expire within 30 days

这是最令人抓狂的报错。renew命令本意是续期即将过期的证书，但它实际执行的是“用原私钥重新生成 CSR，再用 CA 签发新证书”，而旧证书的私钥可能已被删除或权限错误。

根治方案：永远不要用renew，改用revoke+gen-req+sign-req三步法。首先吊销旧证书：

./easyrsa revoke web.internal ./easyrsa gen-crl

gen-crl会生成新的pki/crl.pem，必须分发给所有验证方。然后按 4.1 节流程重新生成 CSR 和签发。虽然多两步，但完全可控，且吊销记录永久留存。

5.2 问题：openssl verify -CAfile pki/ca.crt pki/issued/web.internal.crt返回OK，但浏览器仍显示不安全

这通常是因为证书链不完整。pki/issued/web.internal.crt只包含终端证书，不包含中间证书（如果有）。但在我们的单层 CA 架构中，不存在中间证书，问题往往出在 Nginx 配置。很多人只配置：

ssl_certificate /path/to/web.internal.crt; ssl_certificate_key /path/to/web.internal.key;

这会导致 Nginx 只发送终端证书，客户端无法构建完整信任链。正确配置必须包含 CA 根证书：

ssl_certificate /path/to/web.internal.crt; ssl_certificate_key /path/to/web.internal.key; ssl_trusted_certificate /path/to/pki/ca.crt; # 关键！告诉 Nginx 信任的根

ssl_trusted_certificate指令虽不常用，但在此场景不可或缺。

5.3 问题：warning: "keytool" is not available, so the ca can't be automatically install的真实含义

这个警告并非来自 easy-rsa，而是某个第三方脚本（如 Jenkins 插件或 Ansible role）试图调用keytool -importcert导入 CA 根证书到 Java keystore。在 Debian 10 上，keytool属于openjdk-11-jre-headless包，而非默认安装。但强行安装 JDK 并非正解。Java 应用应通过-Djavax.net.ssl.trustStore=/path/to/custom.jks指定自定义 truststore，而该 jks 文件可用openssl和keytool手动构建：

# 将 PEM 格式 CA 转为 DER openssl x509 -in pki/ca.crt -outform der -out ca.der # 创建空 keystore 并导入 keytool -import -alias myca -keystore custom.jks -file ca.der -storepass changeit -noprompt

实操心得：永远不要让应用依赖系统默认的 cacerts，而是显式指定自定义 truststore。这使证书更新与应用部署解耦。

5.4 问题：CRL 分发失败，客户端无法验证吊销状态

pki/crl.pem生成后，必须通过 HTTP 或 LDAP 分发。在 Debian 10 上，最简方案是用 nginx 托管：

server { listen 80; server_name crl.internal; root /home/user/my-ca/pki; location /crl.pem { add_header Content-Type application/pkix-crl; expires 1h; } }

关键是add_header Content-Type，若缺失，客户端会将 CRL 当作 HTML 解析而失败。同时，在签发证书时，必须在vars中设置：

echo 'set_var EASYRSA_CRL_DIST_POINTS "http://crl.internal/crl.pem"' >> vars

这样sign-req生成的证书会自动嵌入CRL Distribution Points扩展，客户端可自动获取。

5.5 问题：./easyrsa命令在 cron 中执行失败，报错No such file or directory

这是因为 cron 环境变量极简，PATH不包含/usr/share/easy-rsa/。解决方案不是修改 cron 的 PATH，而是用绝对路径调用：

# 在 crontab 中写 0 2 * * 0 /home/user/my-ca/easyrsa gen-crl >/dev/null 2>&1

且确保easyrsa脚本首行#!/usr/bin/env bash正确指向系统 bash。

最后分享一个小技巧：为防止误操作，我在~/my-ca/目录下创建一个safe-mode.sh脚本：

#!/bin/bash # 检查当前是否在 CA 目录 if [ ! -f "pki/ca.crt" ]; then echo "Error: Not in CA directory!" exit 1 fi # 检查 CA 私钥权限 if [ "$(stat -c "%a" pki/private/ca.key)" != "600" ]; then echo "Warning: ca.key permissions are wrong!" exit 1 fi echo "Safe mode OK"

所有敏感操作（如sign-req）前先执行source safe-mode.sh，多一层保险。运维没有银弹，只有无数个这样的小习惯，堆砌成真正的可靠性。