SSL/TLS客户端是否正确响应没有DNS的证书请求消息？
当SSL/TLS客户端接收到具有空DN列表的证书请求消息时，它的正确行为是什么？
这里有两种看起来很自然的可能性：1）发回一个空的证书消息2）从所有可能的证书中选择（或提示用户选择）一个证书
是否有一个正确的行为，或者任一个选项都可以？我的目标是在我的代码(.NET，WCF)中向服务器提供一个证书，并且我正在尝试确定是否需要在客户端进行更改以覆盖不发送证书的看似默认的行为，或者是否需要在服务器端进行更改以实际发送DN列表。
浏览器似乎会选择选项2，但我使用WCF和.NET的代码使用的是选项1。我可以从存储中选择证书，但它不是在TLS握手中发送的。
TLS 1.0和1.2规范（RFC 2246和5246）似乎没有提供任何关于这种情况的指导。
共有1个答案
这实际上是TLS 1.0规范和TLS 1.1/1.2不同的地方。
特别是，在TLS 1.1的第7.4.4节（证书请求）中增加了以下内容：
如果certificate_authorities列表为空，则客户端可以发送适当的ClientCertificateType的任何证书，除非存在相反的外部安排。
根据我的经验（至少在浏览器和Java/JSSE中），这在SSLv3和TLS1.0中也起作用，即使没有提到空列表。
仍然由实现自行选择要做什么（“[...]可能发送任何[...]”）。
在任何情况下，即使有一个非空的CA列表，当多个客户端证书与CA条件匹配时，也需要自动或通过UI做出选择。这也是依赖于实现的，并且可以根据框架进行定制。
-
我收到了一个新的密钥库。jks文件用于ssl连接，以替换旧的但仍在工作的。jks密钥库文件，但我收到了“意外握手消息：serve_hello”错误。我被告知要确保密钥库包含客户端证书，所以我使用keytool将其证书导出到pem文件，然后使用openssl检查目的。结果显示 证书用途：SSL客户端：否SSL客户端CA：否SSL服务器：是SSL服务器CA：否... 然而，当我应用相同的过程来检查旧的
-
我不知道我到底需要在哪里包含客户机证书。现在，我的第一个问题是我不信任服务器。我尝试使用默认的Java密钥库文件（cacerts），其中包含Thawte和Digicert，这些是我试图与之通信的服务器的根权限。我使用
-
我正在尝试创建一个基于网络的网络客户端。我根据网络站点中给出的示例编写了代码。但问题是，响应是由客户端处理程序处理的 我做的一件事是在HttpTarget中创建一个setResponse()方法 因此，基本上我想同步进行，即在HttpSnoopClient中发送一个请求(channel.writeandFlush(req))，然后等待，直到HttpSnoopCLientHandler收到响应 谁能
-
有人能帮我回答以下问题吗： 我有一个启用SSL的REST服务器和一个位于两台不同计算机上的REST客户端。两者都是用Spring Boot构建的。服务器将具有。p12或。pfx证书。
-
我知道10.254.0.1:443实际上提供来自主节点（端口6443上的api)(192.168.0.200)的证书，但如何解析，10.254.0.1提供其有效证书。 以下是clusterip API的描述:[root@master01 dns]#kubectl description service kubernetes namespace：default labels:component=ap