Kubernetes中CertificateSigningRequest.spec.usages值的含义及使用疑问

TLS客户端证书的三个核心用法 #

官方文档推荐TLS客户端证书设置digital signature、key encipherment、client auth三个用法，下面逐个拆解：

1. digital signature（数字签名） #

• 含义：允许证书对应的私钥对数据进行签名，公钥用于验证签名的真实性。
• 为什么需要：TLS握手阶段，客户端需要用私钥签名一段随机数据，证明自己拥有证书对应的私钥，以此完成身份验证。
• 不设置的影响：服务端无法验证客户端的身份合法性，证书无法用于TLS客户端认证场景，握手会失败。

2. key encipherment（密钥加密） #

• 含义：允许用证书的公钥加密对称密钥，只有对应的私钥能解密。
• 为什么需要：TLS握手时，服务端会生成一个临时的会话对称密钥，用客户端证书的公钥加密后发送给客户端，确保密钥在传输过程中不被窃取。
• 不设置的影响：无法安全传递会话密钥，要么通信只能用非对称加密（性能极差），要么密钥明文传输（完全不安全），导致TLS通信无法正常建立或存在严重安全隐患。

3. client auth（客户端认证） #

• 含义：这是一个扩展用法，明确表明该证书的用途是TLS客户端身份认证。
• 为什么需要：告诉证书颁发机构（CA）和服务端，这个证书是专门用来做客户端认证的，服务端会校验这个扩展字段，只有带有该用法的证书才会被当作客户端认证凭证。
• 不设置的影响：即使证书有签名和密钥加密能力，服务端也可能拒绝将其作为客户端认证证书使用，因为无法确认证书的预期用途。

其他可选用法的含义 #

除了上述三个，Kubernetes CSR支持的其他用法含义如下：

• signing：digital signature的别名，功能完全一致。
• content commitment：也叫不可否认性，用于证明数据的来源和完整性，防止发送方事后否认发送过该数据。
• key agreement：用于密钥协商协议（比如ECDH），双方通过交换公钥共同生成对称密钥，无需传输密钥本身。
• data encipherment：允许用公钥直接加密普通数据，TLS场景中很少使用，因为非对称加密性能远低于对称加密。
• cert sign：允许证书作为CA，用来签署其他下级证书。
• crl sign：允许证书签署证书吊销列表（CRL），用于声明哪些证书已被吊销。
• encipher only：仅用于密钥协商过程中的加密操作，通常和key agreement配合使用。
• decipher only：仅用于密钥协商过程中的解密操作，通常和key agreement配合使用。
• any：代表包含所有可用的证书用法，不建议在生产环境使用，会过度授权证书用途。
• server auth：用于TLS服务端认证，证明服务端的身份，是服务端证书的核心用法。
• code signing：用于签署可执行代码或脚本，证明代码未被篡改且来源可信。
• email protection / s/mime：用于加密和签名电子邮件，对应S/MIME协议。
• ipsec end system：用于IPSec协议中的终端系统身份认证。
• ipsec tunnel：用于IPSec协议中的隧道端点身份认证。
• ipsec user：用于IPSec协议中的用户身份认证。
• timestamping：用于签署时间戳，证明某条数据在某个时间点已经存在。
• ocsp signing：用于签署在线证书状态协议（OCSP）的响应，提供证书实时状态查询服务。
• microsoft sgc / netscape sgc：旧版浏览器的特殊扩展，用于兼容早期的服务器网关加密（SGC）功能，现在已基本被淘汰。

内容的提问来源于stack exchange，提问作者Moritz Wolff