TLS证书和自动续期

为什么需要它

TLS加密"kliyent↔servis"流量，确认服务器的真实性（以及mTLS-客户端），并防止欺骗。主要风险包括证书逾期、密钥薄弱、信任链错误、手动程序。本文的目的是描述一种体系结构，在该体系结构中，证书始终是相关的，并且用户不注意轮换。

基本概念

CA/签署人：证书颁发机构（公共或内部）。
链（fullchain）：叶片证书+中间+根（通常在客户端存储中根）。
"主题替代名称"（SAN）-单个证书（multi-SAN）的域/IP列表。
Wildcard: `.example.com"-方便于多个子域,需要DNS验证。
OCSP stapling：服务器应用新的召回状态；减少对外部OCSP的延迟和依赖。
HPKP：已过时/未使用；取而代之的是CT博客和关键卫生。
CT（证书透明）：公开签发日志对于控制假发布很重要。

密码和密钥

算法：

ECDSA（P-256）-快速而紧凑；是现代客户的首选。
RSA-2048/3072-仍然更兼容；可以保留双证书（RSA+ECDSA）。
密钥生成：仅在目标方（不通过网络传输私有者），保护访问权（"0600"）。
HSM/KMS：对于关键区域（支付/PII）,将密钥存储在HSM/KMS,包括操作审核。
寿命：短期证书（90天/30天内）鼓励频繁轮换,并降低损害风险。

TLS管理体系结构模型

1.通过ACME进行公共CA（Let's Encrypt/Buypass/等）

验证：HTTP-01（通过Web 服务器/Ingress）或DNS-01（用于通配符/非直接域）。
优点：免费/自动化,广泛的信任。缺点：外部依赖。

2.内部企业CA

工具：HashiCorp Vault PKI，Smallstep（step-ca），Microsoft AD CS，CFSSL。
优点：定制策略、mTLS、短TTL、内部域发布。缺点：根分布，信任管理。

3.混合动力车

面向外部用户的公共CA；内部CA用于服务K服务（mTLS），集群间频道和海军上将。

自动扩展模式（更新）

一般原则

延期门槛：在到期前"≤ 30"天开始；对于关键服务-在'≤ 45'天。
Zero-downtime：发布新证书，原子替换，流畅的重新发布而不会断开连接。
双重保留（蓝色/绿色）：存储当前和下一个证书；切换-通过symlink或转换后的秘密。
警告：每天45/30/14/7/3；ACME挑战失败时的单独警报。

ACME客户端及其应用

certbot / acme.sh/lego： VM/bare-metal上的轻型代理。
cert-Manager （Kubernetes）：使用Issuer/ClusterIssuer的操作员；自动化发布/更新并写入Secret。
step-ca/Vault Agent：自动发布/旋转,TTL短,sidecar模式,用于密钥和链更新。

Kubernetes的流程

证书管理器（通过Ingress HTTP-01 Let's Encrypt的Issuer示例）：

yaml apiVersion: cert-manager. io/v1 kind: ClusterIssuer metadata:
name: le-http01 spec:
acme:
email: devops@example. com server: https://acme-v02. api. letsencrypt. org/directory privateKeySecretRef:
name: le-account-key solvers:
- http01:
ingress:
class: nginx

证书请求：

yaml apiVersion: cert-manager. io/v1 kind: Certificate metadata:
name: app-cert namespace: prod spec:
secretName: app-tls dnsNames:
- app. example. com issuerRef:
name: le-http01 kind: ClusterIssuer privateKey:
algorithm: ECDSA size: 256 renewBefore: 720h # 30 дней

当"秘密"更新时，NGINX-Ingress中的热交换会自动发生。添加"ssl-ech-curve： secp 256r1", 并通过注释/ConfigMap启用OCSP stapling。

VM/Bare-metal的流程

Certbot (HTTP-01):

bash sudo certbot certonly --webroot -w /var/www/html -d example. com -d www.example. com \
--deploy-hook "systemctl reload nginx"

通过系统计时器定期进行"certbot renew"。
对于通配符，请使用DNS-01（插件提供商）和类似的"-deploy-hook"。

acme.sh (DNS-01, wildcard):

bash export CF_Token="" # example for Cloudflare acme. sh --issue --dns dns_cf -d example. com -d '.example. com' \
--keylength ec-256 --ecc \
--reloadcmd "systemctl reload nginx"

NGINX： 核替代品

存储'fullchain。pem` и `privkey.在稳定的路径下（symlink to version files），然后是"nginx -s reload"。

🚨 Check Alignment of PKI和mTLS

HashiCorp Vault PKI（角色示例）：

bash vault secrets enable pki vault secrets tune -max-lease-ttl=87600h pki vault write pki/root/generate/internal common_name="Corp Root CA" ttl=87600h vault write pki/roles/service \
allowed_domains="svc. cluster. local,internal. example" allow_subdomains=true \
max_ttl="720h" require_cn=false key_type="ec" key_bits=256

自动输出：通过Vault Agent Injector（K8s）或sidecar；应用程序从文件/FS-watcher重新读取证书。
短TTL：24-720小时，刺激频繁旋转，降低被盗钥匙的价值。
mTLS：为特定服务/角色颁发客户端证书；入口-ingress/sidecar-proxy中的mutual TLS。

安全操作

保密共享：私钥仅在主机/子上,访问权限最低。
文件权限："600"用于密钥；所有者是流程用户。
Grace时期：在安装"renewBefore"时足够考虑到DNS/ACME/提供程序故障。
OCSP Stapling：包括在前面；监测反应的新鲜度（通常为12-72小时）。
HSTS：逐步启用（开始时没有"preload"），确保正确交付所有内容的HTTPS。
双证书（RSA+ECDSA）：提高互操作性和性能；向现代客户提供ECDSA。

监控和SLO

指标和检查：

每个域/密的到期日前（gauge）；SLO："expiry之前7天没有证书。"
链的有效性（linting），SAN 与所需域/IP匹配。
OCSP稳定状态（响应新鲜）。
成功/失败的ACME挑战赛的比例。
Leitensi TLS握手，协议/密码版本（审核）。

Alerta（级别示例）：

Warn：到期前30天。
Crit： 7天/失败"renew"。
Page：72小时/无效连锁店/没有OCSP stapling。

事件和回滚

证书逾期：手动临时超额释放,固定RCA（为什么更新、DNS 锁定/API限制不起作用）。
密钥危害：立即重新发布/召回,保密轮换,访问审核,DNS 提供商/ASME帐户令牌轮换。
不正确的链条：正确的"fullchain"的紧急丢弃，强制释放前线。
锁定到DNS提供程序：保留备用验证路径（HTTP-01）或次要DNS。

汽车销售实施支票

1.选择一个模型（通过ACME/内部 PKI/混合动力车公开的 CA）。
2.定义cryptoprophil： ECDSA-P256，如果需要，与RSA-2048双证书。

3.配置自动代理（cert-Manager, certbot, acme.sh, Vault Agent).

4.组织零时速更换（symlink模式，热释放输入/NGINX/Envoy）。
5.启用OCSP stapling和HSTS（分阶段）。
6.增加挑战的时间和状态的变化；拼出SLO。
7.记录破玻璃和手动释放过程。
8.进行"假"演习：破碎的DNS-01，ACME的下降，过时的根/中间。
9.重新定义私有密钥的访问权限、运行DNS提供商令牌和ACME帐户。

iGaming/fintech的功能

PCI DSS/PII：严格的Cipher Suites，强制性TLS 1。2+/1.3、关闭弱密码/压缩,会话恢复,无安全权衡。
域细分：支付子域和海军上将的单独证书；对于内容提供商-隔离链。
审核和编写：记录发布/召回/轮换；签名CI/CD文物。
多区域性：每个区域的本地Issuer-y，以免依赖于跨区域故障。

配置示例

NGINX (RSA+ECDSA, OCSP stapling)

nginx ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_ecdh_curve secp256r1;

ssl_certificate   /etc/nginx/certs/app_ecdsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_ecdsa/privkey. pem;
ssl_certificate   /etc/nginx/certs/app_rsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_rsa/privkey. pem;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=31536000" always;

OpenSSL: CSR (ECDSA-P256)

bash openssl ecparam -name prime256v1 -genkey -noout -out privkey. pem openssl req -new -key privkey. pem -out csr. pem -subj "/CN=app. example. com" \
-addext "subjectAltName=DNS:app. example. com,DNS:www.example. com"

CFSSL： 简介和发行

json
{
"signing": {
"profiles": {
"server": {
"usages": ["digital signature","key encipherment","server auth"],
"expiry": "2160h"
}
}
}
}

bash cfssl gencert -profile=server ca. json csr. json      cfssljson -bare server

FAQ

需要通配符吗？
如果经常出现新的子域-是（通过DNS-01）。否则,对于显式域使用多个SAN。

选择什么： cert-Manager或certbot?

Kubernetes → cert-manager.K8s外的VM/微服务 → certbot/lego/acme。sh.内部PKI → Vault/step-ca。

TTL可以减少到一天吗?

对于内部mTLS-是的，如果自动化/sidecar保证轮换，应用程序知道如何热重置。

如何确保DNS-01安全？
单独的令牌/最小区域访问、密钥旋转、限制IP API访问、进行审核。

底线

可靠的TLS控制是正确的密码处理，自动发布和扩展，零时间轮换，可观察性和清晰的事件重构程序的组合。建立ACME/PXI流水线，添加严格的排气管道，并定期训练"紧急"脚本-过期证书将不再是夜间寻呼机的来源。