尽管Netty 4.1.36和jdk 11中的证书不正确，但握手成功

Question

我有客户端和服务器配置使用TLS和自签名证书。

客户端SSL引擎配置为使用虚拟信任管理器，该管理器从不抛出CertificateException和空KeyManager数组。

服务器SSL引擎使用由手动生成的密钥存储文件初始化的密钥存储。

当我用JDK 8运行它时，我得到以下握手结果：

• 服务器无法验证证书

这是预期的行为。

当我使用JDK 11运行它时，我得到以下结果：

• 服务器失败与相同的错误（空证书链），但在客户端线程我看到以下：
• io.netty.handler.ssl.SslHandler#setHandshake成功被称为first
• io.netty.handler.ssl.SslHandler#setHandshakeFailure在
之后调用

我是TLS 1.3的新手，可能会在配置中错过一些东西。同时留档说java TLS API客户端切换到TLS 1.3没有什么需要更新的。

这种行为令人困惑，它进一步破坏了基于握手协议的逻辑。

可以通过gist link获得重现该问题的完整代码：https://gist.github.com/kiturutin/ccb710f67ccfb0a7a7de1fb3b3099b60

这是一个很棒的脚本，它首先启动服务器，然后启动客户端。




Answer 1

明确地说，您的服务器请求客户端认证，并且客户端证书的服务器验证失败，因为客户端配置没有密钥管理器，因此没有发送证书？（然而，服务器发送了自己的“手册”证书，客户端因为虚拟信任管理器而接受了它。）

如果是这样的话，这看起来像是码头的一个类似问题（？）请参阅中的第五篇文章https://github.com/eclipse/jetty.project/issues/2711--在我看来，这是因为TLS 1.3客户端在发送时认为握手已完成（因为1.3将服务器移到第一个航班），而这是在收到客户端身份验证失败的服务器警报之前。（而在1.2及更早版本中，服务器完成了，可能是票证基本上是第二次飞行，导致客户端第一个应用程序协议（如HTTP）的额外RTT。）

如果使用，它也是在接收服务器NewSessionTicket（针对1.3“恢复”进行了修改）之前；请参阅OpenJDK 11问题-客户端在上次展开之前完成握手。

我想对于1.3来说，您必须在“成功”之后接受“失败”，除非Java人员能够想出一些真正聪明的解决方案。