交叉签名是什么
新根 CA 刚上线时未必进入所有客户端与操作系统的信任库，常见过渡做法是用仍被广泛信任的旧根，为同一个密钥再签一份中间证书，这就是交叉签名。于是同一张中间证书存在两条验证路径：一条经旧根，一条经新根，新旧客户端各自走能走通的那条。等新根普及到目标客户端后，再逐步停用交叉签名路径。
基本信息
| 原理 | 同一中间证书公钥被两个不同根分别签名，形成两条验证路径 |
|---|---|
| 使用方式 | 链中同时携带两条路径，客户端择一验证 |
| 过渡目标 | 新根普及后停止使用交叉签名 |
| 辨认特征 | 同一主体出现签发者不同的多张中间证书，或被签的密钥 SPKI 相同 |
| 验证依据 | RFC 5280 的多路径构建规则 |
典型使用场景
- 新根上线过渡：公共 CA 更换根证书后，让老客户端继续可用。
- 收购与合并：合并后的 CA 体系需要一个过渡期统一信任链。
- 排障定位：客户端报链不完整时，确认是否走了未被信任的那条路径。
- 证书链优化：携带两条路径会让握手字节数上升，需要按客户端分布取舍。
- 私有 PKI 例外判断：自建体系一般不需要交叉签名，不要照搬公共 CA 做法。
辨认交叉签名
辨认交叉签名
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>&1 | grep -E 's:|i:' | head -10
# 逐张导出链上证书，比对同一主体的签发者是否不同
# openssl s_client -connect example.com:443 -showcerts </dev/null 2>&1 | awk '/BEGIN CERT/{n++} n' | csplit - '/END CERTIFICATE/' '{*}' >/dev/null
# 检查被签证书的公钥指纹是否一致：一致即同一密钥被两条路径覆盖路径与客户端匹配
| 客户端情况 | 可用路径 | 处理 |
|---|---|---|
| 信任库含新根 | 新根路径 | 正常校验，无需处理 |
| 信任库只含旧根 | 旧根路径 | 依赖交叉签名维持可用 |
| 两条路径都不可用 | 无 | 确认链是否完整携带、顺序是否正确 |
| 客户端不支持多链 | 取首条有效路径 | 确认链顺序把最兼容的路径放前面 |
交叉签名更常出现在公共 CA 更替与并购场景，自建 PKI 很少用到；内网场景更实际的替代做法是把根证书提前下发到终端信任库。