ES集群不识别节点SSL证书的问题处理

问题描述

在启动ES服务并试图加入其他节点上已启动的集群时，出现报错(原文是一大段话，我按语义拆成了几段)：

[2024-03-19T16:32:02,844][WARN ][o.e.c.s.DiagnosticTrustManager] [node-2-master] failed to establish trust with server at [<unknown host>]; the server provided a certificate with subject name [CN=workerxx], fingerprint [85e5xxx], no keyUsage and extendedKeyUsage [serverAuth];

the certificate is valid between [2024-03-19T02:34:51Z] and [2026-03-19T02:34:51Z] (current time is [2024-03-19T08:32:02.843439860Z], certificate dates are valid);

the session uses cipher suite [TLS_AES_256_GCM_SHA384] and protocol [TLSv1.3]; the certificate has subject alternative names [DNS:localhost,IP:fe80:0:0:0:xxxx:xx:dfc5:1816,IP:192.xx.xx.xxx,IP:0:0:0:0:0:0:0:1,IP:127.0.0.1,IP:fe80:0:0:0:503:d573:42c0:8add,IP:10.xx.xx.xx,DNS:workerxx];

the certificate is issued by [CN=Elasticsearch security auto-configuration HTTP CA]; the certificate is signed by (subject [CN=Elasticsearch security auto-configuration HTTP CA] fingerprint [0439xxx]) which is self-issued;

the [CN=Elasticsearch security auto-configuration HTTP CA] certificate is not trusted in this ssl context ([xpack.security.transport.ssl (with trust configuration: StoreTrustConfig{path=certs/transport.p12, password=<non-empty>, type=PKCS12, algorithm=PKIX})]);

这段日志警告来自Elasticsearch节点node-2-node2，显示它未能与服务器建立信任连接，具体服务器地址为<unknown host>。服务器提供的证书包含如下信息：

• 主题名称：CN=workerxx
• 指纹
• 该证书没有指定keyUsage和extendedKeyUsage的serverAuth属性
• 证书日期有效
• 会话使用的加密套件：TLS_AES_256_GCM_SHA384，协议：TLSv1.3
• 证书包含了多个主题备用名称（Subject Alternative Names, SANs），包括localhost和其他几个IP地址以及DNS名称workerxx
• 证书由名为CN=Elasticsearch security auto-configuration HTTP CA的机构颁发
• 签名证书同样是自签发的（self-issued）

问题分析

日志显示，在Elasticsearch节点node-2-master上出现了SSL握手失败的情况，原因是该节点未能与目标服务器建立信任关系。具体错误是：

当前Elasticsearch节点的SSL上下文(xpack.security.transport.ssl)信任的证书主体也是CN=Elasticsearch security auto-configuration HTTP CA，但已信任的证书指纹与服务器提供的不一致，造成信任链校验失败。

为了解决这个问题，需要采取以下步骤：

1. 确认节点node-2-master上的SSL配置文件（在这个例子中是certs/transport.p12）是否包含正确的、应该被信任的证书及其链。目前，节点信任的证书指纹是c7bd...，而服务器提供的证书指纹是85e5...。

2. 更新Elasticsearch节点上的信任证书存储以包含正确的CA证书和服务器证书，确保它们能形成有效的信任链。

3. 检查并确保所有节点间通信使用的都是同一个信任根CA，并且证书链完整无误。

4. 对于Elasticsearch的安全性配置，尤其是xpack.security.transport.ssl的部分，应确保所有的节点都有相同且正确的信任设置。

但是，这些证书都是自动生成且直接拷贝到其他节点的，并未进行任何修改。并且还有一个现象就是，与master在同一台机器上的ES实例与其通信时是正常的，不过这也可以推测相同机器用的是本地回环地址进行的通信，故信任链在证书中是生效的。

排查与解决

指纹相关？

尝试使用ssh登录远程节点，并记录远程节点的指纹（询问时回答yes），再次尝试无效。

hosts文件记录错误？

由于我的机器是由两个不同网段接通的，一个千兆，一个万兆，故将本地的/etc/hosts文件中的改为配置文件中填写的千兆IP地址，报错相同。

证书文件损坏？

由于本机器的文件都是从其他节点拷贝来的，可能出现损坏，故重新检查和拷贝一遍后问题依然存在。

重新生成ssl证书并分发？

我重新解压开一个编译包，让它自动生成一份http、Transport的p12证书，然后覆盖到所有需要的节点，结果本地节点仍然可以正常启动组成集群，但是另一个机器还是无法通过信任链校验，无法通信，至此，问题有点陷入僵局的意思。

采用token方案进行观察（解决）

翻看之前搭建集群的记录，似乎不能直接把证书拷贝过去使用。由于之前是采用的token的方案，没有过多配置，我先清空远程节点的discovery相关属性，使用token的方案加入集群观察一下。

主节点先生成token：

./bin/elasticsearch-create-enrollment-token -s node

使用指定token的方式加入集群非常顺利，几乎是秒过！

./bin/elasticsearch -d --enrollment-token eyJ2ZXIiOi...

执行上述命令后节点启动正常，并立即识别了远程master节点，顺利加入集群。

这种方案只修改了以下三个配置：

cluster.name: my-app-es
node.name: node-2-master
node.roles: [master,ingest]

需要注意的是，这个服务由于我指定的是master角色，所以没有指定任何端口。

data节点指定端口的尝试

前面新增了一个master角色，现在尝试增加一个data角色。

修改配置：

cluster.name: my-app-es
node.name: node-2-node1
node.roles: [ data, ingest ]
http.port: 9201
transport.port: 9301

之后启动命令与前述相同，节点也顺利加入了集群。

正常情况的总结

观察上述两个过程，启动前certs目录是没有的，启动后自动生成了证书，并且配置自动修改好，显然这个证书就是本地可用的。

拷贝证书再测试

# 从node1拷贝证书到node2，覆盖node2
cp -r node1/config/certs/ node2/config/
cp  node1/config/elasticsearch.keystore node2/config

# 修改node2的配置，主要是增加发现信息，修改端口
cd node2/config/
vim config/elasticsearch.yml

rm -rf data/*
rm -rf logs/*

# 非token方式启动
./bin/elasticsearch -d

这样也是启动成功的，最终集群从3节点变成6个节点了（2主4数），如下图：

总结

所以，绕了一圈SSL证书仅需要在本地生成，踩这个坑主要是由于ES 8.x版本将证书生成进行了自动化（对用户透明了），所以忽略了这一点。这个举措本身是简化用户操作的，因此，建议使用指定token的方式组建集群，不要手动配置证书了。

另外，每个ES节点配置中的发现信息（discovery.seed_hosts）随着加入集群的顺序而改变，后加入的节点会自动添加前面已在集群内的节点信息，但是手动启动的不会自己变更。最后集群的节点配置各不相同，全部重启也不会同步该信息。