Java 具有CA签名证书的双向TLS

我的任务是在Java环境中实现双向TLS。我找到了一个示例（），并能够自己将其作为一个演示放在一起。就像这个例子一样，我在网上找到的所有其他例子都使用自签名证书。但现在的问题是，如果我们使用第三方CA签名证书会怎么样。它将如何影响这个演示？并请考虑这2种情况：

在服务器端，我只关心客户端是否通过CA认证。例如，服务器以前不知道的全新客户端，只要它可以通过CA获得证书，那么服务器将提供服务

它是一种点对点关系，不仅客户端需要提供CA颁发的证书，服务器还将检查证书，以查看客户端是否在预定义的实体列表中，从而有资格获得服务

---

那么，对于上述两种不同的场景，我应该如何分别配置密钥库和信任库呢

无论是在客户端还是服务器端，您都需要该端的密钥库。这实际上只需要证书和私钥

然后，双方都需要对方的信任根，但不需要自己的信任根。服务器需要客户端的根CA，反之亦然（除非忽略客户端上的服务器证书验证）。根目录将位于信任库中

除此之外，每一方都需要另一方的任何中间CA。他们可以已经将它们放在信任库中，也可以从另一方接收它们

因此，出于礼貌，双方还可以包括自己的中间CA证书，并将其发送到链中以帮助另一方。否则，双方实际上都不需要自己的CA或中间CA证书

因此，服务器需要客户端的根CA，并且需要提前获得任何中间CA证书，或者从客户端接收证书

更新：响应下面的评论，如果您想过滤客户端证书，在某些TLS实现中（例如openssl）是可能的。您可以连接到验证步骤，并对是否允许连接发表意见。这似乎有点低级，但它确实有一些优势。例如，您可以在一个文本文件中保存所有允许的客户机证书的连接（只有公共证书，而不是任何私钥），并在启动时将其读入openssl“证书堆栈”，然后在每个TLS连接上运行以查找匹配项。这是一个非常具体的客户白名单

---

我要提醒大家，不要简单地检查DN以确定是否允许客户端，因为这可能是一个很大的安全漏洞。攻击者只需从任何知名CA获取公共证书，请求符合您所寻找模式的DN即可。这将被您的服务器接受，因为CA是典型默认信任库上数百个受信任CA中的一个。一旦连接被接受，DN符合预期模式，因此允许使用客户端。

与两端CA签名证书的区别在于，除非JRE的内置信任库不知道CA，否则不需要从密钥库导出并导入信任库，您不需要自己定制的信任库。在每种情况下，您只需要将CA包和由您自己的CSR生成的CA签名证书导入到您自己的密钥库中

服务器还将检查证书，以查看客户端是否在预定义的实体列表中，以符合服务的条件

---

正如您在问题中所说，这是服务器应用程序在连接完成后必须执行的授权步骤。它不是密钥库/信任库设置的一部分，该设置仅与身份验证有关。不要把这些步骤混在一起。服务器（或其前面的Apache HTTPD）将检查证书的主题DN，以查看该DN是否具有使用请求的服务（例如URL）的适当角色。这可以内置到Apache HTTPD或Tomcat CMA中。

可能与well重复，您似乎只是在描述双向TLS的一般机制。我真正想问的是使用自签名证书和第三方CA签名证书之间的区别，特别是在设置密钥库和信任库的上下文中。哦，我明白了。我想@EJP有你的答案了。开箱即用，在大多数平台上，您已经在机器上拥有了一个信任库，并预装了数百个信任根。所以服务器可能根本不需要客户端的任何东西。当然，@EJP回答了我的部分问题。此外，如果服务器只向某个客户机A提供服务，比如说，CA认证客户机A、B和C，并且所有客户机A、B和C都请求服务器提供服务，该怎么办。服务器识别所有客户端提供的CA颁发的证书。但是，一旦服务器读入证书的内容，它只向A提供服务，而不是B和C。因为此服务仅为A设置。那么，对于此场景，如何在两侧设置密钥库和信任库？谢谢，然后在我描述的情况下，公平地说，我最好使用自签名证书，而不是CA签名证书。因为我不需要做额外的“授权”步骤，交易伙伴和我自己也不需要花钱从第三方CA购买证书。我认为使用自签名证书再好不过了。它们令人头痛，因为在自签名证书的所有者和每个对等方都需要额外的步骤。您确实需要执行额外的授权步骤，这就是我回答的要点。