客户端与服务器身份危机：为什么不应让一个证书承担两种角色

在 PKI 和 TLS 中，证书是证明身份的数字凭证。如果同一张凭证同时声明两种不同且高信任级别的身份，例如在单张证书中组合扩展密钥用法 (EKU) serverAuth 与 clientAuth，就会模糊安全边界。

虽然技术上可行，有时也方便，但这是一种重要的安全反模式。下面说明这种做法为何有风险，以及如何设计更安全的证书策略。

“全能型”证书：看似诱人的捷径

扩展密钥用法 (EKU) 是定义证书用途的 X.509 扩展。TLS 中最常见的两种 EKU 是：

• serverAuth (OID: 1.3.6.1.5.5.7.3.1)：授权证书用于验证服务器身份（例如 HTTPS 网站）。
• clientAuth (OID: 1.3.6.1.5.5.7.3.2)：授权证书用于验证客户端身份（例如 API 客户端、用户或服务）。

尤其在开发环境或遗留系统中，可能会看到包含两种 EKU 的证书：

openssl req -new -key device.key -out device.csr -addext "extendedKeyUsage = serverAuth, clientAuth"

这种做法的优点是简单：只需管理一张而不是两张证书。但这种便利会带来显著的安全代价。

核心问题：违反最小权限原则

最小权限原则 (PoLP) 要求每个实体（用户、系统或证书）只能获得执行其预定功能所需的权限，不能更多。

同时包含 serverAuth 和 clientAuth 的证书天然权限过多：

• 服务器负责监听并响应请求，不应拥有以经过身份验证的客户端身份主动发起请求的权限。
• 客户端负责向可信服务器发起请求，不应能够冒充服务器。

合并两种角色会模糊界限。如果攻击者攻破同时具有 clientAuth 权限的服务器证书，就可能用它向其他信任客户端证书的内部服务进行身份验证，并在网络中横向移动。

可以这样理解：银行金库（服务器）的万能钥匙不应同时打开其中所有的保管箱（客户端）。

技术和运维问题

1. 密钥用途不合适：服务器和客户端证书通常需要不同的 keyUsage 扩展。服务器可能需要 keyEncipherment（例如用于 RSA 密钥交换），客户端可能只需要 digitalSignature。组合证书可能会采用过于宽泛的密钥用途。

2. 生命周期管理复杂：如果开发人员离职后需要轮换证书，而这张证书同时用于关键服务器，轮换就会变成复杂且高风险的操作。

3. 审计与合规困难：一张证书承担多个角色，会增加确认用途、审查访问情况和限制泄露影响范围的难度。

正确做法：为每种用途创建专用证书

建议为每个角色使用独立、专门设计的证书。

服务器证书

服务器证书应只包含服务器身份验证 EKU 及该服务所需的密钥用途。例如：

openssl req -new -key server.key -out server.csr -subj "/CN=api.mycompany.com/O=MyOrg/OU=Server" -addext "extendedKeyUsage = serverAuth" -addext "keyUsage = digitalSignature, keyEncipherment"

客户端证书

客户端证书应包含客户端身份验证 EKU 及相应密钥用途。例如：

openssl req -new -key client.key -out client.csr -subj "/CN=backend-service-account/O=MyOrg/OU=Client" -addext "extendedKeyUsage = clientAuth" -addext "keyUsage = digitalSignature"

这种做法的优势

• 限制安全事件影响范围：服务器证书被攻破后，攻击者不能将其用于客户端身份验证。
• 精细控制：客户端和服务器证书可以分别撤销和轮换。
• 审计记录清晰：每张证书的用途都明确。
• 有利于合规：符合现代安全框架的要求。

是否存在可以合并的情况？

此类例外极少见，必须经过充分论证。

• 资源极其有限的嵌入式设备：某些 IoT 设备实际上只能存储一张证书，组合用途可能不得已而为之。仍须仔细评估风险并通过其他措施加以缓解。
• 内部服务网格代理：部分高级服务网格架构（如 Istio）使用证书在代理间执行 mTLS。在这种高度受控的专业环境中，网格控制平面可能管理同时用于两个角色的证书，而非由应用所有者自行配置。

对于99% 的场景——包括 Web 应用、API、微服务和服务帐户——正确做法都是使用独立证书。

结论：专用化是优点，不是缺陷

在安全领域，专用化是一种优势。正如不应使用根 CA 证书签署日常邮件，也不应使用同一张证书表示多个不同的机器身份。

为服务器和客户端身份验证使用专用证书，可以构建更具韧性、易于管理且更安全的系统，消除不必要的风险并遵循基础网络安全原则。PKI Trust Manager 可通过策略执行和规范的证书管理帮助避免不良实践。