文章目录确认证书SAN内容需要用CA证书还是自签证书1.需要确认的 IP 地址注意不能是网段不支持签发网段2.需要确认的域名/DNS3. 证书是什么类型4. CA证书和自签证书的区别多san 简化命令这个就是自签证书签发非CA证书签发使用 CA 签名的三层结构这是k8s官方和所有生产环境的做法优化前的脚本最后优化后的脚本 前两个第一个没有keyUsage和extendedKeyUsage 第二个openssl x509 -req 不支持-addext三种证书的用途对比证书类型 keyUsage与extendedKeyUsageetcd 场景的具体应用对比确认证书SAN内容需要用CA证书还是自签证书前置条件要确定自签证书内部通信节点有哪些IP访问的客户端ip段是什么上层用到的SLB 地址或域名是什么本机务必添加上127.0.0.1 、localhost证书是什么类型服务端、客户端、服务端客户端生产必须CA证书不能自签证书1.需要确认的 IP 地址注意不能是网段不支持签发网段etcd 节点自己的 IP# 当前节点所有网络接口的 IP- 物理网卡 IP: 例如100.112.0.222 - 虚拟网卡 IP: 例如100.112.6.78(可能是容器或虚拟化网络)- 回环地址:127.0.0.1Kubernetes 控制平面 VIP/负载均衡器 IP- API Server 负载均衡器 IP: 如果有外部负载均衡器 - Keepalived 虚拟 IP: 如果使用 VIPService Cluster IP 范围# etcd 在 K8s 内部的 Service IP- 通常是 K8s Service CIDR 中的某个 IP - 例如:10.96.0.0/12 范围内的某个 IP2.需要确认的域名/DNS本地主机名- localhost -$(hostname)# 当前节点的主机名Kubernetes 内部 DNS 名称最常用# etcd StatefulSet 的标准 DNS 名称etcd-0.etcd-headless.default.svc.cluster.local etcd-0.etcd-headless.kube-system.svc.cluster.local# Headless Service 名称etcd-headless.default.svc.cluster.local# 单节点常用etcd.default.svc.cluster.local etcd.kube-system.svc.cluster.local外部访问域名如果有- etcd.example.com - etcd.production.company.com3. 证书是什么类型服务端、客户端、服务端客户端忘记添加 Service DNS 名称 → kube-apiserver 通过 Service 访问 etcd 时会失败缺少节点 IP → 本地访问 etcd 失败大小写错误 → DNS 名称必须全部小写IPv6 与 IPv4 混用 → 保持一致证书过期时间 → 36500 天100年虽然可以但有些安全扫描会报警4. CA证书和自签证书的区别自签名证书自己给自己发身份证我是我自己的公安局内部 CA 签发公司公安局给员工发工牌统一的信任体系实际建议玩一玩、快速测试 → 自签名生产环境、K8s 集群 → 内部 CA对外服务 → 公共 CA总结# 自签名我是我自己的权威# 优点简单、一步到位# 缺点无法形成信任网、难以管理# 内部 CA建立自己的信任王国# 优点集中管理、易扩展、可吊销# 缺点需要额外维护 CA信任机制的区别自签名证书点对点信任节点A的证书 ──┬── 节点B手动信任 ├── 节点C手动信任 └── 节点D手动信任 每个节点都要单独配置信任关系CA 签发层次化信任┌── 节点A证书(CA签发)┌─────────┼── 节点B证书(CA签发)CA证书 ───────┼── 节点C证书(CA签发)└─────────└── 节点D证书(CA签发)所有节点只需信任同一个 CA实际操作对比自签名证书一步完成# 直接生成证书不需要 CAopenssl req-x509-new-nodes-days365\-keyserver.key\-subj/CNetcd-server\-addextsubjectAltNameIP:192.168.1.10\-outserver.crt# 客户端配置必须明确信任这个证书etcdctl--cacertserver.crt\# ← 直接信任证书本身--endpointshttps://192.168.1.10:2379\get /keyCA 签发需要 CA# 1. 创建 CA只做一次openssl req-x509-new-nodes-days3650\-keyca.key-subj/CNMy Company CA\-outca.crt# 2. 为每个服务生成证书需要 CA 签名openssl req-new-keyserver.key-outserver.csr openssl x509-req-inserver.csr\-CAca.crt-CAkeyca.key\# ← CA 签名-outserver.crt# 3. 客户端配置只需信任 CAetcdctl--cacertca.crt\# ← 信任 CA 即可--endpointshttps://192.168.1.10:2379\get /key实际场景问题场景 1Kubernetes 集群有 3 个 etcd 节点自签名方案# etcd 配置etcd:cert-file:/etc/etcd/server-1.crt# 节点1的证书key-file:/etc/etcd/server-1.key# kube-apiserver 配置要信任3个不同证书--etcd-cafile/etc/kubernetes/certs/server-1.crt# 证书1--etcd-cafile/etc/kubernetes/certs/server-2.crt# 证书2 ← 无法配置多个--etcd-cafile/etc/kubernetes/certs/server-3.crt# 证书3 ← 参数只能指定一个问题–etcd-cafile 只能指定一个文件无法同时信任多个自签名证书。CA 方案# kube-apiserver 只需信任 CA--etcd-cafile/etc/kubernetes/certs/ca.crt# 一个 CA 信任所有节点场景 2证书过期自签名# 每个节点单独处理sshnode1openssl req -x509 -new ... -out server.crtsshnode2openssl req -x509 -new ... -out server.crtsshnode3openssl req -x509 -new ... -out server.crt# 每个客户端都要重新配置信任# 痛苦要更新所有配置文件CA 签发# 集中签发新证书openssl x509-req-inserver.csr-CAca.crt-CAkeyca.key-outserver-new.crt# 分发给各节点scpserver-new.crt node1:/etc/etcd/scpserver-new.crt node2:/etc/etcd/scpserver-new.crt node3:/etc/etcd/# 客户端无需任何改动仍然信任同一个 CA场景 3节点扩容自签名# 新节点生成自签名证书# 所有客户端都要添加对这个新证书的信任# 在 K8s 中几乎不可行CA 签发# 为新节点生成证书CA 签名openssl req-new-keynode4.key-outnode4.csr openssl x509-req-innode4.csr-CAca.crt-CAkeyca.key-outnode4.crt# 客户端无需任何配置自动信任因为 CA 没变多san 简化命令这个就是自签证书签发非CA证书签发CN 是证书主体的主要标识字段用于指定该证书要保护的主域名openssl req-x509-new-nodes-sha512-days36500\-subj/CCN/STSiChuan/LChengDu/OHtzh/CN*.htwisdom.cn\-addextsubjectAltName DNS:harborai.htwisdom.cn,DNS:htwisdom.cn,DNS:htwisdom.io,DNS:htwisdom.local,DNS:*.htwisdom.io,DNS:*.htwisdom.local,DNS:htwisdom.com,DNS:*.htwisdom.com, DNS:*.htwisdom.cn,DNS:*.htwisdom.local, DNS:localhost, IP:100.112.0.222, IP:100.112.6.78, IP:127.0.0.1\-addextkeyUsage digitalSignature, keyEncipherment\-addextextendedKeyUsage serverAuth, clientAuth\-keyserver.key\-outserver.crt验证证书openssl x509-inserver.crt-text-noout|grep-A1Subject Alternative Nameopenssl x509-inserver.crt-text-noout|grepSubject:使用 CA 签名的三层结构这是k8s官方和所有生产环境的做法etcd 需要独立的 CA 证书CA 签发的服务器证书CA 签发的客户端证书优化前的脚本cat etcd-gencrt-old.sh不具备keyUsageextendedKeyUsage功能权限较大 # 1. 生成 CA 证书根证书openssl genrsa-outca.key2048openssl req-x509-new-nodes-sha256-days36500\-keyca.key\-subj/CCN/STSiChuan/LChengDu/OHtzh/CNetcd-ca\-outca.crt# 2. 生成服务器私钥和证书请求openssl genrsa-outserver.key2048openssl req-new-sha256\-keyserver.key\-subj/CCN/STSiChuan/LChengDu/OHtzh/CNetcd-server\-outserver.csr# 3. 用 CA 签发服务器证书带 SANopenssl x509-req-sha256-days36500\-inserver.csr\-CAca.crt-CAkeyca.key-CAcreateserial\-outserver.crt\-addextsubjectAltName DNS:localhost,DNS:etcd,DNS:etcd.default.svc,DNS:etcd.default.svc.cluster.local,IP:127.0.0.1,IP:100.112.0.222,IP:100.112.6.78或者 openssl x509-req-sha256-days36500\-inserver.csr\-CAca.crt-CAkeyca.key-CAcreateserial\-outserver.crt\-extfile(printfsubjectAltNameDNS:localhost,DNS:etcd,DNS:etcd.default.svc,DNS:etcd.default.svc.cluster.local,IP:127.0.0.1,IP:100.112.0.222,IP:100.112.6.78)# 4. 生成客户端证书kube-apiserver 使用openssl genrsa-outclient.key2048openssl req-new-sha256\-keyclient.key\-subj/CCN/STSiChuan/LChengDu/OHtzh/CNetcd-client\-outclient.csr# 5. 用 CA 签发客户端证书openssl x509-req-sha256-days36500\-inclient.csr\-CAca.crt-CAkeyca.key-CAcreateserial\-outclient.crt优化前的脚本CSR 证书签名请求文件相当于一张证书申请表。cat etcd-gencrt-new.sh#!/bin/bash# 设置变量DAYS36500COUNTRYCNSTATESiChuanCITYChengDuORGHtzh# 生成 CAopenssl genrsa-outca.key2048openssl req-x509-new-nodes-sha256-days${DAYS}\-keyca.key\-subj/C${COUNTRY}/ST${STATE}/L${CITY}/O${ORG}/CNetcd-ca\-addextkeyUsage critical, keyCertSign, cRLSign\-addextbasicConstraints critical, CA:TRUE\-outca.crt# 生成服务器证书openssl genrsa-outserver.key2048openssl req-new-sha256\-keyserver.key\-subj/C${COUNTRY}/ST${STATE}/L${CITY}/O${ORG}/CNetcd-server\-outserver.csr openssl x509-req-sha256-days${DAYS}\-inserver.csr\-CAca.crt-CAkeyca.key-CAcreateserial\-outserver.crt\-addextsubjectAltName DNS:localhost,DNS:etcd,DNS:etcd.default.svc,DNS:etcd.default.svc.cluster.local,IP:127.0.0.1,IP:100.112.0.222,IP:100.112.6.78\-addextkeyUsage critical, digitalSignature, keyEncipherment\-addextextendedKeyUsage serverAuth# 生成客户端证书openssl genrsa-outclient.key2048openssl req-new-sha256\-keyclient.key\-subj/C${COUNTRY}/ST${STATE}/L${CITY}/O${ORG}/CNetcd-client\-outclient.csr openssl x509-req-sha256-days${DAYS}\-inclient.csr\-CAca.crt-CAkeyca.key-CAcreateserial\-outclient.crt\-addextkeyUsage critical, digitalSignature, keyEncipherment\-addextextendedKeyUsage clientAuthecho证书生成完成ls-lh*.crt *.key最后优化后的脚本 前两个第一个没有keyUsage和extendedKeyUsage 第二个openssl x509 -req 不支持-addext# 创建扩展配置文件catserver-ext.cnfEOF subjectAltName DNS:localhost,DNS:etcd,DNS:etcd.default.svc,DNS:etcd.default.svc.cluster.local,IP:127.0.0.1,IP:100.112.0.0/16,IP:100.112.5.70 keyUsage critical, digitalSignature, keyEncipherment extendedKeyUsage serverAuth EOFcatclient-ext.cnfEOF keyUsage critical, digitalSignature, keyEncipherment extendedKeyUsage clientAuth EOF# 1. 生成 CAopenssl genrsa-outca.key2048openssl req-x509-new-nodes-sha256-days36500\-keyca.key\-subj/CCN/STSiChuan/LChengDu/OHtzh/CNetcd-ca\-addextkeyUsagecritical,keyCertSign,cRLSign\-addextbasicConstraintscritical,CA:TRUE\-outca.crt# 2. 生成服务器证书openssl genrsa-outserver.key2048openssl req-new-sha256\-keyserver.key\-subj/CCN/STSiChuan/LChengDu/OHtzh/CNetcd-server\-outserver.csr openssl x509-req-sha256-days36500\-inserver.csr\-CAca.crt-CAkeyca.key-CAcreateserial\-outserver.crt\-extfileserver-ext.cnf# 3. 生成客户端证书openssl genrsa-outclient.key2048openssl req-new-sha256\-keyclient.key\-subj/CCN/STSiChuan/LChengDu/OHtzh/CNetcd-client\-outclient.csr openssl x509-req-sha256-days36500\-inclient.csr\-CAca.crt-CAkeyca.key-CAcreateserial\-outclient.crt\-extfileclient-ext.cnf# 4. 验证结果echo 生成的文件 ls-lh*.crt *.keyechoecho 验证服务器证书 openssl x509-inserver.crt-text-noout|grep-E(Subject:|X509v3 Extended Key Usage|X509v3 Subject Alternative Name)-A1echoecho✅ 证书生成完成三种证书的用途对比证书类型 keyUsage extendedKeyUsage 使用场景 CA 证书 keyCertSign, cRLSign 无 签发其他证书 服务器证书 digitalSignature, keyEncipherment serverAuth etcd 服务端 客户端证书 digitalSignature, keyEncipherment clientAuth API Server 访问 etcd 对等证书 digitalSignature, keyEncipherment serverAuth, clientAuth etcd 集群内部通信1. 服务器证书(serverAuth) etcd 启动时使用 --cert-file 参数 证明自己是合法的 etcd 服务器2. 客户端证书(clientAuth) kube-apiserver 使用 --etcd-certfile 参数 证明自己有权限访问 etcd3. 对等证书(serverAuth clientAuth) etcd 集群节点间互相验证 既要验证对方身份clientAuth又要证明自己身份serverAuth证书类型 keyUsage与extendedKeyUsagekeyUsage基础密钥用途控制证书的私钥可以执行哪些加密操作。常用值详解 值 含义 实际场景 类比 digitalSignature 数字签名证明数据未被篡改 TLS 握手时的签名验证 在合同上签字 keyEncipherment 加密对称密钥 HTTPS 中传输会话密钥 用信封封装秘密文件 keyCertSign 签发下级证书 CA 证书给其他证书签名 公安局签发身份证 cRLSign 签发证书吊销列表 CA 发布黑名单 法院发布通缉令 dataEncipherment 直接加密数据少用 某些特殊加密场景 用密码锁锁日记本extendedKeyUsage扩展用途指定证书在 TLS/SSL 协议层的具体使用场景。常用值详解 值 含义 谁使用 验证方向 serverAuth 作为 TLS 服务器 Nginx, etcd, API Server 客户端验证服务器 clientAuth 作为 TLS 客户端 curl, kubectl, kubelet 服务器验证客户端 codeSigning 签名代码/软件 软件开发商 用户验证软件来源 emailProtection 加密/签名邮件 Outlook, Thunderbird 邮件客户端验证关键理解serverAuth ≠ 服务器证书而是这个证书可以用于服务器身份验证。# etcd 服务端证书extendedKeyUsageserverAuth# 证明自己是 etcd 服务器# kube-apiserver 客户端证书extendedKeyUsageclientAuth# 证明自己有权限访问 etcd# etcd 集群内部通信既是客户端又是服务器extendedKeyUsageserverAuth, clientAuthetcd 场景的具体应用CA 证书根证书keyUsage keyCertSign, cRLSign # 只能签发证书 # 没有 extendedKeyUsageCA 不直接参与 TLS作用像个公安局只负责签发身份证自己不上街执勤。etcd 服务器证书keyUsagedigitalSignature, keyEncipherment# 能签名和加密extendedKeyUsageserverAuth# 只能做服务器作用像警官证证明自己是警察服务器身份。3. 客户端证书kube-apiserver 用keyUsagedigitalSignature, keyEncipherment# 能签名和加密extendedKeyUsageclientAuth# 只能做客户端作用像通行证证明自己有权限进入。对等证书多节点集群keyUsagedigitalSignature, keyEncipherment# 能签名和加密extendedKeyUsageserverAuth, clientAuth# 既能当服务器又能当客户端作用像外交护照既能在本国用也能在他国用。对比openssl req -x509 完全支持 -addext 自签证书没有信任连 但openssl x509 -req 不支持-addext CA签发有完整的信任链