SSL握手失败:使用kubernetes和postman使用SubjectDN的签名者

Question

我的吊舱里有这个错误，我已经做了两天的研究，试图修复这个错误，但是我仍然找不出出了什么问题。

SSL握手失败:从主机CN=cluster.us-south.containers.appdomain.cloud发送了一个带有SubjectDN CWPKI0823E的签名者。签名者可能需要添加到位于SSL配置别名/opt/ibm/wlp/usr/servers/defaultServer/keycopy.jks，中的本地信任存储defaultSSLSettings。来自SSL握手异常的扩展错误消息是:无法找到指向请求目标的有效证书路径。

1. ，我在用本地机器创建的keycopy.jks上添加了一个自签名证书。但我也收到了同样的错误。
2. 试图关闭“启用ssl验证”以关闭和添加相同的错误
3. ，并添加信息，我在设置>认证>添加证书中添加了我在邮递员中创建的证书。
4. ，我尝试从keycopy.jks文件本身提取一个证书，并将它添加到我的postmand请求中，但我仍然有相同的错误。

Answer 1

我不是专家，但最近使用过SSL/TLS，并且发现SSL握手失败通常发生在与主机名(CN)不匹配的情况下。

您为某些CN域创建了一个证书--例如，example.com

• you然后尝试通过从服务器返回的localhost:8080

• the证书访问服务，localhost:8080

• the证书用于example.com而不是localhost。握手失败，没有建立

连接。

由于您正在获得一个证书，其中指定的主机名/CN为CN=cluster.us-south.containers.appdomain.cloud，但日志显示的是不同的域cloud.xxxx.container，因此连接失败--您的浏览器/ssl手握器正在试图验证主机是否是他们所称的主机，并得到了错误的结果--所以失败是正确的。

如果您能够将证书替换为拥有CN=cloud.xxxx.container，则很可能会成功地形成连接。

不确定下面的内容是否有效，但测试非常快速/容易(过去，我的example.com和localhost示例也是如此，所以我将提到它，尽管它可能不像预期的那样工作(用于测试目的)：

在/etc/hosts文件中创建一个条目：

cluster.us-south.containers.appdomain.cloud   cloud.xxxx.container

这将导致浏览器将cluster.us-south.containers.appdomain.cloud请求重定向到cloud.xxxx.container，而不更改浏览器中的url。这可能使SSL握手成功。试试看，如果成功了就告诉我们。

Answer 2

我的同事解决了这个问题。问题在server.xml中，他修改了server.xml文件，将keyStore id从"defaultTrustStore“更改为"defaultKeyStore”。

还可以参考以下内容：https://www.ibm.com/docs/en/was-liberty/core?topic=liberty-ssl-defaults-in

声明"Keystore:在默认配置中，defaultKeyStore同时用作密钥和信任库“