集群环境
ES集群版本：v6.810和v7.13.4
加密参数配置：
xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12 xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12
通过配置文件看到，只针对集群中节点之间的通信进行了加密，而且是自签的CA。
生成证书为您的Elasticearch集群创建一个证书颁发机构。例如，使用elasticsearch-certutil ca命令：
bin/elasticsearch-certutil ca --days 36500
为群集中的每个节点生成证书和私钥。例如，使用elasticsearch-certutil cert 命令：
bin/elasticsearch-certutil cert --days 36500 --ca elastic-stack-ca.p12
发现过期
通过批量扫描集群信息，发现证书过期
GET /_ssl/certificates [ { "path" : "certs/elastic-certificates.p12", "format" : "PKCS12", "alias" : "instance", "subject_dn" : "CN=Elastic Certificate Tool Autogenerated CA", "serial_number" : "e365c63bf8050b2d1a73025c37aaa6d8d0772f06", "has_private_key" : false, "expiry" : "2023-04-26T09:13:27.000Z" }, { "path" : "certs/elastic-certificates.p12", "format" : "PKCS12", "alias" : "instance", "subject_dn" : "CN=instance", "serial_number" : "bff8e3ed43fcc2abc4e6951bd6064ed53ddb7b56", "has_private_key" : true, "expiry" : "2023-04-26T09:13:44.000Z" }, { "path" : "certs/elastic-certificates.p12", "format" : "PKCS12", "alias" : "ca", "subject_dn" : "CN=Elastic Certificate Tool Autogenerated CA", "serial_number" : "e365c63bf8050b2d1a73025c37aaa6d8d0772f06", "has_private_key" : false, "expiry" : "2023-04-26T09:13:27.000Z" } ]
参考因素
- 是否会导致节点间通信异常
- 是否需要重启节点，滚动重启还是全部停掉再启动
- 服务连接是否受影响，数据一致性是否有保障
解决方案 及问题
基于ES6.8.10-ARC(通用3节点集群) 验证测试
遇到问题：
- 将证书设置1天过期，过期之后查看，集群还是正常运行（各种方式查看新证书确实都生效了）
结论总结：
- 1. 批量下发证书，从各个节点日志可以看出，证书已更新
[2023-04-26T10:12:41,125][INFO ][o.e.x.c.s.SSLConfigurationReloader] [es_10.4.6.2_9211] reloaded [/work/idb/es9211/config/certs/elastic-certificates.p12] and updated ssl contexts using this file
- 2.集群中的某个节点，重启时，如果自己的证书和其他节点不一致，可以启动但是无法被其他节点识别，无法加入集群
[2023-04-25T15:43:25,272][WARN ][o.e.x.c.s.t.n.SecurityNetty4Transport] [es_10.4.6.2_9211] client did not trust this server's certificate, closing connection Netty4TcpChannel{localAddress=0.0.0.0/0.0.0.0:9311, remoteAddress=/10.4.6.9:36814}
- 直接替换证书，自动就被其他节点识别到，然后节点正常加入集群
查询命令：
- 查询证书过期
GET /_ssl/certificates
- 验证证书是否有效
curl -X GET "http://escluster111.es.zcinc.com:9211/_cluster/health?pretty" -uelastic:OWRmNjA5MDlkNGM3 --cacert elastic-certificates.p12
GET /_nodes?filter_path=**.transport.ssl
官网说明：
关于证书更新的文档，版本：>=7.13
如果使用相同的CA，签发新的证书，替换原来的文件，是不需要重启节点的
如果使用不同的CA，签发新的证书，替换原来的文件，是需要滚动重启的
这里有3个点需要注意：
- 没有小于<7.13的版本文档说明，但是我测试6.8.10，重启和不重启，都能查询到新的证书
- 测试6.8.10证书过期，集群依然可以正常使用，读写、新连接，都没有影响，具体原因不清楚
- 为了安全，还是批量替换证书，并滚动重启一遍
以下是官网文档说：
使用相同的CA：
https://www.elastic.co/guide/en/elasticsearch/reference/7.13/update-node-certs-same.html
使用不同的CA：
https://www.elastic.co/guide/en/elasticsearch/reference/7.13/update-node-certs-different.html
其他解决方案
除了证书原地更新，其它方案都是基于索引数据迁移
第一种：reindex
使用于: 小索引、索引数少
将索引迁移到新的集群，需要停写，将域名解析切到新集群
第二种：业务双写
提供新的集群，让业务双写，再合适的时间，直接切域名解析到新集群
第三种：snapshot
通过ES的快照备份，全量＋增量，时时备份增量到存储(共享存储:NFS/COS/OSS)，并做时时恢复到新集群，再合适的时间停服，切域名解析到新集群。
增量的备份和恢复，最小粒度可以设置1分钟
以上三种方案，都会涉及业务短暂的停写，需要针对不同场景选用合适的方案。
