我有一个代理服务器。客户端通过 HTTPS 连接到它，因此它需要服务器证书。代理服务器还会向其他后端服务器发出传出请求。其中一个后端服务器需要相互 TLS，因此我也需要一个“客户端”证书。
两种情况使用一个证书可以吗？这是常见做法吗，还是大多数人选择使用两个单独的证书？
答案1
这可以做到，但你可能不想这样做。
从技术上来说，TLS 证书可以同时用作服务器证书和客户端证书。例如，此网站的 TLS 证书的密钥用途就是以这种方式设置的。
但是需要客户端证书的服务器会这样做来验证客户端。因此，它会需要由特定证书颁发机构签名的特定证书。在这种情况下，您用于面向 Internet 的服务器的 TLS 证书可能不是您想要的，因为该服务器会发现限制其接受哪些客户端证书要困难得多。
该后端服务器的服务器管理员可以颁发正确的客户端证书，或者向您指出可以颁发证书的证书颁发机构。
答案2
两种情况使用一个证书可以吗？这是常见做法吗，还是大多数人选择使用两个单独的证书？
我有一个类似的情况，但不能使用相同的证书，因为：
- 后端应用程序需要人工账户的客户端证书（它对照预定义用户列表进行检查），该证书由我们的 CA 为用户验证
- 服务器可以使用的唯一证书是其自己的证书，且 cn 未列入白名单。
因此我们认为的解决方案是：
- 使用透明代理：发送到后端时欺骗 IP 地址，后端具有将所有数据包发送回代理的静态路由（因此它可以转发给真实用户）
- 允许使用机器证书，但将其配置为转发真实 cn。我认为这叫做代理协议。如果我们这样做，我们需要将白名单控制移到代理机器上（该机器可以看到真实证书，可以验证完整的 CA 并记录登录尝试）
- 使用代理证书动态生成有效的客户端证书
我更喜欢最后一个选项，因为它在计划任务的情况下很有用（它可以存储在代理或路径中的任何机器上）。我们的后端系统不支持它，所以我们不得不退回到解决方案 1。
我问了自己同样的问题，因为我很懒（所以重复使用证书可能不是一个好主意）而想要另一个证书。
我认为如果符合以下条件就可以：
- cn = 唯一的 fqdn（以及 SAN 中的服务名称），因为如果发生攻击，您可以知道哪台机器被感染了（如果您对同一个后端有多个代理）
- 该证书由您的内部 CA 或您信任的公共 CA 验证（该证书旨在共享以证明身份，因此我看不到任何反对指示）或使用自签名证书但固定在另一侧（后者在轮换证书时会导致更多的工作）
- 它用于直接的机器间通信（如果您有另一个代理，则需要再次重复该过程），因为它可以验证 SAN 中包含的 IP 和接收数据包的 IP，因此很难同时欺骗这两个。