有什么理由我不应该同时颁发带有 TLS Web 服务器身份验证和 TLS Web 客户端身份验证的最终实体证书?
如果应该在 Web 服务器上进行身份验证的客户端证书也包含 TLS Web 服务器身份验证,会发生什么情况?
我应该签发 2 个不同的证书吗?一个仅使用 TLS Web 客户端身份验证,第二个仅使用 TLS Web 服务器身份验证?
最佳做法和您的经验是什么?
有什么理由我不应该同时颁发带有 TLS Web 服务器身份验证和 TLS Web 客户端身份验证的最终实体证书?
如果应该在 Web 服务器上进行身份验证的客户端证书也包含 TLS Web 服务器身份验证,会发生什么情况?
我应该签发 2 个不同的证书吗?一个仅使用 TLS Web 客户端身份验证,第二个仅使用 TLS Web 服务器身份验证?
最佳做法和您的经验是什么?
从规范的角度来看,RFC5280 对在同一证书上设置两个扩展密钥用法没有任何限制。
从安全的角度来看,使用与客户端(我猜是连接到其他服务)和服务器(用于接收连接)相同的证书进行 SSL 身份验证也没有加密/协议问题(据我所知/可以找到) )。因为如果你使用两个证书,两个证书也将存储在同一台服务器上,如果攻击者可以窃取一个证书,他可以窃取两个证书,在那里没有收益或损失。
但是,将它们分开也没有什么坏处,特别是如果您以后出于任何原因需要以可能影响其中一种用途的功能的方式更改证书特征(例如:更改 DN 以包含相关内容到可能破坏服务器身份验证的客户端身份验证)。
在这种情况下,我总是将两者分开,如果您在谈论私有 PKI,通常我也会使用不同的 CA 来发布它们。
首先是另一端如何检查另一端提供的证书是客户端还是服务器,就知道它来自扩展密钥使用
Not Critical
TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
如您所见,它是 NON Critical 扩展,因此证书可用性几乎不依赖于此扩展
它是施加限制的证书密钥使用扩展
Critical
Signing
Key Encipherment
没有“签名”字段的证书不能用于身份验证,因此不能用作服务器证书
同样,没有密钥加密的证书不能用于密钥交换目的,同样还有其他参数
低至评论。我意识到这一点,但在某些情况下仍然需要它,例如流行的 389/RH DS 上的 LDAP/TLS 复制。根据 Redhat Directory Server Guide V 11:
如果供应商的证书在 TLS 握手期间只能充当服务器证书而不能充当客户端,则通过基于证书的身份验证通过 TLS 配置的复制将失败。使用基于证书的身份验证的复制使用 Directory Server 的服务器证书对远程服务器进行身份验证。