• Elasticsearch:使用不同的 CA 更新安全证书 (二)


    在之前的文章 “Elasticsearch:使用不同的 CA 更新安全证书 (一)” 中,我详细地描述了如何更新 transport 层的证书。transport 层的证书复制集群中各个节点之前的连接,甚至关乎集群之前的连接。在这边文章中,我将继续之前的内容来详述如何替换 HTTP 层的证书。

    • HTTP:用于 HTTP 通信绑定的地址和端口,这是 Elasticsearch REST API 公开的方式
    • transport:用于集群内节点之间的内部通信

    为 HTTP 层生成新证书

    你可以使用新的 CA 证书和私钥为 HTTP 层生成证书。 其他组件(例如 Kibana 或任何 Elastic 语言客户端)在连接到 Elasticsearch 时会验证此证书。

    注意:如果你的组织有自己的 CA,则需要生成证书签名请求 (CSR)。 CSR 包含你的 CA 用于生成和签署安全证书的信息,而不是使用 elasticsearch-certutil 工具生成的自签名证书。

    更新客户端以信任新 CA

    在为 HTTP 层生成(但在使用之前)新证书之后,你需要转到连接到 Elasticsearch 的所有客户端(例如 Beats、Logstash 和任何语言客户端)并将它们配置为也信任新 CA(ca. crt) 生成的。

    每个客户端的此过程都不同,因此请参阅客户端的文档以获取信任证书。 在此过程中生成必要的证书后,你将更新 Kibana 和 Elasticsearch 之间的 HTTP 加密。

    我们将使用如下的步骤来更新 HTTP 层的证书:

    1)在集群中安装了 Elasticsearch 的任何节点上,运行 Elasticsearch HTTP 证书工具。

    ./bin/elasticsearch-certutil http

    此命令会生成一个 .zip 文件,其中包含用于 Elasticsearch 和 Kibana 的证书和密钥。 每个文件夹都包含一个 README.txt,解释如何使用这些文件。

    1. 当询问你是否要生成 CSR 时,输入 n。
    2. 当询问你是否要使用现有 CA 时,输入 y。
    3. 输入新 CA 证书的绝对路径,例如 ca.crt 文件的路径。
    4. 输入新 CA 证书私钥的绝对路径,例如 ca.key 文件的路径。
    5. 输入证书的到期值。你可以输入年、月或日的有效期。例如,输入 1y 表示一年。
    6. 当询问你是否要为每个节点生成一个证书时,输入 y。
    7. 每个证书都有自己的私钥,并针对特定的主机名或 IP 地址颁发。
    8. 出现提示时,输入集群中第一个节点的名称。使用与 elasticsearch.yml 文件中 node.name 参数的值相同的节点名称。
    9. 输入用于连接到你的第一个节点的所有主机名。这些主机名将作为 DNS 名称添加到证书的主题备用名称 (SAN) 字段中。
    10. 列出用于通过 HTTPS 连接到集群的每个主机名和变体。
    11. 输入客户端可用于连接到你的节点的 IP 地址。
    12. 对集群中的每个其他节点重复这些步骤。
    1. $ pwd
    2. /Users/liuxg/elastic0/elasticsearch-8.3.2
    3. $ ./bin/elasticsearch-certutil http
    4. ## Elasticsearch HTTP Certificate Utility
    5. The 'http' command guides you through the process of generating certificates
    6. for use on the HTTP (Rest) interface for Elasticsearch.
    7. This tool will ask you a number of questions in order to generate the right
    8. set of files for your needs.
    9. ## Do you wish to generate a Certificate Signing Request (CSR)?
    10. A CSR is used when you want your certificate to be created by an existing
    11. Certificate Authority (CA) that you do not control (that is, you don't have
    12. access to the keys for that CA).
    13. If you are in a corporate environment with a central security team, then you
    14. may have an existing Corporate CA that can generate your certificate for you.
    15. Infrastructure within your organisation may already be configured to trust this
    16. CA, so it may be easier for clients to connect to Elasticsearch if you use a
    17. CSR and send that request to the team that controls your CA.
    18. If you choose not to generate a CSR, this tool will generate a new certificate
    19. for you. That certificate will be signed by a CA under your control. This is a
    20. quick and easy way to secure your cluster with TLS, but you will need to
    21. configure all your clients to trust that custom CA.
    22. Generate a CSR? [y/N]n
    23. ## Do you have an existing Certificate Authority (CA) key-pair that you wish to use to sign your certificate?
    24. If you have an existing CA certificate and key, then you can use that CA to
    25. sign your new http certificate. This allows you to use the same CA across
    26. multiple Elasticsearch clusters which can make it easier to configure clients,
    27. and may be easier for you to manage.
    28. If you do not have an existing CA, one will be generated for you.
    29. Use an existing CA? [y/N]y
    30. ## What is the path to your CA?
    31. Please enter the full pathname to the Certificate Authority that you wish to
    32. use for signing your new http certificate. This can be in PKCS#12 (.p12), JKS
    33. (.jks) or PEM (.crt, .key, .pem) format.
    34. CA Path: /Users/liuxg/elastic0/elasticsearch-8.3.2/ca/ca.crt
    35. ## What is the path to your CA key?
    36. /Users/liuxg/elastic0/elasticsearch-8.3.2/ca/ca.crt appears to be a PEM formatted certificate file.
    37. In order to use it for signing we also need access to the private key
    38. that corresponds to that certificate.
    39. CA Key: /Users/liuxg/elastic0/elasticsearch-8.3.2/ca/ca.key
    40. ## How long should your certificates be valid?
    41. Every certificate has an expiry date. When the expiry date is reached clients
    42. will stop trusting your certificate and TLS connections will fail.
    43. Best practice suggests that you should either:
    44. (a) set this to a short duration (90 - 120 days) and have automatic processes
    45. to generate a new certificate before the old one expires, or
    46. (b) set it to a longer duration (3 - 5 years) and then perform a manual update
    47. a few months before it expires.
    48. You may enter the validity period in years (e.g. 3Y), months (e.g. 18M), or days (e.g. 90D)
    49. For how long should your certificate be valid? [5y]
    50. ## Do you wish to generate one certificate per node?
    51. If you have multiple nodes in your cluster, then you may choose to generate a
    52. separate certificate for each of these nodes. Each certificate will have its
    53. own private key, and will be issued for a specific hostname or IP address.
    54. Alternatively, you may wish to generate a single certificate that is valid
    55. across all the hostnames or addresses in your cluster.
    56. If all of your nodes will be accessed through a single domain
    57. (e.g. node01.es.example.com, node02.es.example.com, etc) then you may find it
    58. simpler to generate one certificate with a wildcard hostname (*.es.example.com)
    59. and use that across all of your nodes.
    60. However, if you do not have a common domain name, and you expect to add
    61. additional nodes to your cluster in the future, then you should generate a
    62. certificate per node so that you can more easily generate new certificates when
    63. you provision new nodes.
    64. Generate a certificate per node? [y/N]y
    65. ## What is the name of node #1?
    66. This name will be used as part of the certificate file name, and as a
    67. descriptive name within the certificate.
    68. You can use any descriptive name that you like, but we recommend using the name
    69. of the Elasticsearch node.
    70. node #1 name: mac
    71. ## Which hostnames will be used to connect to mac?
    72. These hostnames will be added as "DNS" names in the "Subject Alternative Name"
    73. (SAN) field in your certificate.
    74. You should list every hostname and variant that people will use to connect to
    75. your cluster over http.
    76. Do not list IP addresses here, you will be asked to enter them later.
    77. If you wish to use a wildcard certificate (for example *.es.example.com) you
    78. can enter that here.
    79. Enter all the hostnames that you need, one per line.
    80. When you are done, press once more to move on to the next step.
    81. localhost
    82. liuxgm.local
    83. liuxg.com
    84. mac
    85. You entered the following hostnames.
    86. - localhost
    87. - liuxgm.local
    88. - liuxg.com
    89. - mac
    90. Is this correct [Y/n]y
    91. ## Which IP addresses will be used to connect to mac?
    92. If your clients will ever connect to your nodes by numeric IP address, then you
    93. can list these as valid IP "Subject Alternative Name" (SAN) fields in your
    94. certificate.
    95. If you do not have fixed IP addresses, or not wish to support direct IP access
    96. to your cluster then you can just press to skip this step.
    97. Enter all the IP addresses that you need, one per line.
    98. When you are done, press once more to move on to the next step.
    99. 192.168.0.3
    100. You entered the following IP addresses.
    101. - 192.168.0.3
    102. Is this correct [Y/n]y
    103. ## Other certificate options
    104. The generated certificate will have the following additional configuration
    105. values. These values have been selected based on a combination of the
    106. information you have provided above and secure defaults. You should not need to
    107. change these values unless you have specific requirements.
    108. Key Name: mac
    109. Subject DN: CN=mac
    110. Key Size: 2048
    111. Do you wish to change any of these options? [y/N]n
    112. Generate additional certificates? [Y/n]y
    113. ## What is the name of node #2?
    114. This name will be used as part of the certificate file name, and as a
    115. descriptive name within the certificate.
    116. You can use any descriptive name that you like, but we recommend using the name
    117. of the Elasticsearch node.
    118. node #2 name: ubuntu
    119. ## Which hostnames will be used to connect to ubuntu?
    120. These hostnames will be added as "DNS" names in the "Subject Alternative Name"
    121. (SAN) field in your certificate.
    122. You should list every hostname and variant that people will use to connect to
    123. your cluster over http.
    124. Do not list IP addresses here, you will be asked to enter them later.
    125. If you wish to use a wildcard certificate (for example *.es.example.com) you
    126. can enter that here.
    127. Enter all the hostnames that you need, one per line.
    128. When you are done, press once more to move on to the next step.
    129. parallels
    130. localhost
    131. You entered the following hostnames.
    132. - parallels
    133. - localhost
    134. Is this correct [Y/n]y
    135. ## Which IP addresses will be used to connect to ubuntu?
    136. If your clients will ever connect to your nodes by numeric IP address, then you
    137. can list these as valid IP "Subject Alternative Name" (SAN) fields in your
    138. certificate.
    139. If you do not have fixed IP addresses, or not wish to support direct IP access
    140. to your cluster then you can just press to skip this step.
    141. Enter all the IP addresses that you need, one per line.
    142. When you are done, press once more to move on to the next step.
    143. 192.168.0.8
    144. You entered the following IP addresses.
    145. - 192.168.0.8
    146. Is this correct [Y/n]y
    147. ## Other certificate options
    148. The generated certificate will have the following additional configuration
    149. values. These values have been selected based on a combination of the
    150. information you have provided above and secure defaults. You should not need to
    151. change these values unless you have specific requirements.
    152. Key Name: ubuntu
    153. Subject DN: CN=ubuntu
    154. Key Size: 2048
    155. Do you wish to change any of these options? [y/N]n
    156. Generate additional certificates? [Y/n]n
    157. ## What password do you want for your private key(s)?
    158. Your private key(s) will be stored in a PKCS#12 keystore file named "http.p12".
    159. This type of keystore is always password protected, but it is possible to use a
    160. blank password.
    161. If you wish to use a blank password, simply press at the prompt below.
    162. Provide a password for the "http.p12" file: [ for none]
    163. ## Where should we save the generated files?
    164. A number of files will be generated including your private key(s),
    165. public certificate(s), and sample configuration options for Elastic Stack products.
    166. These files will be included in a single zip archive.
    167. What filename should be used for the output zip file? [/Users/liuxg/elastic0/elasticsearch-8.3.2/elasticsearch-ssl-http.zip]
    168. Zip file written to /Users/liuxg/elastic0/elasticsearch-8.3.2/elasticsearch-ssl-http.zip

    2)为每个节点生成证书后,在出现提示时输入密钥库的密码。

    3)解压生成的 elasticsearch-ssl-http.zip 文件。 此压缩文件包含一个用于 Elasticsearch 和 Kibana 的目录。 /elasticsearch 目录中是您使用其自己的 http.p12 文件指定的每个节点的目录。 例如:

    1. $ pwd
    2. /Users/liuxg/elastic0/elasticsearch-8.3.2
    3. $ ls
    4. LICENSE.txt data lib
    5. NOTICE.txt elastic-certificates.p12 logs
    6. README.asciidoc elastic-stack-ca.p12 modules
    7. bin elastic-stack-ca.zip plugins
    8. ca elasticsearch-ssl-http.zip
    9. config jdk.app
    10. $ unzip elasticsearch-ssl-http.zip
    11. Archive: elasticsearch-ssl-http.zip
    12. creating: elasticsearch/
    13. creating: elasticsearch/mac/
    14. inflating: elasticsearch/mac/README.txt
    15. inflating: elasticsearch/mac/http.p12
    16. inflating: elasticsearch/mac/sample-elasticsearch.yml
    17. creating: elasticsearch/ubuntu/
    18. inflating: elasticsearch/ubuntu/README.txt
    19. inflating: elasticsearch/ubuntu/http.p12
    20. inflating: elasticsearch/ubuntu/sample-elasticsearch.yml
    21. creating: kibana/
    22. inflating: kibana/README.txt
    23. inflating: kibana/elasticsearch-ca.pem
    24. inflating: kibana/sample-kibana.yml

    4)如有必要,重命名每个 http.p12 文件以匹配您现有的 HTTP 客户端通信证书的名称。 例如,node1-http.p12。针对我的情况,我直接把上面生成的 http.p12 拷入到之前的目录中:

    1. $ cp ./elasticsearch/mac/http.p12 ./config/certs/
    2. overwrite ./config/certs/http.p12? (y/n [n]) y

    这样我们就覆盖了之前的证书。我们同时使用如下的命令来更新 config/certs/http_ca.crt 文件:

    cp ca/ca.crt config/certs/http_ca.crt
    1. $ cp http_ca.crt ./config/certs/
    2. overwrite ./config/certs/http_ca.crt? (y/n [n]) y

    我们可以很容易验证这个证书的正确性:

    1. $ curl --cacert /Users/liuxg/elastic0/elasticsearch-8.3.2/config/certs/http_ca.crt -u elastic:WRuB1Xdd4bu3jzpo_ugw -XGET "https://192.168.0.3:9200/"
    2. {
    3. "name" : "liuxgm.local",
    4. "cluster_name" : "elasticsearch",
    5. "cluster_uuid" : "w2WUiix7RcaWODjmFdMiYA",
    6. "version" : {
    7. "number" : "8.3.2",
    8. "build_type" : "tar",
    9. "build_hash" : "8b0b1f23fbebecc3c88e4464319dea8989f374fd",
    10. "build_date" : "2022-07-06T15:15:15.901688194Z",
    11. "build_snapshot" : false,
    12. "lucene_version" : "9.2.0",
    13. "minimum_wire_compatibility_version" : "7.17.0",
    14. "minimum_index_compatibility_version" : "7.0.0"
    15. },
    16. "tagline" : "You Know, for Search"
    17. }

    上面显示我们的证书是正确的。

    5)在集群中要更新密钥库的当前节点上,启动滚动重启

    在指示 Perform any needed changes 的步骤处停止,然后继续执行此过程中的下一步。

    6)用新的密钥库替换现有的密钥库,确保文件名匹配。 例如,node1-http.p12。

    重要:如果你的密钥库密码正在更改,请使用新文件名保存密钥库,以便 Elasticsearch 在你更新密码之前不会尝试重新加载文件。

    7)如果你需要使用新文件名保存新密钥库,请更新 ES_PATH_CONF/elasticsearch.yml 文件以使用新密钥库的文件名。 例如:

    1. xpack.security.http.ssl.enabled: true
    2. xpack.security.http.ssl.keystore.path: node1-http.p12

    8)如果你的密钥库密码正在更改,请将你的私钥密码添加到 Elasticsearch 中的安全设置中。

    1. $ pwd
    2. /Users/liuxg/elastic0/elasticsearch-8.3.2
    3. $ ./bin/elasticsearch-keystore list
    4. keystore.seed
    5. xpack.security.http.ssl.keystore.secure_password
    6. xpack.security.transport.ssl.keystore.secure_password
    7. xpack.security.transport.ssl.truststore.secure_password
    8. $ ./bin/elasticsearch-keystore show xpack.security.http.ssl.keystore.secure_password
    9. sdNqGKAyRqiqtvhELjqg7Q
    10. $ ./bin/elasticsearch-keystore add xpack.security.http.ssl.keystore.secure_password
    11. Setting xpack.security.http.ssl.keystore.secure_password already exists. Overwrite? [y/N]y
    12. Enter value for xpack.security.http.ssl.keystore.secure_password:

    请注意这个密码是在上面的第一步中生成证书时提示输入的一个密码:

    1. Your private key(s) will be stored in a PKCS#12 keystore file named "http.p12".
    2. This type of keystore is always password protected, but it is possible to use a
    3. blank password.
    4. If you wish to use a blank password, simply press at the prompt below.
    5. Provide a password for the "http.p12" file: [ for none]

    我们可以通过上面的方法来更新这个密码。

    9)启动更新密钥库的节点。

    启动如下的命令来查看 HTTP 是否正常。在我上面的演示中,我特别添加了 liuxg.com 这个域名。在默认安装的情况下,这个是不可以访问的,但是由于我们添加了这个,我们尝试使用 liuxg.com 来进行访问。有关 liuxg.com 的配置,你可以在 /etc/hosts 中今天添加:

     显然我们的访问是成功的。

    10)我们还可以通过如下的命令来查看 Elasticsearch 所装载的 keystore:

    GET /_ssl/certificates

    11)一次一个节点,完成第 5 步到第 10 步,直到你更新了集群中的所有密钥库。

    12)完成滚动重启的剩余步骤,从 Reenable shard allocation 的步骤开始。

    如果这个时候,我们尝试访问 Kibana,我们将看到如下的信息:

    显然,我们的访问是不成功的。我将在下面来配置 Kibana。

    更新 Kibana 和 Elasticsearch 之间的加密

    当你使用 http 选项运行 elasticsearch-certutil 工具时,它会创建一个 /kibana 目录,其中包含一个 elasticsearch-ca.pem 文件。 你可以使用此文件将 Kibana 配置为信任 HTTP 层的 Elasticsearch CA。

    1)将 elasticsearch-ca.pem 文件复制到由 KBN_PATH_CONF 路径定义的 Kibana 配置目录。

    注意:KBN_PATH_CONF 包含 Kibana 配置文件的路径。 如果你使用归档发行版(zip 或 tar.gz)安装 Kibana,则路径默认为 KBN_HOME/config。 如果你使用软件包发行版(Debian 或 RPM),则路径默认为 /etc/kibana。

    1. $ pwd
    2. /Users/liuxg/elastic0/elasticsearch-8.3.2
    3. $ cp kibana/elasticsearch-ca.pem ../kibana-8.3.2/config
    4. $ cd ../kibana-8.3.2/config/
    5. $ ls
    6. elasticsearch-ca.pem kibana.yml node.options

    2)如果你修改了 elasticsearch-ca.pem 文件的文件名,请编辑 kibana.yml 并更新配置以指定 HTTP 层的安全证书的位置。

    kibana.yml

     保存上面的文件

    3)重新启动 Kibana。我们再次访问 Kibana:

    上面显示我们的访问是成功的。 

  • 相关阅读:
    2024年10月文章一览
    多目标优化算法matlab代码大合集
    某瑞集团安全技术研发岗位面试
    mybatisplus快速实现动态数据源切换
    [附源码]java毕业设计 宠物医院管理系统
    RouYi-Vue项目部署——保姆级教程
    MES管理系统的设计与实施
    60 最长有效括号
    手把手教你Nginx常用模块详解之ngx_http_rewrite_module(十)
    【Shell牛客刷题系列】SHELL21 格式化输出:来看个printf命令的小彩蛋~
  • 原文地址:https://blog.csdn.net/UbuntuTouch/article/details/125993452