关于ELA的公共CA证书、自签名CA证书和各组件实体证书

elasticsearch的配置文件中，tranport层和http层都是用的同一个实体证书，其他各组件也是用对应的实体证书比如logstash、xxx。而这些实体证书是由elasticsearch的bin目录下的certutil生成的ca证书来生成的各组件的实体证书。然后，如果外部想要访问Kibana的服务，则需要在Kibana的配置文件中的# kibana.yml 中外部访问的HTTPS配置（用户浏览器访问） server.ssl.enabled: true server.ssl.certificate: "certs/kibana-public.crt" # 公共CA证书 server.ssl.key: "certs/kibana-public.key" # 对应私钥 

然后内部通信还是# Kibana与ES内部通信的证书（仍用自签名CA） elasticsearch.ssl.certificateAuthorities: ["certs/elastic-ca.pem"]

 

1. 内部通信层（组件互信）：
   • 用 elasticsearch-certutil 生成 1 个自签名 CA 根证书（如 elastic-ca.p12），作为内部信任基准。
   • 基于该 CA 签发各组件的 实体证书（如 Elasticsearch 的 es-node.p12、Logstash 的 logstash-cert.pem、Filebeat 的 filebeat-cert.pem 等）。
   • Elasticsearch 的 transport 层（节点间通信）和 http 层（与 Kibana/Logstash 通信）可共用同一个实体证书（只要证书包含节点的 IP / 主机名）。
   • 所有组件的内部通信配置（如 Kibana 连接 ES、Logstash 连接 ES、Filebeat 连接 Logstash）均通过 信任自签名 CA 根证书（elastic-ca.pem）实现互信。
2. 外部访问层（用户 / 客户端信任）：
   • 若需外部用户通过浏览器访问 Kibana（如 https://kibana.yourdomain.com），则在 Kibana 的 server.ssl 中配置 公共 CA 签发的域名证书（如 Let's Encrypt 的 kibana-public.crt 和私钥），确保浏览器信任（不显示 “不安全” 提示）。
   • Kibana 与 Elasticsearch 的内部通信仍基于自签名 CA（elasticsearch.ssl.certificateAuthorities: ["elastic-ca.pem"]），与外部访问的证书体系完全隔离，互不干扰。

补充 2 个关键注意事项（避免踩坑）

1. 实体证书必须包含 “实际通信的主机信息”用 elasticsearch-certutil 生成实体证书时，务必在 “hostname” 中填写组件实际通信的 IP 或域名（如 Elasticsearch 节点的 IP 192.168.1.100、Kibana 的内部主机名 kibana-internal 等）。若证书中缺少实际使用的地址，会导致 SSL 验证失败（如 “hostname mismatch” 错误）。
2. 证书权限与路径
   • 所有证书文件需保证对应组件的进程有读取权限（如 Elasticsearch 用 elasticsearch 用户、Kibana 用 kibana 用户）。
   • 路径尽量使用绝对路径（如 /etc/elasticsearch/certs/elastic-ca.pem 而非相对路径），避免因组件启动目录不同导致证书找不到。“用 CA 根证书生成实体证书”（签发阶段） 和 “各组件信任 CA 根证书以验证实体证书”（验证阶段）。这两个过程都需要用到 CA 根证书，但用途完全不同，我们用一个比喻来解释：

   • 比喻：CA 根证书 = 公安局公章，实体证书 = 身份证

     • 公安局公章（CA 根证书）：是 “信任基准”，只有公安局能盖这个章，证明 “这个身份证是真的”。
     • 身份证（实体证书）：每个人（每个组件）都有自己的身份证，上面盖了公安局的公章（由 CA 根证书签发），证明 “我是谁”。

     两个核心过程的区别：

     1. 签发阶段：用 CA 根证书生成实体证书（“给身份证盖章”）

     当你用elasticsearch-certutil生成证书时：
     • 先创建 “公安局公章”（CA 根证书elastic-ca.p12，包含公章的 “私钥”—— 只有公安局能用来盖章）。
     • 然后用这个公章，给每个组件 “办身份证”（实体证书）：给 Elasticsearch 办一张（es-node.p12）、给 Kibana 办一张（kibana-cert.pem）、给 Logstash 办一张（logstash-cert.pem）…… 每张身份证上都盖了公安局的公章（由 CA 根证书的私钥签名）。
     这个阶段，CA 根证书的作用是 **“签发实体证书”**（盖章），实体证书是组件的 “身份证”，证明自己的身份。

     2. 验证阶段：各组件信任 CA 根证书以验证对方的实体证书（“检查身份证上的公章”）

     当组件之间通信时（如 Kibana 连接 Elasticsearch）：
     • Kibana 会要求 Elasticsearch 出示 “身份证”（Elasticsearch 的实体证书es-node.p12）。
     • Kibana 拿到后，会检查这张身份证上的公章是不是 “自己信任的公安局公章”（即验证实体证书的签名是否来自elastic-ca.pem——CA 根证书的公钥部分）。
     • 因为 Elasticsearch 的实体证书是用elastic-ca的私钥签发的，所以 Kibana 用elastic-ca的公钥（elastic-ca.pem）能验证通过，确认 “这张身份证是真的，我信任它”。
     同理，Elasticsearch 验证 Kibana 的实体证书时，也是用elastic-ca.pem检查 Kibana 的 “身份证” 上是否有可信的公章。
     这个阶段，CA 根证书的作用是 **“作为验证依据”**（判断对方的实体证书是否可信），各组件配置elastic-ca.pem，是为了告诉自己：“只要对方的证书是这个 CA 签发的（有这个公章），我就信任它”。

     为什么各组件都要配置elastic-ca.pem？

     因为所有组件的 “身份证”（实体证书）都是同一个 CA（elastic-ca）签发的，所以只需要让所有组件都信任这个 CA 的公章（elastic-ca.pem），就能互相验证对方的身份证是否有效。
     如果 Kibana 配置的是kibana-ca.pem（另一个 CA），而 Elasticsearch 的实体证书是elastic-ca签发的，那么 Kibana 会认为 Elasticsearch 的 “身份证” 上的公章是陌生的，就会拒绝信任（SSL 握手失败）。

     总结：

     • 实体证书：是组件的 “身份证”，每个组件有自己的（如es-node.p12、kibana-cert.pem），用于证明 “我是谁”，由 CA 根证书签发（盖了公章）。
     • CA 根证书（elastic-ca.pem）：是 “公章的公钥”，所有组件都需要信任它，用于验证对方的 “身份证” 上的公章是否有效（即对方的实体证书是否由可信 CA 签发）。
     两者缺一不可：没有实体证书，组件无法证明自己的身份；没有 CA 根证书，组件无法判断对方的实体证书是否可信。这就是为什么既需要用 CA 根证书生成实体证书，又需要让所有组件都信任 CA 根证书的原因。