交叉签署第三方DV证书与我们自己的CA为高度信任
我希望通过在客户服务和我们的服务之间建立相互的TLS来扩大我们应用程序中的信任。我正试图把我的头围绕着这些东西，因为我对这项技术有点陌生，所以我想确认一下我的方法。
我正在考虑向客户索取他们的域验证证书.然后，我将交叉签署它与我们自己的中间CA (AWS私有CA)，并生成一个叶证书，他们将用于请求。
在与我们的服务器握手时，我希望验证他们是一个允许与我们的服务交互的公司/域(验证他们的DV证书)。此外，由于我交叉签名与我们的CA，我可以撤销他们的访问，如果需要。基本上，我验证了这两件事。
这是这类事情的最佳实践吗？客户是否需要每年在证书到期时向我提供一份新的证书？我是否会有任何问题，交叉签署他们的DV证书与我的中间CA？
附加信息：
我想要一个可信的加密会话的实时设置。因此，我希望客户端(将是客户服务器)向我们的服务发送一个证书(我们提供的)。
我正在努力建立一个信任网络，在这个网络中，我可以在新用户上工作，并确保他们是受信任的实体(因此是DV证书部分)。
也许我没有自己的私人CA，取而代之的是使用商业CA。
回答 2
Server Fault用户
发布于 2022-07-10 20:00:13
假设DV证书是由一个商业CA (例如，我们加密)颁发的，并且您的系统有一个合理的最新信任锚存储(可信根CA证书的集合)，那么您已经信任他们的DV证书了。您信任根CA，因此您隐式地信任根CA和根的任何下属CA颁发的所有证书。这是相互身份验证完成的前半部分--服务器身份验证。这与浏览任何网站(如ServerFault )没有什么不同，您的客户端(浏览器)信任服务器发送的证书，该证书是由一个商业CA颁发的(在本例中，让我们加密一下)。
对于另一半--客户端身份验证--您需要让他们信任由您在相互TLS会话初始化期间提交的证书。也就是说，您需要向您的系统颁发客户端身份验证证书，该证书将呈现给服务器以进行身份验证。
在服务器身份验证(上文第1段)和客户端身份验证(第2段)之间，您现在有了相互身份验证。请记住，通过相互身份验证，您的终端将验证它们的服务器证书；而它们将验证您的客户端证书--因此是相互的。
剩下的问题是如何向自己颁发客户将信任的客户证书。你有两个选择：
- 或者您需要由他们已经信任的CA颁发给自己的证书(根CA证书已经在他们的信任锚存储中)；或者，
- 您需要让他们信任您的私有CA (将您的根CA证书添加到他们的信任-锚存储区)，并从该CA为自己颁发证书--但是，如果他们在其组织中拥有严格的PKI治理，那么获得您的根CA证书可能是一个挑战。
您不能交叉签署为相互TLS -交叉签署是为了不同的目的。
Server Fault用户
发布于 2022-07-10 20:00:55
证书只能有一个签名，这意味着不能像这里建议的那样在这个级别添加另一个信任链。交叉签名则是拥有多个颁发者证书，它们共享相同的公钥(从而共享相同的私钥)，从而允许不同的信任链。这通常是在将信任从一个根CA转换到另一个根CA时完成的。因此，这不是这里描述的那种用例，而且您也无法访问原始颁发机构CA的密钥对，以便使用此密钥与您自己的证书交叉签名。
考虑到这里对证书的完全控制(包括撤销)，似乎正确的方法是让您自己的根CA为客户颁发客户端证书，并将这些证书发送给客户使用。如果客户坚持使用自己的证书，则可以将其钉在这些证书或其中的公钥上。
https://serverfault.com/questions/1105234
复制相似问题
腾讯云开发者
