2路TLS和CA签名证书

时间:2018-07-11 23:14:02

标签: java security ssl tls1.2

我的任务是在Java上下文中实现2路TLS。我找到了一个示例(https://www.opencodez.com/java/implement-2-way-authentication-using-ssl.htm),并亲自将其组合为一个演示。就像这个示例一样,我在网上可以找到的所有其他示例都使用自签名证书。但是现在问题来了,如果我们使用第三方CA签名证书怎么办。它将如何影响本演示?另外,请考虑以下两种情况:

  1. 在服务器端,我只关心客户端是否已通过CA认证。例如,服务器以前不知道的全新客户端,只要它可以通过CA获得证书,服务器就会提供服务;
  2. 这是点对点关系,不仅客户端需要出示由CA颁发的证书,服务器还将检查证书,以查看客户端是否在符合资格的实体的预定义实体列表中;

那么我应该如何分别为以上两种不同的方案配置密钥库和信任库?

2 个答案:

答案 0 :(得分:3)

与CA签名证书在两端的区别在于,除非JRE的内置信任库不知道CA,否则您不需要从密钥库中导出任何内容并导入到信任库中,也不需要您自己的自定义信任库。在每种情况下,您只需要将您自己的CSR生成的CA的捆绑软件和CA签名的证书导入到您自己的密钥库中即可。

  

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

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

答案 1 :(得分:1)

在客户端和服务器的任一端,您都需要该端的密钥库。那真的只需要证书和私钥。

然后,每一方都需要对方的信任根,但不需要自己的信任根。服务器需要客户端的根CA,反之亦然(除非您忽略客户端上的服务器证书验证)。根将位于信任库中。

然后,最重要的是,每一侧都需要另一侧的任何中间CA。他们可以在信任库中拥有它们,或者可以从另一端接收它们。

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

因此服务器需要客户端的根CA,并且会提前需要任何中间的CA证书,或者从客户端接收它们。

更新:响应下面的评论,如果要过滤客户端证书,则可能在某些TLS实现中(例如,openssl)。您可以进入验证步骤,并对是否允许连接发表意见。这看起来有点低级,但是确实有一些优势。例如,您可以在文本文件中保留所有允许的客户端证书的串联(仅公共证书,而不是任何私钥),并在启动时将其读入openssl“证书堆栈”,然后遍历该外观每个TLS连接上的匹配项。那是一个非常具体的客户白名单。

我会提醒您不要简单地检查DN是否有模式来确定是否允许客户端,因为这可能是一个很大的安全漏洞。攻击者只需从任何著名的CA 获得公开证书,并索取适合您所寻找模式的DN。这将被您的服务器接受,因为CA是典型默认信任库上的数百个受信任CA之一。接受连接后,DN将符合预期的模式,因此允许客户端。

相关问题