TLS 与证书运维

• RSA 兼容性最好但密钥长度大、握手开销相对高
• ECDSA 密钥短、握手性能好、生成快
• 浏览器与现代客户端兼容性（ECDSA 已被广泛支持）

RSA 证书兼容性最广，几乎所有客户端与旧系统（如旧版 Windows、老 Android）都支持，但密钥长（2048/4096 位）、握手时 ServerKeyExchange 与签名开销大，生成也慢。ECDSA 使用 P-256 等短密钥（256 位），签名与握手性能高、生成快，现代浏览器与客户端（Chrome/Firefox/Safari 近年）都支持。选型权衡：公网面向现代用户优先 ECDSA（或 ECDSA 为主、RSA 为备的 dual-cert），内网/合规/老系统强制 RSA 或同时支持。合规场景（如某些监管要求）可能指定 RSA 或特定算法。生成性能上 ECDSA 明显快于 RSA。

核心权衡是"兼容性 vs 性能"。RSA 兼容最广但开销大，ECDSA 性能好但要求客户端支持。现代选型多用 ECDSA 或双证书，老系统才保留 RSA。

• SNI 不匹配：多证书服务器按 SNI 选证书，缺失则返回默认
• 套件不匹配：双方无共同套件/协议版本
• 证书链不完整：中间证书缺失导致校验失败

TLS 握手失败按以下顺序排查：① SNI 不匹配——服务器按 SNI 选证书，若客户端未带 SNI 或服务器无匹配证书会返回默认/错误证书，用 openssl s_client -servername 指定 SNI 测试；② 协议版本与套件不匹配——双方无共同版本/套件，检查 -tls1_2/-tls1_3 与 -cipher；③ 证书链不完整——服务器未下发中间证书，客户端无法验证到根，用 -showcerts 检查链；④ 客户端信任库缺失——根证书不在客户端信任库，报 unknown issuer；⑤ OCSP 阻塞——客户端启用 OCSP 校验但 responder 不可达导致握手超时/失败。用 openssl s_client -state -debug 查看握手阶段，配合 -tls1_3、-verify 逐项验证。

系统性排查要按"协议→套件→证书→信任→OCSP"逐层定位，s_client 的各个参数分别命中不同环节。SNI 与证书链是最常见原因。

• Vault PKI 作为 CA，按需签发短生命周期证书
• 签发、吊销、轮换的自动化
• TTL 控制与自动续期（agent/secret engine）

Vault PKI 允许 Vault 作为 CA 动态签发证书，通常为短生命周期（几小时到几天），大幅降低证书泄露风险。签发流程：vault write pki/issue/web role=web common_name=web.example.com 按 role 的 TTL/允许域签发并返回证书与私钥。证书到期由客户端（如 Vault agent 或应用）自动续签，实现轮换。吊销用 vault write pki/revoke serial=...，并可用 pki/tidy 清理。Vault 支持 CRL/OCSP，可配合 cert-manager 的 Vault issuer 把动态证书用于 K8s。动态证书的优势是"短 TTL + 自动轮换"，即使泄露影响面小。

动态证书的核心是"按需签发 + 短 TTL + 自动续期"。Vault 提供 PKI secret engine，role 控制签发策略，agent/集成实现轮换，是零信任/短证书的典型实现。

• cert-manager 提供 Certificate/Issuer CRD
• ACME/HTTP01/DNS01 签发、自签 CA、内部 CA
• 自动续期与 secret 更新

cert-manager 通过 CRD（Certificate、Issuer/ClusterIssuer）在 K8s 中自动签发并管理证书。Certificate 声明要的域名与类型，Issuer 定义签发来源（ACME、Vault、自签、内部 CA）。ACME 支持 HTTP01（在 Ingress 上放验证文件）与 DNS01（通过 DNS provider 加 TXT 记录）验证。证书到期前 cert-manager 自动续期并更新 Secret，Ingress 引用该 Secret 即自动生效。也支持 cert-manager.io 注解或 cert-manager.io/cluster-issuer 注解间接关联。它是"声明式证书管理"，把证书生命周期纳入 K8s 声明周期。

cert-manager 的核心是"声明式 + 自动续期"。CRD 声明需求，Issuer 定义来源，控制器按需签发/续期/更新 Secret，实现证书全自动。

• blackbox_exporter 的 ssl_certificate_expiry_timestamp 指标
• 链完整性、SNI 匹配、有效期监控
• 多级告警阈值（如 30/14/7 天）

用 Prometheus blackbox_exporter 的 ssl_certificate_expiry_timestamp 指标监控证书剩余天数，probe_ssl_earliest_cert_expiry 取链中最早过期证书。通过 -r 指定 SNI（ssl_certificate_exporter 或 blackbox 的 -servername）验证多证书的 SNI 匹配，probe_ssl_last_chain_expiry_timestamp 关注链完整性。告警阈值做成多级：如剩余 30 天告警、14 天 warning、7 天 critical，越早发现越好。叠加 blackbox 的 TLS 握手探针（probe_success）检测证书链与信任问题。告警路由到值班/证书负责人，并配合"证书变更导致的连续抖动"去噪。

监控的核心是"剩余天数 + 链完整性 + SNI 匹配"。blackbox 的 ssl_certificate_expiry_timestamp 是主指标，多级阈值避免漏报，SNI 参数确保多证书探测正确。

• CT 日志记录证书签发，公开审计
• 浏览器强制 CT（公开可信证书必须入日志）
• 私有 CA 的例外：内网证书无需 CT

Certificate Transparency 是公开的证书签发日志系统，CA 签发的证书必须提交到 CT 日志，浏览器对公开可信证书强制 CT（未入日志则拒绝）。CT 的审计价值：任何证书签发都有记录，可检测 CA 误签发、中间人证书、恶意签发，可监控自己域名是否被签发证书。运维上可监控 CT 日志中自己域名的证书，发现异常签发立即处理。强制 CT 针对"公开可信的 CA（公网根）"，私有 CA 或内网自签证书不受 CT 强制，因为内网无需公网信任链，也无需公开审计。

CT 是"公开审计 + 公网信任前提"。公网证书强制入日志，私有/内网 CA 例外。审计价值在于监控误签发。

• JWKS 是 JWT 公钥的 JSON 表示，用于验签
• 与 TLS 证书（X.509）的信任模型差异
• JWKS 轮换（kid 标识）影响验签

JWKS（JSON Web Key Set）是 JWT 验签公钥的标准 JSON 表示，发布在 /jwks 端点，验签方按 JWT 头里的 kid 从 JWKS 中找对应公钥。与 TLS 证书体系差异：TLS 用 X.509 证书 + CA 信任链验证身份与公钥，JWKS 是纯公钥分发、无 CA 信任链，靠 HTTPS 保护 JWKS 端点。JWKS 轮换时，新密钥加入 JWKS 并带新 kid，旧密钥保留一段时间（grace period）让旧 JWT 仍能验签，之后移除。这与证书续期类似：新证书先发布并保持旧证书有效，待客户端缓存过期后再撤旧证书。若轮换时旧密钥立即移除，会导致旧 token 验签失败。

核心差异是"信任模型"：TLS 靠 CA 链，JWKS 靠受信任端点。轮换的类比是"新旧并存 + 平滑过渡"，避免验证窗口断裂。

• TLS 1.2 需要 2-RTT 握手，1.3 只需 1-RTT（0-RTT 可选）
• 1.3 移除旧套件，固定 AEAD 套件
• 1.3 的密钥交换（ECDHE/ECDHE-ECDSA）+ 签名

TLS 1.2 完整握手需要 2 个 RTT（ClientHello→ServerHello/Certificate→ClientKeyExchange→Finished），支持大量套件含 CBC、RC4、3DES 等弱套件。TLS 1.3 只需 1 个 RTT（ClientHello 携带 key_share，ServerHello 即完成密钥交换），可选 0-RTT（early data）。1.3 移除了 RSA 密钥交换与弱套件，只保留 AEAD 套件（AES-GCM、ChaCha20-Poly1305），名为 TLS_AES_128_GCM_SHA256 等固定格式，且强制前向保密（只能用 ECDHE），密钥协商与签名分离。1.3 还简化了握手阶段（合并 Certificate/Finished 等消息）。

1.3 的核心改进是"更少 RTT + 更强套件 + 前向保密"。1.2 靠 RTT 与套件协商，1.3 用单 RTT + 固定 AEAD，安全性更高。

• OCSP responder 提供证书状态实时查询
• 内网部署：自建 responder、配置 CA 支持
• 客户端接入 OCSP 校验、OCSP stapling

OCSP responder 用于实时查询证书吊销状态，比 CRL 更及时。内网部署：先让 CA 提供 OCSP responder（如 OpenSSL 的 OCSP 服务、专业 CA 平台），在证书的 Authority Information Access（AIA）扩展中声明 OCSP 地址，然后部署 responder 服务。客户端接入：浏览器/应用配置 OCSP 校验（或使用 OCSP stapling，由服务器在握手时带 OCSP 响应，减少客户端回源）。内网可用 OCSP stapling 减少客户端到 responder 的额外往返。相比 CRL，OCSP 实时但需响应可用，CRL 离线但可能滞后。内网需保证 responder 高可用，否则会阻塞校验。

内网 OCSP 的关键是"CA 支持 + AIA 声明 + responder 服务 + 客户端校验"。OCSP stapling 可减轻客户端回源压力，需保证 responder 可用。

• SM2 国密算法与双证书（签名证书 + 加密证书）分离
• GM/T 0024 协议（国密 SSL）
• 浏览器/服务端适配与兼容层

国密 SM2 是椭圆曲线算法，商用密码合规要求下常用"双证书体系"：签名证书用于身份验证与签名，加密证书用于数据加密，两把证书分离，符合国密 CA 规范。协议层用 GM/T 0024（国密 SSL）定义握手与加密流程。落地时：服务端需支持 GM/T 0024（如 Nginx 国密补丁、专用国密网关），浏览器需支持国密（如国密浏览器、Chrome 打补丁或使用支持国密的代理）。适配上常做"国密优先 + 标准 TLS 兜底"双栈，兼容无法用国密的客户端。合规场景（如金融、政务）要求强制国密，需保证证书、协议、浏览器全链路支持。

国密落地核心是"双证书分离 + GM/T 0024 协议 + 全链路适配"。合规强制时用国密，兼容场景做双栈共存。

• HSM 硬件保护、KMS 云托管、软密钥本地存储
• 各方案的边界：性能、成本、可控性
• 私钥泄露检测：轮换、吊销、监控

私钥保护分三档：HSM（硬件安全模块）用物理设备保护私钥，私钥不出设备，安全性最高，适合高价值/合规场景；KMS（云密钥管理）托管密钥，由云平台用 HSM 保护，省运维但有供应商依赖；软密钥（文件存储）最简单但私钥在磁盘上，安全性依赖主机防护。运维边界：HSM 强调"私钥不出设备"，KMS 强调"托管+轮换"，软密钥需严格文件权限与加密。泄露检测：持续监控私钥是否出现在公开渠道（GitHub 扫描、暴露面检查）、定期轮换密钥（缩短泄露影响窗口）、泄露后吊销证书并重新签发。配合最小权限、审计日志控制访问。

三档的权衡是"安全/成本/可控"。HSM 最安全、KMS 平衡、软密钥最灵活但最弱。泄露检测靠"扫描+轮换+吊销"。

• 过期监控：剩余天数、blackbox、多级阈值
• 轮换：自动续期、发布/生效/回滚
• 监控告警与轮换流程结合

证书监控的核心是"剩余天数告警 + 自动轮换"。用 blackbox_exporter 的 ssl_certificate_expiry_timestamp 或 cron 脚本检查剩余天数，设 30/14/7 天多级告警。轮换流程：提前签发新证书、验证链、发布到终端（Nginx/网关/负载均衡）、reload 生效、监控确认无误。自动轮换用 cert-manager/ACME 或 Vault。轮换后要验证新证书的 SAN、SNI、链完整性，并监控告警消除。证书过期事故多因监控缺失或轮换失败，需有自动化与告警兜底。回滚：保留旧证书备份，新证书异常时切回。

监控与轮换是一体的：监控发现剩余天数低→触发轮换→发布验证→告警消除。核心是"提前量 + 自动化 + 回滚"。

• 0-RTT 在首次握手后复用会话，无需额外 RTT 发送数据
• 重放风险：early data 可能被重放
• 服务端需重放防护（防重放缓存、幂等检查）

TLS 1.3 的 0-RTT（early data）允许客户端在恢复会话时把应用数据随第一个 ClientHello 发出，省去 1 个 RTT，显著降低首次请求延迟。但 0-RTT 数据存在重放风险：攻击者可重放 early data 到不同服务器或重复请求。服务端需做重放防护：使用防重放缓存（freshness 窗口 + 单次消费）、对 early data 做幂等处理（GET 等安全方法）、或对敏感操作禁用 0-RTT。测试兼容性：用 openssl s_client -early_data 发送 early data，确认服务器接受并处理，检查 -tls1_3 恢复会话；服务端可用 -enable_early_data 控制。开启时需权衡延迟收益与重放风险，敏感业务默认关闭。

0-RTT 的权衡是"延迟 vs 安全"。重放是核心风险，服务端必须防重放 + 幂等。测试用 s_client -early_data 验证，敏感操作关闭。

• s_client 看握手、证书、版本、套件
• tcpdump 抓 TLS 握手包，看 ClientHello/ServerHello
• 用 -state 查看握手阶段、-debug 输出

TLS 排障用 openssl s_client -connect host:443 -servername host -showcerts -state -debug 查看握手全程：-state 显示握手阶段（ClientHello/ServerHello/Certificate/Finished），-showcerts 看证书链，-debug 输出握手消息。抓包用 tcpdump -i any 'tcp port 443' -nn 看 ClientHello 与 ServerHello 的版本、套件、扩展，确认 TLS 版本与 ALPN。若 s_client 在某阶段失败，结合抓包判断是"服务器无响应"（网络/防火墙）、"证书问题"（verify 失败）还是"套件不匹配"（alert）。抓包可看 TLS Alert（如 handshake_failure、unrecognized_name）。

s_client 看协议层，抓包看报文层，两者结合定位握手失败的具体阶段与原因。Alert 类型是定位关键。

• 握手失败：协议/套件/SNI/证书校验
• 证书链问题：链不完整、中间证书缺失、信任库
• s_client 的 verify 输出与 -showcerts

握手失败与证书链排障：先用 openssl s_client -connect host:443 -servername host -showcerts 看服务器下发的证书链，检查是否包含中间证书。若链不完整（只有叶子+根），客户端无法验证到信任根，报 unknown issuer。用 -verify_return_error -verify_quiet 强制校验看错误。手动验证链：openssl verify -CAfile ca.pem -untrusted mid.pem leaf.pem。握手失败可能因协议版本/套件不匹配（handshake_failure alert）、SNI 不匹配（unrecognized_name）、证书过期（certificate expired）。逐项用 s_client 参数隔离。

证书链问题多在"中间证书缺失"，导致信任链断裂。verify 输出与手动 openssl verify 是定位链问题的关键。

• 会话复用（session ticket/resumption）减少握手 RTT
• OCSP stapling 由服务器在握手时带 OCSP 响应，减少客户端回源
• 性能影响与 CPU 开销

TLS 性能优化关键是减少握手开销。会话复用（session resumption）让客户端复用之前协商的会话，省去完整握手（TLS 1.3 用 session ticket，仅 1 个 RTT 或 0-RTT），显著降低重复握手延迟。OCSP stapling 由服务器在握手时主动把 OCSP 响应放在 Certificate 消息中，客户端无需回源 OCSP responder，减少一次额外往返，也避免 OCSP 阻塞。配置上：Nginx 的 ssl_session_cache、ssl_session_tickets 开会话复用，ssl_stapling on 开 OCSP stapling。会话复用能大幅降低 CPU 开销与握手延迟。

会话复用针对"握手 RTT"，OCSP stapling 针对"证书状态查询往返"。两者都减少握手阶段的额外开销，是 TLS 性能调优的核心。

• 禁用旧协议（TLS 1.0/1.1），启用 1.2/1.3
• 安全的密码套件与前向保密
• 安全头：HSTS、CSP 等

TLS 配置最佳实践：协议版本只启用 TLS 1.2/1.3，禁用 TLS 1.0/1.1/SSL（存在已知漏洞）；密码套件只选 AEAD 与 ECDHE（前向保密），禁用 RC4/3DES/CBC 弱套件。安全头：HSTS（Strict-Transport-Security）强制 HTTPS、CSP（Content-Security-Policy）限制内容来源、X-Frame-Options、X-Content-Type-Options 等。证书用 2048 位 RSA 或 ECDSA P-256，保持密钥强。配置可用 ssl_protocols TLSv1.2 TLSv1.3、ssl_ciphers 指定套件，并定期用 Qualys SSL Labs 等检测评分。

最佳实践分"传输层"（协议/套件/前向保密）与"应用层"（HSTS/CSP 等安全头）。前者管加密强度，后者管浏览器行为。

• 签发：生成密钥、CSR、CA 签发
• 续期：到期前自动续期、ACME
• 吊销：OCSP/CRL 发布撤销状态

证书生命周期管理：签发——生成密钥对、创建 CSR（包含域名 SAN）、提交 CA 签发，得到证书与链；续期——在到期前自动续期（ACME/cert-manager/Vault），新证书发布后旧证书可并存平滑过渡；吊销——证书被泄露或不再需要时，通过 CA 发布 CRL（吊销列表）或 OCSP（实时状态）声明其失效，客户端校验时发现已吊销则拒绝。运维上要建立"签发→监控→续期→吊销"的闭环，用剩余天数告警触发续期，用 CRL/OCSP 处理吊销。吊销后客户端依赖缓存/校验时效，需设计兜底。

生命周期闭环是"签发、监控、续期、吊销"。续期用自动化（ACME），吊销用 CRL/OCSP 发布状态，两者是证书信任的关键。

• cert-manager 的 Certificate/Issuer 自动续期
• ACME 协议（HTTP01/DNS01）验证
• 轮换触发与 Secret 更新

cert-manager 与 ACME 实现证书轮换自动化：cert-manager 的 Certificate 资源声明域名与 issuer，到期前自动发起 ACME 签发（HTTP01 通过 Ingress 提供验证文件，DNS01 通过 DNS provider 添加 TXT 记录），签发后更新 Secret，Ingress/网关引用该 Secret 自动生效。ACME 的证书有效期为 90 天，cert-manager 在剩余约 30 天时自动续期，实现"短周期 + 自动轮换"。轮换过程无需人工干预，且 cert-manager 保证续期失败可重试。它是 K8s 内证书自动化的标准方案。

自动化核心是"声明式 + 到期自动续期"。ACME 提供签发协议，cert-manager 管理声明与续期，Secret 更新使终端自动生效。