为什么要自建机构
内网与测试环境里，如果每个服务都各签一张自签证书，客户端就会积累一堆需要单独信任的条目，轮换时更是灾难。自建一个根，由它给各服务签发证书，客户端只需信任这一个根（RFC 5280 描述的正是这套公钥基础设施的基本结构）。
关键在签发是否规范
签发时必须显式配置主体备用名称：只用通用名的新客户端会判定域名不匹配。有效期、密钥长度与用途扩展也要按实际场景设置，别照搬教程里对测试环境的宽松参数。
基本信息
| 目标 | 一次建立根，集中签发与轮换各服务证书 |
|---|---|
| 必备扩展 | 主体备用名称必须显式列出国名之外的域名与通配符 |
| 工具选择 | 本地开发可用一键生成工具，生产内网建议自动化签发方案 |
| 规范 | RFC 5280 定义证书结构与路径验证 |
典型使用场景
- 内网服务之间启用加密传输
- 开发与测试环境模拟真实的证书签发流程
- 为内部设备与管理界面签发证书
- 替代「给每台机器单独装自签证书」的临时做法
最小自建流程
最小自建流程
# 1 生成根私钥与自签根证书
openssl req -x509 -newkey rsa:4096 -nodes -days 3650 -keyout ca.key -out ca.crt -subj "/CN=My Internal CA"
# 2 为服务生成密钥与请求
openssl req -new -newkey rsa:2048 -nodes -keyout svc.key -out svc.csr -subj "/CN=svc.internal"
# 3 用根签发，并显式写入备用名称
openssl x509 -req -in svc.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 825 -out svc.crt -extfile <(printf 'subjectAltName=DNS:svc.internal,DNS:*.svc.internal')落地要点
| 要点 | 做法 | 风险 |
|---|---|---|
| 备用名称 | 显式列出域名与通配符 | 缺了会被判定域名不匹配 |
| 根私钥保管 | 离线或放在受限环境 | 泄露等于整套内部信任被攻破 |
| 有效期 | 按轮换能力设置 | 过长会拖慢密钥轮换 |
| 信任分发 | 只把根装进客户端 | 给每台机器装独立证书不可维护 |
测试环境可用一键生成工具完成本地根的安装；生产内网建议使用自动化签发方案处理签发与轮换，减少手工操作带来的过期事故。
自签证书的备用名称必须显式配置：只用通用名的新客户端会判定域名不匹配，这类问题在测试环境常被长期忽略，直到换到真实客户端才暴露。
根证书本身的有效期要长于所签发的服务证书，否则会出现「根先过期、服务证书还在有效期」的尴尬局面，且更换根会牵动所有终端。