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）實現互信。
  1. 外部訪問層（用户 / 客户端信任）：
  • 若需外部用户通過瀏覽器訪問 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 根證書的原因。