我希望通过在客户服务和我们的服务之间设置相互 TLS 来扩大我们应用程序内的信任。我正在尝试理解这些东西，因为我对这项技术还不太熟悉，所以想确认我的方法。
我正在考虑向客户索要他们的域验证证书。然后我将使用我们自己的中间 CA（AWS 私有 CA）对其进行交叉签名，并生成他们将用于请求的叶证书。
在与我们的服务器握手时，我想验证他们是否是允许与我们的服务交互的公司/域（验证他们的 DV 证书）。此外，由于我与我们的 CA 进行了交叉签名，因此我可以根据需要撤销他们的访问权限。所以基本上我会验证这两件事。
对于这种事情，这是最佳实践吗？证书到期后，客户是否每年都需要向我提供新证书？使用我的中间 CA 交叉签署他们的 DV 证书会遇到问题吗？
额外的信息：
我希望实时设置可信加密会话。因此我希望客户端（即客户服务器）向我们的服务发送证书（我们提供）。
我正在尝试建立一个信任网络，在其中我可以接纳新用户并确保他们是受信任的实体（因此有 DV 证书部分）
也许我没有自己的私人CA，而是使用商业CA。
答案1
证书只能有一个签名，这意味着不能像这里建议的那样在此级别添加另一个信任链。交叉签名是指拥有多个共享相同公钥（因此也共享相同私钥）的颁发者证书，从而允许不同的信任链。这通常在将信任从一个根 CA 转移到另一个根 CA 时完成。因此，这不是这里描述的用例，而且无论如何您都无法访问原始颁发者 CA 的密钥对，因此无法使用此密钥对您自己的证书进行交叉签名。
鉴于此处需要完全控制证书（包括撤销），看起来正确的方法是让您自己的根 CA 简单地为客户颁发客户端证书，并将其发送给客户以供使用。如果客户坚持使用自己的证书，则可以锁定这些证书或其中的公钥。
答案2
假设 DV 证书是由商业 CA（例如 Let's Encrypt）颁发的，并且您的系统具有相当最新的信任锚点存储（受信任的根 CA 证书集合），那么您已经信任他们的 DV 证书。您信任根 CA，因此您隐式信任由根 CA 及其任何下属 CA 颁发的所有证书。这是相互认证的前半部分 - 服务器认证。这与浏览任何网站（例如 ServerFault）没有什么不同，您的客户端（浏览器）信任服务器发送的证书，该证书由商业 CA（在本例中为 Let's Encrypt）颁发给它。
对于另一半 - 客户端身份验证 - 您需要让他们信任证书由您呈现在相互 TLS 会话初始化期间。也就是说，您需要向您的系统颁发客户端身份验证证书，系统会将该证书提供给服务器以进行身份验证。
在服务器身份验证（上面第 1 段）和客户端身份验证（第 2 段）之间，现在有了相互身份验证。请记住，通过相互身份验证，您的终端会验证其服务器证书；而他们的终端会验证您的客户端证书 - 因此是相互的。
剩下的问题是如何向自己颁发客户信任的客户端证书。您有两个选择：
- 您需要由他们已经信任的 CA 向您颁发证书（根 CA 证书已在他们的信任锚存储中）；或者，
- 您需要让他们信任您的私人 CA（将您的根 CA 证书添加到他们的信任锚存储中）并从该 CA 为自己颁发证书 - 但是，如果他们对其组织内的 PKI 进行严格管理，那么添加您的根 CA 证书可能是一个挑战。
您不能对相互 TLS 进行交叉签名 - 交叉签名用于不同的目的。