尧图网页设计 
etcd 集群的 TLS 证书怎么生成用仓库自带 cfssl 脚本签发 CA、client 与 peer 证书【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd给 etcd 集群开启 TLS客户端走 HTTPS、节点之间做 peer 双向认证之前需要先准备 CA 证书和每个节点的证书。etcd 仓库在hack/tls-setup/下自带了一套基于 Cloudflare cfssl 工具的签发脚本一条make就能生成 CA 和各节点的 client、peer 证书。本文按改 CSR → 设环境变量 → 跑脚本 → 核对产物的顺序走完这条流程最后给出用生成的证书拉起本地三节点演示集群的方法。前置条件按 hack/tls-setup/README.md 的要求是机器上已安装 git、go 和 make。脚本与配置文件在哪里整套工具集中在 hack/tls-setup/ 目录Makefile定义cfssl、ca、req、clean四个 targetall直接make时执行careqconfig/ca-csr.jsonCA 的 CSRCN 为Autogenerated CARSA 2048CA 有效期876000hconfig/req-csr.json节点证书的 CSRhosts字段是节点 IP 列表当前仓库里是localhost、127.0.0.1和三个示例 IPCN 为etcdconfig/ca-config.json签发配置允许的 usages 为signing、key encipherment、server auth、client auth叶子证书有效期876000hProcfile用 goreman 拉起本地三节点演示集群的命令。Makefile 中CFSSL和JSON两个变量会在GOPATH/bin前缀 PATH 上调用cfssl与cfssljson所以 cfssl 工具装到GOPATH/bin后脚本才能找到它们。第一步编辑 req-csr.json替换为本集群的节点 IP把 config/req-csr.json 中hosts里的 IP 替换/补充为每个 etcd 节点的 IP 地址。README 强调127.0.0.1必须保留loopback 用途。README 给出的编辑示例文档示例如下{ CN: etcd, hosts: [ 3.8.121.201, 46.4.19.20, 127.0.0.1 ], key: { algo: ecdsa, size: 384 }, names: [ { O: autogenerated, OU: etcd cluster, L: the internet } ] }注意一处文档与实际文件的出入README 开头说默认生成 ECDSA-384 root and leaf certificates示例里的key也是ecdsa/384但仓库当前的 ca-csr.json 和 req-csr.json 实际写的是algo: rsa、size: 2048。最终生效的密钥算法以你实际编辑的文件中key字段为准签发前先确认它符合你的预期。第二步设置三个节点环境变量README 要求导出以下环境变量{IP-0}、{IP-1}、{IP-2}需替换为各节点 IPexport infra0{IP-0} export infra1{IP-1} export infra2{IP-2}在 Makefile 中reqtarget 用${infra0}等变量作为证书输出的文件名前缀即每个节点会生成certs/${infraN}.pemclient 证书和certs/peer-${infraN}.pempeer 证书两套文件。README 示例中直接用节点 IP 作为变量值。第三步执行签发首次使用先安装 cfssl 工具链。cfssltarget 通过go get下载并安装cfssl、cfssljson和goreman三个工具副作用会从网络拉取代码并安装到本机 Go 环境Makefile 中保留了代理设置HTTPS_PROXY127.0.0.1:12639 go get -u -tags nopkcs11 github.com/cloudflare/cfssl/cmd/cfssl HTTPS_PROXY127.0.0.1:12639 go get -u github.com/cloudflare/cfssl/cmd/cfssljson HTTPS_PROXY127.0.0.1:12639 go get -u github.com/mattn/goreman执行make cfssl然后执行主流程makemake依次跑ca和req两个 target实际执行的命令为# ca创建 certs/ 目录并自签 CA mkdir -p certs cfssl gencert -initca config/ca-csr.json | cfssljson -bare certs/ca # req用 CA 分别签发三个节点的 client 证书和 peer 证书以 infra0 为例其余类推 cfssl gencert \ -ca certs/ca.pem \ -ca-key certs/ca-key.pem \ -config config/ca-config.json \ config/req-csr.json | cfssljson -bare certs/${infra0} cfssl gencert \ -ca certs/ca.pem \ -ca-key certs/ca-key.pem \ -config config/ca-config.json \ config/req-csr.json | cfssljson -bare certs/peer-${infra0}CA 来自ca-csr.json自签节点证书则由certs/ca.pem签发签发时的 usages 和有效期取ca-config.json的默认值。第四步核对产物按 Makefile 与 Procfile 的引用make完成后certs/目录中应有ca.pem、ca-key.pemCA 证书与私钥${infra0}.pem、${infra0}-key.peminfra1、infra2 同理节点 client 证书peer-${infra0}.pem、peer-${infra0}-key.pem同理节点 peer 证书。README 说明etcd 节点在双向认证的两端使用同一张证书但不对非 peer 的客户端强制要求 client 证书——这正对应 Procfile 里--cert-file与--peer-cert-file传同一文件、只加--peer-client-cert-auth而不加客户端 cert auth 的做法。如果需要重新生成make clean会删除整个certs/目录执行前确认目录里只有本次生成的文件。可选用生成的证书拉起本地三节点演示集群Procfile 用 goreman 在本机启动三个 etcd 进程本地演示用端口各不相同其中etcd1的完整命令如下其余两个同构../../bin/etcd --name infra1 --listen-client-urls https://localhost:2379 \ --advertise-client-urls https://localhost:2379 \ --listen-peer-urls https://localhost:2380 \ --initial-advertise-peer-urls https://localhost:2380 \ --initial-cluster-token etcd-cluster-1 \ --initial-cluster infra1https://localhost:2380,infra2https://localhost:12380,infra3https://localhost:22380 \ --initial-cluster-state new \ --cert-filecerts/etcd1.pem --key-filecerts/etcd1-key.pem \ --peer-cert-filecerts/etcd1.pem --peer-key-filecerts/etcd1-key.pem \ --peer-client-cert-auth --peer-trusted-ca-filecerts/ca.pem注意两点适用条件Procfile 期望的证书文件名是certs/etcd1.pem、certs/etcd2.pem、certs/etcd3.pem即环境变量需要按etcd1/etcd2/etcd3取值运行make才能对上这套文件名另外命令引用../../bin/etcd要求 etcd 二进制已构建到仓库的bin/目录下。启动三个 etcd 进程属于本地产物的演示用途按需执行。限制与常见的握手拒绝现象hosts中缺127.0.0.1或漏掉节点真实 IP 时对应端的 TLS 校验会失败。CHANGELOG-3.2.md 记录了具体现象当 peer 证书 SAN 里含 IP 而对方远端 IP 不匹配时etcd 拒绝连接错误为x509: certificate is valid for 10.138.0.27, not 10.138.0.2当 peer 证书只有 DNS 名且解析结果不含对方 IP 时错误形如tls: 10.138.0.2 does not match any of DNSNames [b.com]。生成证书前核对hosts与节点实际 IP 一致是避免这类报错的关键。README 描述的默认算法ECDSA-384与仓库配置文件实际内容RSA-2048不一致签发前以文件实际内容为准。客户端一侧默认不强制 client 证书README如需对非 peer 客户端也做双向认证需要自行补充对应的 etcd 启动参数脚本本身只覆盖上述证书生成流程。【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 etcd 集群的 TLS 证书怎么生成：用仓库自带 cfssl 脚本签发 CA、client 与 peer 证书
etcd 集群的 TLS 证书怎么生成用仓库自带 cfssl 脚本签发 CA、client 与 peer 证书【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd给 etcd 集群开启 TLS客户端走 HTTPS、节点之间做 peer 双向认证之前需要先准备 CA 证书和每个节点的证书。etcd 仓库在hack/tls-setup/下自带了一套基于 Cloudflare cfssl 工具的签发脚本一条make就能生成 CA 和各节点的 client、peer 证书。本文按改 CSR → 设环境变量 → 跑脚本 → 核对产物的顺序走完这条流程最后给出用生成的证书拉起本地三节点演示集群的方法。前置条件按 hack/tls-setup/README.md 的要求是机器上已安装 git、go 和 make。脚本与配置文件在哪里整套工具集中在 hack/tls-setup/ 目录Makefile定义cfssl、ca、req、clean四个 targetall直接make时执行careqconfig/ca-csr.jsonCA 的 CSRCN 为Autogenerated CARSA 2048CA 有效期876000hconfig/req-csr.json节点证书的 CSRhosts字段是节点 IP 列表当前仓库里是localhost、127.0.0.1和三个示例 IPCN 为etcdconfig/ca-config.json签发配置允许的 usages 为signing、key encipherment、server auth、client auth叶子证书有效期876000hProcfile用 goreman 拉起本地三节点演示集群的命令。Makefile 中CFSSL和JSON两个变量会在GOPATH/bin前缀 PATH 上调用cfssl与cfssljson所以 cfssl 工具装到GOPATH/bin后脚本才能找到它们。第一步编辑 req-csr.json替换为本集群的节点 IP把 config/req-csr.json 中hosts里的 IP 替换/补充为每个 etcd 节点的 IP 地址。README 强调127.0.0.1必须保留loopback 用途。README 给出的编辑示例文档示例如下{ CN: etcd, hosts: [ 3.8.121.201, 46.4.19.20, 127.0.0.1 ], key: { algo: ecdsa, size: 384 }, names: [ { O: autogenerated, OU: etcd cluster, L: the internet } ] }注意一处文档与实际文件的出入README 开头说默认生成 ECDSA-384 root and leaf certificates示例里的key也是ecdsa/384但仓库当前的 ca-csr.json 和 req-csr.json 实际写的是algo: rsa、size: 2048。最终生效的密钥算法以你实际编辑的文件中key字段为准签发前先确认它符合你的预期。第二步设置三个节点环境变量README 要求导出以下环境变量{IP-0}、{IP-1}、{IP-2}需替换为各节点 IPexport infra0{IP-0} export infra1{IP-1} export infra2{IP-2}在 Makefile 中reqtarget 用${infra0}等变量作为证书输出的文件名前缀即每个节点会生成certs/${infraN}.pemclient 证书和certs/peer-${infraN}.pempeer 证书两套文件。README 示例中直接用节点 IP 作为变量值。第三步执行签发首次使用先安装 cfssl 工具链。cfssltarget 通过go get下载并安装cfssl、cfssljson和goreman三个工具副作用会从网络拉取代码并安装到本机 Go 环境Makefile 中保留了代理设置HTTPS_PROXY127.0.0.1:12639 go get -u -tags nopkcs11 github.com/cloudflare/cfssl/cmd/cfssl HTTPS_PROXY127.0.0.1:12639 go get -u github.com/cloudflare/cfssl/cmd/cfssljson HTTPS_PROXY127.0.0.1:12639 go get -u github.com/mattn/goreman执行make cfssl然后执行主流程makemake依次跑ca和req两个 target实际执行的命令为# ca创建 certs/ 目录并自签 CA mkdir -p certs cfssl gencert -initca config/ca-csr.json | cfssljson -bare certs/ca # req用 CA 分别签发三个节点的 client 证书和 peer 证书以 infra0 为例其余类推 cfssl gencert \ -ca certs/ca.pem \ -ca-key certs/ca-key.pem \ -config config/ca-config.json \ config/req-csr.json | cfssljson -bare certs/${infra0} cfssl gencert \ -ca certs/ca.pem \ -ca-key certs/ca-key.pem \ -config config/ca-config.json \ config/req-csr.json | cfssljson -bare certs/peer-${infra0}CA 来自ca-csr.json自签节点证书则由certs/ca.pem签发签发时的 usages 和有效期取ca-config.json的默认值。第四步核对产物按 Makefile 与 Procfile 的引用make完成后certs/目录中应有ca.pem、ca-key.pemCA 证书与私钥${infra0}.pem、${infra0}-key.peminfra1、infra2 同理节点 client 证书peer-${infra0}.pem、peer-${infra0}-key.pem同理节点 peer 证书。README 说明etcd 节点在双向认证的两端使用同一张证书但不对非 peer 的客户端强制要求 client 证书——这正对应 Procfile 里--cert-file与--peer-cert-file传同一文件、只加--peer-client-cert-auth而不加客户端 cert auth 的做法。如果需要重新生成make clean会删除整个certs/目录执行前确认目录里只有本次生成的文件。可选用生成的证书拉起本地三节点演示集群Procfile 用 goreman 在本机启动三个 etcd 进程本地演示用端口各不相同其中etcd1的完整命令如下其余两个同构../../bin/etcd --name infra1 --listen-client-urls https://localhost:2379 \ --advertise-client-urls https://localhost:2379 \ --listen-peer-urls https://localhost:2380 \ --initial-advertise-peer-urls https://localhost:2380 \ --initial-cluster-token etcd-cluster-1 \ --initial-cluster infra1https://localhost:2380,infra2https://localhost:12380,infra3https://localhost:22380 \ --initial-cluster-state new \ --cert-filecerts/etcd1.pem --key-filecerts/etcd1-key.pem \ --peer-cert-filecerts/etcd1.pem --peer-key-filecerts/etcd1-key.pem \ --peer-client-cert-auth --peer-trusted-ca-filecerts/ca.pem注意两点适用条件Procfile 期望的证书文件名是certs/etcd1.pem、certs/etcd2.pem、certs/etcd3.pem即环境变量需要按etcd1/etcd2/etcd3取值运行make才能对上这套文件名另外命令引用../../bin/etcd要求 etcd 二进制已构建到仓库的bin/目录下。启动三个 etcd 进程属于本地产物的演示用途按需执行。限制与常见的握手拒绝现象hosts中缺127.0.0.1或漏掉节点真实 IP 时对应端的 TLS 校验会失败。CHANGELOG-3.2.md 记录了具体现象当 peer 证书 SAN 里含 IP 而对方远端 IP 不匹配时etcd 拒绝连接错误为x509: certificate is valid for 10.138.0.27, not 10.138.0.2当 peer 证书只有 DNS 名且解析结果不含对方 IP 时错误形如tls: 10.138.0.2 does not match any of DNSNames [b.com]。生成证书前核对hosts与节点实际 IP 一致是避免这类报错的关键。README 描述的默认算法ECDSA-384与仓库配置文件实际内容RSA-2048不一致签发前以文件实际内容为准。客户端一侧默认不强制 client 证书README如需对非 peer 客户端也做双向认证需要自行补充对应的 etcd 启动参数脚本本身只覆盖上述证书生成流程。【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考