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流水線，添加嚴格的排氣管道，並定期訓練「緊急」腳本-過期證書將不再是夜間尋呼機的來源。