Elasticsearch自定义TLS证书配置指南，替换默认证书提升集群安全性
本文详解如何为自行管理的 Elastic Stack 集群替换默认 TLS 证书，涵盖传输层、HTTP 层、Kibana 与 Fleet Server 的完整证书配置流程，适用于需满足企业级安全合规要...
在企业级日志分析与搜索平台中，Elasticsearch 作为核心组件，其通信安全直接关系到数据完整性与访问控制。默认安装的 Elastic Stack 会自动生成一套临时证书用于节点间传输（transport）和 HTTP API 层加密，但这些自签名证书不具备长期可信性，无法满足等保、ISO 27001 或金融行业对证书链可追溯性的硬性要求。因此，将默认证书替换为由组织自有证书颁发机构（CA）签发的 TLS 证书，成为高安全等级部署的必要步骤。
这一过程并非简单替换文件，而是一套涉及 PKI 架构设计、证书生成、分发与服务重载的系统性操作。根据官方技术文档，整个流程可分为四大模块：Elasticsearch 传输层 TLS、Elasticsearch HTTP 层 TLS、Kibana 安全集成，以及 Fleet Server 与 Elastic Agent 的端到端证书配置。
首先，传输层 TLS 用于保障集群内节点间的通信安全。默认情况下，Elasticsearch 使用 transport.p12 密钥库进行节点认证与加密。要实现自定义，需先创建一个专用 CA（例如使用 OpenSSL 或 HashiCorp Vault），再为每个节点生成包含公钥、私钥及 CA 签名链的证书。关键在于确保所有节点使用同一 CA 签发的证书，并在 elasticsearch.yml 中明确指定 xpack.security.transport.ssl 相关参数，如 certificate, key, certificate_authorities。完成配置后，需执行滚动重启——逐个节点停止、更新证书、重启，避免集群脑裂。
其次，HTTP 层 TLS 保护客户端（如 Kibana、Logstash 或外部应用）与 Elasticsearch 的 API 交互。该层通常使用 http_ca.crt 和 http.p12 文件，默认由快速入门脚本生成。自定义时建议为整个 Elastic Stack 建立统一的 HTTP CA，而非为每个服务单独签发，以简化信任链管理。Elasticsearch 节点需配置 xpack.security.http.ssl 参数组，并确保 Kibana 的 elasticsearch.ssl.certificateAuthorities 指向该 CA 公钥。值得注意的是，此阶段不涉及双向 TLS（mTLS），若需客户端证书认证，须额外启用 client_authentication 并配置对应策略。
第三部分聚焦 Kibana 的安全加固。Kibana 作为可视化入口，其自身也需 HTTPS 访问支持。配置逻辑分为两步：一是为其生成独立的服务端证书（可复用前述 HTTP CA 或新建），二是修改 kibana.yml 中的 server.ssl 设置，包括 enabled: true、certificate、key 及 certificateAuthorities。重启后，浏览器访问将显示有效锁图标，且 Kibana 内部调用 Elasticsearch 时能自动验证对方证书链。若跳过此步，即便 Elasticsearch 启用 HTTPS，Kibana 仍可能因证书不匹配而连接失败。
最后是现代可观测性架构的关键环节：Fleet Server 与 Elastic Agent。Fleet Server 作为集中式代理注册中心，其与 Agent 之间的通信默认使用自签名证书。在生产环境中，必须将其替换为组织可控的证书体系。具体操作包括：在安装 Fleet Server 时通过 --cert 和 --key 参数传入自定义证书；Agent 注册时通过 fleet.elastic_agent.tls.certificate_authorities 指定信任的 CA；部署完成后可通过 GET /_nodes/stats 或 Fleet UI 查看 Agent 连接状态与证书信息。此举不仅提升传输安全性，也为后续审计与合规报告提供可验证依据。
整个配置过程预计耗时约 90 分钟，前提是已具备基础集群环境——即已完成《安装自行管理的 Elastic Stack》教程中的本地部署，且各节点 /etc/elasticsearch/certs/ 下存在 http_ca.crt、http.p12 与 transport.p12 等默认证书文件。实际操作中需特别注意权限控制：证书文件应归属 root:elasticsearch 组，权限设为 640，防止私钥泄露；密钥库密码应通过 elasticsearch-keystore 管理，而非明文写入配置。
从运维角度看，自定义 TLS 证书虽增加初期配置复杂度，却显著降低长期风险。一方面避免因默认证书过期导致服务中断（默认证书有效期仅 1 年）；另一方面满足 SOC 2、GDPR 等法规对“加密通信可审计”的要求。尤其在混合云或跨区域部署中，统一 CA 策略还能简化证书轮换与吊销流程。
值得补充的是，Elastic 官方推荐使用 certutil 工具辅助生成证书，该工具内置了符合 Elastic Stack 证书规范的模板（如 SAN 扩展、密钥用法限制），比纯 OpenSSL 手动配置更可靠。此外，随着 Elastic Agent 的普及，越来越多企业将日志采集、指标监控与 APM 统一纳入 Fleet 管理，此时端到端 TLS 成为保障整个可观测性管道安全的基石。
综上，自定义 TLS 证书不是一次性的“安全补丁”，而是构建可信数据基础设施的必经路径。对于需要长期稳定运行、接受第三方审计或对接政府监管系统的用户而言，掌握这套配置方法具有现实必要性。
