2022 年我接手一个跨境电商平台 主站 api.shop.com 加 30 个子域名 wildcard 证书一张主域名证书加几张子域 全是手工在云厂商面板买的 DV 证书 一年到期手工 renew。我刚接手时觉得这套也能跑 直到我陆续踩了一堆坑。第一种最让我傻眼 某天凌晨 4 点主站告警 用户访问全部 ERR_CERT_DATE_INVALID 证书过期了一个小时 我赶紧上云厂商续费 重新签发 再 deploy 到 5 台 Nginx 上线 总共耗时 90 分钟 业务损失 30 万。第二种最难缠 一个子域名 pay.shop.com 我们换了 CA 提供商 证书私钥不一样 但有一台 Nginx 配置没更新 用户访问随机命中老的 Nginx 一会儿能登录一会儿不能 排查了两天。第三种最离谱 我们的 ELB 上挂了 SSL 后端 Nginx 也跑 TLS,在 HTTP 之上加一层 TLS 加密,防止中间人窃听和篡改。">HTTPS 配置 Strong Cipher 这套配置 OpenSSL 1.0 跟 1.1 默认行为不同 升级系统后某些老 Android 用户访问全部 SSL handshake 失败 客服收到一堆投诉 排查发现是 cipher 列表与协议版本配置不兼容。第四种最致命 我们某个内网 API 用自签证书 应用代码里写死了 verify=False 一年后这个习惯被复制到外网调用 我们的支付网关因此被中间人攻击 一笔 8 万订单的资金流向被截改 才发现是 SSL 证书没校验。第五种最莫名其妙 同一个 Let's Encrypt 证书 在 Nginx 上跑正常 在 HAProxy 上 SSL labs 评分只有 B 排查是 HAProxy 默认不支持 ECDSA 证书 配置要单独调。我盯着这一连串问题想了很久才彻底想明白第一版错在一个根本的认知上我以为 HTTPS 就是买张证书 配 Nginx 监听 443 就完事 可这个认知是错的真正能扛业务的 TLS 是一个 证书自动签发与轮转 加 多 SAN 与 wildcard 策略 加 OCSP stapling 加 强 cipher 与 TLS 版本 加 HSTS 与 HPKP 加 中间证书链 加 客户端验证 的整套工程方法论 任何一环没做都可能让你的网站某天突然挂掉或者被中间人攻击本文从头梳理 HTTPS TLS 的工程化要点 ACME 怎么用 cert-manager 怎么配 cipher 怎么选 OCSP stapling 怎么开 HSTS 怎么设 以及一些把 TLS 做扎实要避开的工程坑
问题背景:为什么 HTTPS 不是配 443 就完事
很多人对 HTTPS 的认知是 上传证书私钥 Nginx 配 443 listen ssl 就完事 但生产里你会发现 证书过期没人盯着 多台机器配置漂移 cipher 选错老客户端连不上 中间人攻击因为没校验。问题的根源在于:
- 证书必须自动化:手工 renew 迟早忘 必须 ACME 自动签发 自动轮转 自动 reload Nginx 一次部署管 10 年。
- 多机配置必须一致:同一域名的证书在多台机器上必须同一份 任何一台漂移就会导致随机的 SSL 错误 必须 cert-manager 加 secret 同步。
- OCSP stapling 必须开:不开 OCSP 客户端要主动查 CA 的吊销状态 增加几百毫秒延迟 开了 stapling 服务端把吊销证据带给客户端 一次握手搞定。
- cipher 与 TLS 版本要选:默认配置可能包含弱 cipher 老协议 SSL Labs 评分低 监管合规过不了 必须按 Mozilla intermediate 模板配。
- HSTS 防止降级:没开 HSTS 用户访问 http://shop.com 会被攻击者改成 http 永远不升级到 https 必须 HSTS 加 includeSubDomains。
- 客户端验证不能关:verify=False 是 TLS 自杀 中间人攻击的所有前提都是因为 client 没校验 server 证书 必须 verify=True 加 trusted CA。
一 ACME 自动签发:Let's Encrypt 与 cert-manager
ACME 是 Let's Encrypt 的协议 让证书签发完全自动化 不用人工。生产推荐两种方案 单机用 acme.sh 或 certbot K8s 用 cert-manager 都成熟稳定 我们公司用 cert-manager 一份配置管 200 张证书。
# cert-manager Issuer 配置 用 Let's Encrypt 生产环境
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: ops@mycompany.com
privateKeySecretRef:
name: letsencrypt-prod-key
# DNS-01 challenge 支持 wildcard 比 HTTP-01 灵活
solvers:
- dns01:
route53:
region: us-east-1
hostedZoneID: Z1234567890ABC
selector:
dnsZones:
- mycompany.com
- shop.com
ClusterIssuer 只是声明 怎么向 CA 申请证书 真正的证书资源用 Certificate 描述 cert-manager 看到 Certificate 资源后自动发起 ACME 申请 申请成功后把证书私钥写进 Secret 应用 Pod 直接 mount 这个 Secret 不需要关心签发过程。
# Certificate 资源 cert-manager 自动签发与轮转
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: shop-tls
namespace: production
spec:
secretName: shop-tls-secret
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
duration: 2160h # 90 天 Let's Encrypt 标准
renewBefore: 720h # 提前 30 天续期
subject:
organizations: ['MyCompany Inc']
commonName: shop.com
dnsNames:
- shop.com
- www.shop.com
- '*.shop.com' # wildcard 包含所有一级子域名
- api.shop.com
- pay.shop.com
privateKey:
algorithm: ECDSA
size: 256
rotationPolicy: Always # 每次轮转换新私钥 安全性更好
cert-manager 的工程价值 一份 Certificate 资源声明就管签发 监控到期 自动续期 自动推到 Secret 应用 Pod mount Secret 不用关心证书生命周期 这套机制让我们公司 200 张证书零运维成本。DNS-01 比 HTTP-01 更灵活 支持 wildcard 不需要公网 80 端口 适合内网与 wildcard 场景 缺点是需要 DNS API 权限。
二 Nginx TLS 配置:Mozilla Intermediate 模板
Nginx 的 TLS 配置直接决定 SSL Labs 评分与兼容性。Mozilla 维护了三个等级模板 modern intermediate old 生产推荐 intermediate 兼容 IE 11 macOS 10.12 之后 同时禁用弱 cipher 老协议。
# /etc/nginx/conf.d/tls.conf 全局 TLS 配置
ssl_certificate /etc/letsencrypt/live/shop.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/shop.com/privkey.pem;
# Mozilla Intermediate (2024.05) 兼容性广 安全性高
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
# Session 复用 减少握手开销
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m; # 约 200k 个 session
ssl_session_tickets off; # tickets 有前向安全性问题 关掉
# OCSP Stapling 客户端少一次 CA 查询
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/shop.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
# HSTS 强制 https 不允许降级
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
# 防 BEAST 攻击
ssl_ecdh_curve X25519:prime256v1:secp521r1;
# DH 参数 必须自己生成 2048+
ssl_dhparam /etc/nginx/dhparam.pem;
生成 dhparam 是初始化时的一次性步骤 命令简单但容易被忽略 默认 DH 参数有安全风险 必须本地生成 2048 位以上的参数 让 perfect forward secrecy 真正生效。
# 生成 dhparam 一次性步骤 但必做
openssl dhparam -out /etc/nginx/dhparam.pem 2048
# 验证证书链完整性 缺中间证书会让某些客户端连不上
openssl s_client -connect shop.com:443 -servername shop.com -showcerts < /dev/null
# 看 SSL Labs 评分 目标 A+
curl -s 'https://api.ssllabs.com/api/v3/analyze?host=shop.com'
# 看 OCSP stapling 是否生效
openssl s_client -connect shop.com:443 -status -servername shop.com < /dev/null \
2>&1 | grep -E 'OCSP|Cert Status'
# 看 Nginx 加载的实际证书内容
echo | openssl s_client -connect shop.com:443 -servername shop.com 2>/dev/null \
| openssl x509 -noout -dates -subject -issuer
Nginx TLS 配置的工程经验 ssl_session_tickets off 是个反直觉但重要的选择 tickets 在多机环境下 ticket key 不同步会让 session 复用失效 不如老老实实用 session cache 加 sticky session。ssl_dhparam 默认 1024 位 OpenSSL 会警告 必须自己生成 2048 位以上 这是 Logjam 攻击的修复要点。
三 HSTS 与证书透明度:防降级与防伪造
HSTS HTTP Strict Transport Security 是浏览器记住你的域名 必须用 https 永远不降级 http。这是防中间人攻击的关键。CT Certificate Transparency 是 CA 必须把签发的证书提交到公开日志 你可以监控这个日志看有没有人冒签你的域名证书。
# HSTS 推荐配置 max-age 2 年 includeSubDomains preload
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
# preload 列表加入 一旦加入 即使第一次访问 http 浏览器也强制 https
# 提交地址 https://hstspreload.org/
# 注意 preload 是单向的 加入后想撤销要走 hstspreload removal 流程 几个月
# Content-Security-Policy 防 XSS 中间人脚本注入
add_header Content-Security-Policy "default-src 'self' https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:" always;
# X-Frame-Options 防 clickjacking
add_header X-Frame-Options "SAMEORIGIN" always;
# X-Content-Type-Options 防 MIME sniffing
add_header X-Content-Type-Options "nosniff" always;
# Referrer-Policy 限制 referrer 泄露
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
# Permissions-Policy 关闭不必要的浏览器 API
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
HSTS preload 是单向操作 一旦加入移除需要几个月 必须谨慎评估 比如你的 wildcard 子域名是否都已经 HTTPS 化 否则加入 preload 会让某些子域名彻底访问不了。我们公司有个内部 staging 子域走 http 加 HSTS preload 后 staging 彻底访问不了 花了 3 个月才从 preload list 移除 教训惨痛。CT 监控用 crt.sh 或者 Facebook 的 CT API 定期跑脚本扫描你的域名 看有没有不是你签发的证书。
四 多机器证书同步:cert-manager 之外的方案
不在 K8s 上的多机环境 多台 Nginx 多台 HAProxy 证书必须一致 否则用户随机命中漂移机器会出问题。常用方案有共享存储 NFS 配置管理 Ansible 集中签发 Vault PKI 三种。
# Ansible 方案 acme.sh 在中心机签发 推送到所有 web 机
# /etc/ansible/playbooks/tls-sync.yml
- name: 证书签发与分发
hosts: tls-issuer
tasks:
- name: 签发证书
shell: |
acme.sh --issue --dns dns_aws \
-d shop.com -d '*.shop.com' \
--keylength ec-256 \
--reloadcmd "echo signed"
register: issue_result
- name: 读取证书
slurp:
src: /root/.acme.sh/shop.com_ecc/fullchain.cer
register: cert_content
- name: 读取私钥
slurp:
src: /root/.acme.sh/shop.com_ecc/shop.com.key
register: key_content
中心机签发完拿到证书与私钥 接下来分发到所有 web 机 必须先 nginx -t 校验配置 校验通过才 reload 否则配置错 reload 失败 老进程退出新进程起不来 服务挂掉 这是多机同步最容易踩的坑。
- name: 分发到所有 web 机
hosts: web_servers
tasks:
- name: 写证书
copy:
content: "{{ hostvars['tls-issuer'].cert_content.content | b64decode }}"
dest: /etc/nginx/certs/shop.com.fullchain.pem
mode: '0644'
- name: 写私钥
copy:
content: "{{ hostvars['tls-issuer'].key_content.content | b64decode }}"
dest: /etc/nginx/certs/shop.com.key
mode: '0600'
owner: root
group: root
- name: 校验 Nginx 配置
shell: nginx -t
register: nginx_test
changed_when: false
- name: Reload Nginx
systemd:
name: nginx
state: reloaded
when: nginx_test.rc == 0
多机证书同步的工程经验 必须先 nginx -t 校验配置再 reload 不要直接 reload 一旦配置错 reload 失败 老进程退出新进程起不来 服务挂掉 必须 atomic 替换 校验通过才生效。Ansible 方案适合中小规模 100 台以下 大规模推荐用 Vault PKI 集中管理签发 客户端用 vault-agent 自动获取与轮转 比 Ansible 更细粒度更安全。
[mermaid]flowchart TD
A[域名注册] --> B[DNS 记录配置]
B --> C[cert-manager ACME 请求]
C --> D[DNS-01 challenge]
D --> E[Let's Encrypt 签发]
E --> F[Certificate Secret]
F --> G[Nginx Pod mount]
G --> H[reload sidecar 监听]
H --> I[证书更新自动 reload]
I --> J[OCSP stapling 配置]
J --> K[HSTS header]
K --> L[CT 监控]
L --> M[到期前 30 天自动续期]
M --> C
五 客户端 TLS:requests 与 Go 的正确姿势
客户端 TLS 配置同样重要 verify=False 是 TLS 自杀 让所有中间人攻击成为可能。生产代码必须 verify=True 加 trusted CA 加证书 pinning 严格场景。
# Python requests 正确姿势
import requests
import ssl
import urllib3
# 1 永远不要 verify=False 这是反面教材
# requests.get(url, verify=False) # 绝对不要
# 2 默认 verify=True 用系统 CA bundle
resp = requests.get('https://api.partner.com/v1/orders', timeout=10)
# 3 自定义 CA bundle 内部 CA 签发的服务
resp = requests.get(
'https://internal.api.mycompany.com/v1/data',
verify='/etc/ssl/certs/mycompany-ca.pem',
timeout=10,
)
# 4 mTLS 双向认证 客户端也要证书
resp = requests.get(
'https://mtls.partner.com/v1/data',
cert=('/etc/ssl/client-cert.pem', '/etc/ssl/client-key.pem'),
verify='/etc/ssl/certs/partner-ca.pem',
timeout=10,
)
# 5 证书 pinning 严格模式 不信任 CA 只信特定指纹
class FingerprintAdapter(requests.adapters.HTTPAdapter):
def __init__(self, fingerprint, **kwargs):
self.fingerprint = fingerprint.replace(':', '').lower()
super().__init__(**kwargs)
def init_poolmanager(self, *args, **kwargs):
kwargs['assert_fingerprint'] = self.fingerprint
return super().init_poolmanager(*args, **kwargs)
session = requests.Session()
session.mount(
'https://payment.partner.com/',
FingerprintAdapter('AB:CD:EF:...:99'), # SHA256 fingerprint
)
客户端 TLS 的工程经验 verify=False 必须代码 review 强制禁止 mTLS 与证书 pinning 适合金融 支付等高安全场景 一般业务 verify=True 加系统 CA 足够。我们公司 CI 加了 grep 钩子 提交代码里出现 verify=False ssl._create_unverified_context 直接 reject 这是最有效的预防。
六 TLS 的工程坑:那些文档里学不到的
讲完原理来说几个真实生产里踩过的坑。第一个坑是 证书链不完整 你的证书是叶子证书 中间证书必须一起 deploy 否则某些客户端比如老 Android Java 客户端会因为找不到中间证书 验证失败 必须用 fullchain.pem 不要只用 cert.pem。第二个坑是 时钟漂移 你的服务器时间偏 几小时 证书的 notBefore 还没到 客户端验证失败 必须 NTP 同步 时钟漂移超过 5 分钟就告警。第三个坑是 SNI 与证书匹配 一个 IP 多个域名共享 443 端口 必须 SNI 不然客户端要哪个域名服务端不知道 老客户端不支持 SNI 比如 IE6 XP 这种已经可以忽略。第四个坑是 证书过期监控 自己服务的证书 第三方依赖的 API 证书 内部 CA 根证书 都要监控 我们公司 cert-monitor 跑定时任务 任何即将过期的证书都报警 给运维 30 天反应时间。第五个坑是 私钥泄漏的应急 一旦私钥泄漏 必须立刻吊销证书 重新签发 但 OCSP 缓存 CDN 缓存 客户端缓存可能让吊销不及时生效 必须有完整的应急流程 短 TTL 监控 立即重启等等。
关键概念速查
| 概念 | 含义 | 工程价值 |
|---|---|---|
| ACME | 自动证书协议 | 零运维续期 |
| cert-manager | K8s 证书 operator | 200 张证书一份配置 |
| DNS-01 | DNS 验证 | 支持 wildcard |
| OCSP Stapling | 服务端预带吊销证据 | 减一次客户端往返 |
| HSTS | 强制 https | 防降级攻击 |
| HSTS preload | 首访即强制 | 极致安全 不可逆 |
| Cipher Suite | 加密算法组合 | Mozilla intermediate |
| fullchain.pem | 叶子+中间证书 | 避免链不全 |
| mTLS | 双向证书 | 金融场景必备 |
| CT 监控 | 证书透明度日志 | 防伪造证书 |
避坑清单
- 证书必须 ACME 自动签发 不要手工 buy renew 手工迟早忘 让 cert-manager 或 acme.sh 接管。
- cert-manager renewBefore 设 30 天 给应急留时间 不要拖到最后一天才续。
- Nginx ssl_protocols 只开 TLSv1.2 TLSv1.3 老协议 SSL3 TLS1.0 1.1 全关掉。
- ssl_dhparam 必须自己生成 2048+ 不要用默认 1024 Logjam 攻击有可能。
- OCSP stapling 必开 ssl_stapling on + ssl_trusted_certificate 让客户端少一次往返。
- HSTS max-age 至少 1 年 includeSubDomains preload 前一定要确认所有子域都 https 化。
- 客户端代码 verify=False 必须代码 review 禁止 CI 加 grep 钩子拦截。
- 多机证书必须 atomic 替换 + nginx -t 校验通过再 reload 不要直接 reload。
- 证书链必须用 fullchain.pem 单纯 cert.pem 会让老客户端验证失败。
- 证书过期监控必做 cert-monitor 30 天前告警 任何过期都是生产事故。
总结
HTTPS 这事 很多人的直觉是 买张证书 配 Nginx 443 listen ssl 就完事 这其实是把 我会配 443 监听 和 我能在生产用 HTTPS 扛住高可用零中间人攻击合规审计 混为一谈。前者是会配置 后者是懂 TLS 工程。中间隔着的是 ACME 自动化 cipher 选型 OCSP HSTS 多机同步 客户端校验 整整一套工程方法论。
从原型到生产 你需要做的事远不止 配置 Nginx ssl。你要懂 ACME 怎么自动签发 cert-manager 怎么用 cipher 怎么选 OCSP 怎么开 HSTS 怎么设 客户端怎么 verify mTLS 怎么用。每一项单独看都不复杂 但它们组合在一起 才是一个能扛业务的 HTTPS 体系。少任何一项 都可能让你的网站某天突然挂掉或者被中间人。
我经常用一个比喻来理解 TLS 它有点像快递的保价加防伪。证书是寄件人盖的官方印章 CA 是公证处证明印章真实 OCSP 是公证处随时确认这个印章没被作废 HSTS 是收件人坚持必须见到这个印章才签收 cipher 是包装的封箱方式 强 cipher 是金属密码箱 弱 cipher 是普通纸箱 mTLS 是收件人也要出示自己的身份证。你不能因为有了印章就觉得邮件安全 还要确保印章真实 没作废 收件人愿意只接受加印章的 包装是金属箱不是纸箱 收件人也要验证身份 这才是一整套快递安全。
这套架构最难的地方在于 它的复杂度在静态网站时几乎完全暴露不了。你一个静态 blog 配个证书 用户访问也很顺 觉得 HTTPS 真简单。但真正生产 多机多域名 wildcard 子域 金融合规 老客户端兼容 你才发现 99% 的复杂度都在 那 1% 的边角 case 里 证书过期没人盯 配置漂移 cipher 不兼容 中间证书丢 私钥泄漏。建议任何想做严肃业务的团队 上线前一定要去 ssllabs.com 跑一次评分 目标 A+ 任何低于 A 的项目必须修 千万别等用户来告诉你 那时候可能已经被中间人攻击造成资金损失了。
—— 别看了 · 2026