step-ca 与 AD GPO 的企业内部 PKI

在企业内网环境中，大量基础设施与业务系统开始通过 HTTPS 提供管理入口与应用服务，例如邮件系统、跳板机、WAF、内部 Wiki、Git 服务、NAS 管理界面等。如果每台服务器各自使用自签名证书，客户端浏览器将持续出现不受信任告警，不仅影响使用体验，也削弱了运维体系的一致性与可信度。

合理的方案是建立一套统一的企业内部 PKI：由内部 CA 统一签发内网站点证书，由域控通过 GPO 将根证书与中间证书下发到域内终端，从而在企业环境中实现内部 HTTPS 默认受信任。

一、架构目标与职责划分

内部 PKI 的落地本质上由三类角色共同完成。

第一类是 CA 服务器。它承载 step-ca，负责保存 CA 密钥材料、接收 CSR、签发服务器证书，是企业内网的统一发证中心。

第二类是 业务服务器。每个实际提供 HTTPS 服务的业务系统都属于这一类，例如 Mailu、JumpServer、NAS、SafeLine、内部 Wiki 等。业务服务器负责生成自己的私钥与 CSR，接收签发后的证书，并将其加载到本地服务。

第三类是 域控 / GPO。它不负责签发证书，而是负责建立信任。通过组策略将 Root CA 与 Intermediate CA 下发到域内 Windows 终端的本地证书存储区，使浏览器与系统能够信任由内部 CA 签发的站点证书。

这三类角色的职责可以概括为：

step-ca 负责发证；

业务服务器负责使用证书；

AD / GPO 负责建立客户端信任。

理解这一点之后，后续所有内部站点接入这套 PKI 的流程都会变得清晰。

二、证书信任的原理

在初次接触内部 PKI 时，容易误以为服务器部署了证书，浏览器就应该自动信任。实际上并非如此。

浏览器之所以信任一个 HTTPS 站点，不是因为服务器启用了证书，而是因为它能够沿着证书链验证到一个自己已经信任的根证书。

以企业内部站点为例，服务端实际提供的是站点证书，例如 mailu.yxwa.info。该证书由企业内部 Intermediate CA 签发，而 Intermediate CA 又由企业内部 Root CA 签发。只有当客户端已经信任这套内部 Root CA，并且能够识别 Intermediate CA，整条链路才成立，浏览器才会将该站点判定为受信任。

因此，企业内部 PKI 的落地必须同时完成两件事：

一是统一签发内网服务器证书；
二是统一向终端建立 CA 信任。

两者缺一不可。

三、统一签发的基本流程

统一签发的核心原则是：私钥留在业务服务器本机，CSR 送到 CA 服务器签发，签发后的证书再返回业务服务器使用。

这套流程可以稳定复用于任何内部服务。

首先先进入到step-ca的配置文件，由于默认只有24h的时效，我们加入全局变量，将最大签发有效期扩大至三个月(2160h)

业务服务器生成私钥与 CSR

私钥应在业务服务器本机生成，不应在 CA 上代为生成。这样可以避免业务私钥离开服务宿主机，降低密钥泄露风险。

以 wiki.yxwa.info 为例，在业务服务器上可以使用 OpenSSL 生成私钥与 CSR：

mkdir -p /etc/pki/internal/wiki.yxwa.info
cd /etc/pki/internal/wiki.yxwa.infoopenssl genrsa -out wiki.yxwa.info.key 4096openssl req -new \
  -key wiki.yxwa.info.key \
  -out wiki.yxwa.info.csr \
  -subj "/CN=wiki.yxwa.info" \
  -addext "subjectAltName=DNS:wiki.yxwa.info"

这一步的输出是：

业务私钥：wiki.yxwa.info.key
证书申请：wiki.yxwa.info.csr

其中，SAN 必须显式写入，否则很多现代浏览器不会仅依据 CN 进行主机名校验。

CA 服务器签发证书

CSR 生成后，将其传送到 CA 服务器，在 step-ca 所在主机上完成签发。

签发命令的核心形式如下：

step ca sign \
  /tmp/wiki.yxwa.info.csr \
  /tmp/wiki.yxwa.info.crt \
  --provisioner admin \
  --ca-url https://ca.yxwa.info:8443 \
  --root /opt/step/certs/root_ca.crt \
  --not-after 2160h

这里指定了：

CSR 路径；
输出证书路径；
所使用的 provisioner；
CA 服务地址；
Root CA 用于客户端校验；
证书有效期。

本次实践中，最终将 TLS 证书有效期调整为 90 天，即 2160h。这在内部环境中是一个较为均衡的选择：既避免过短有效期带来的高频运维，也比一年期证书更容易纳入后续生命周期管理。

将签发后的证书部署回业务服务器

签好的证书文件应回传到业务服务器，并与本机私钥一起部署到业务服务中。

许多 Web 服务实际需要的不是单张叶子证书，而是 fullchain，即：

站点证书；

中间证书。

常见做法是将两者拼接为 fullchain.pem：

cat wiki.yxwa.info.crt intermediate_ca.crt > fullchain.pem

随后在 Nginx、Apache、Mailu、JumpServer 等服务中，分别配置：

证书文件：fullchain.pem

私钥文件：wiki.yxwa.info.key

验证服务端证书链

证书部署完成后，应使用 openssl s_client 验证站点实际返回的证书链：

openssl s_client -connect wiki.yxwa.info:443 -servername wiki.yxwa.info -showcerts </dev/null

应重点确认：

叶子证书主题是否正确；

SAN 是否包含目标域名；

颁发者是否为企业内部 Intermediate CA；

服务端是否连同中间证书一并返回；

有效期是否符合预期。

这一检查非常重要，因为客户端的不受信任并不总是由 CA 信任缺失导致，服务端链配置不完整同样会触发浏览器警告。

四、通过 GPO 建立域内统一信任

仅完成证书签发和部署还不够。如果域内终端没有信任 Root CA 与 Intermediate CA，浏览器仍然会提示证书不受信任。

在企业 AD 环境中，最合适的做法是通过 GPO 下发证书信任，而不是在每台客户端手工导入。

准备分发材料

应从 CA 服务器整理并导出以下两个文件：

root_ca.crt

intermediate_ca.crt

其中：

Root CA 证书用于导入受信任的根证书颁发机构；

Intermediate CA 证书用于导入中间证书颁发机构。

新建 GPO

在组策略管理中，以域为作用范围创建新的 GPO，例如：

YXWA - Internal PKI Trust

建议单独使用一个 GPO 管理内部 CA 信任，便于后续维护、审计与变更。

导入根证书与中间证书

在 GPO 编辑器中，路径为：

计算机配置 → 策略 → Windows 设置 → 安全设置 → 公钥策略

在此处分别导入：

Root CA 到“受信任的根证书颁发机构”；
Intermediate CA 到“中间证书颁发机构”。

完成后，该 GPO 即可向域内计算机统一分发内部 CA 信任。

客户端刷新组策略并验证

在已加入域的 Windows 客户端上执行：

gpupdate /force

随后检查本地证书存储区，确认两张证书已经下发到本机：

Get-ChildItem Cert:\LocalMachine\Root | Where-Object {$_.Subject -like "*Root CA*"}
Get-ChildItem Cert:\LocalMachine\CA   | Where-Object {$_.Subject -like "*Intermediate CA*"}

当客户端已经收到这两张证书后，再访问内部 HTTPS 站点，浏览器即可完成完整链路验证，站点将显示为受信任。