Elasticsearch集群内部各节点之间的通信走的是transport层，默认是明文传输的。这意味着在网络中任何一个位置抓包，都能看到节点间交换的数据内容，包括索引文档、集群状态甚至安全凭证。对于生产环境来说，这是不可接受的风险。启用节点间加密的核心手段是在transport层配置TLS，本文将从证书生成、配置修改到集群滚动重启，完整走一遍配置流程。
为什么要开启节点间加密
很多团队在部署Elasticsearch时只关注了HTTP层的访问控制，认为只要API端口不对外暴露就足够安全了。但transport端口9300往往在集群内网中是互通的，一旦内网中有机器被攻陷，攻击者就可以直接连入集群，伪造节点加入集群，进而读取全量数据或者直接删除索引。官方文档也明确指出，未加密的集群等于把管理权完全暴露在网络上。
从Elasticsearch 7.x版本开始，如果集群启用了安全功能，会强制要求transport层必须配置TLS，否则节点无法启动。对于使用X-Pack安全功能的用户来说，节点间加密已经不再是可选项。除了防窃听，TLS还能做节点身份验证，只有持有合法证书的节点才能加入集群，这有效防止了恶意节点混入。
此外，节点间加密对性能的影响其实比想象中小。TLS握手只在节点建立连接时发生一次，后续的对称加密开销在现代CPU上通常只占整体资源的百分之一到百分之三。所以没有必要因为担心性能而放弃加密，这一点在官方的基准测试中也有体现。
生成CA证书和节点证书
Elasticsearch自带的elasticsearch-certutil工具可以完成整个证书体系搭建。第一步是生成CA：
bin/elasticsearch-certutil ca -out elastic-stack-ca.p12
执行过程中会要求设置CA密码，如果不想在配置文件里写密码，可以直接回车留空。第二步用这个CA给每个节点签发证书：
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 --out elastic-certificates.p12
生成的elastic-certificates.p12是一个PKCS#12格式的证书包，可以同时用于所有节点。如果是规模较大的集群，也可以用elasticsearch-certutil为每个节点单独生成包含节点IP和主机名信息的证书，通过--dns和--ip参数指定，这样能开启更严格的主机名验证。
把生成的证书文件复制到每个节点的config目录下，注意文件权限要收紧，建议属主设为运行Elasticsearch的用户，权限设为600。证书文件泄露等于整个加密体系作废，所以在分发过程中最好不要走明文ftp或者随意放置的共享目录。
修改配置并滚动重启集群
证书就位后，需要在每个节点的elasticsearch.yml中加入transport层的TLS配置：
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时设置了密码，还需要把密码写入keystore，避免明文出现在配置文件里：
bin/elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password bin/elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password
verification_mode这个参数值得多说几句。certificate模式只验证证书是否由可信CA签发，不校验主机名；full模式则同时校验主机名，安全性更高但要求证书中正确包含了节点的主机名或IP。如果证书是通用的一份多节点使用，certificate模式是常见选择。
配置修改完成后需要重启节点。对于正在运行的生产集群，务必采用滚动重启的方式：先禁用分片分配，逐个节点重启，等节点重新加入集群、状态恢复为green后再处理下一个节点。整个过程中集群始终可用：
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "primaries"
}
}全部节点重启完成并验证无误后，记得把分片分配策略改回all，否则副本分片不会恢复。
常见问题与验证方法
配置节点间加密后最常见的问题是节点无法互相发现，日志里通常会出现SSLHandshakeException或者connection reset之类的报错。排查思路是：先确认每个节点的证书文件路径和文件权限是否正确；再检查keystore中的密码是否和生成证书时设置的一致；最后确认集群中所有节点使用的是同一个CA签发的证书。任何一个节点的证书与其他节点不匹配，都会导致握手失败。
另一个容易忽略的点是客户端连接。Kibana、Logstash以及各类语言的客户端在transport协议直连场景下也需要配置相同的信任证书，否则同样握手失败。对于只走HTTP协议的客户端则不受影响，HTTP层的加密是单独通过xpack.security.http.ssl配置的，两套配置相互独立。
验证加密是否生效有几个简单办法。一是抓包对比：在transport端口上用tcpdump抓包，开启加密后抓到的内容应该是一堆无法解读的二进制数据；二是查看节点日志，启动时会看到已启用transport TLS的相关信息；三是通过_cluster/health和_nodes API确认所有节点都正常加入集群，分片分配状态正常。如果这些都通过了，说明节点间加密已经完整生效。
Elasticsearch节点间加密TLS证书配置修改时间：2026-09-08 11:47:51