前面那段时间，我被叫去帮忙看一个很典型的线上问题：主站首页能打开，但用户下单、查订单、调接口全部失败，前端控制台一片飘红，报的都是证书校验不通过。运维同学的第一反应是"证书过期了"，查了一圈发现有效期还有大半年；第二反应是"是不是被运营商劫持了"，这个方向又跑偏了。真正的原因说出来有点尴尬——负载均衡上只配了站点自己的证书，中间证书漏掉了，桌面浏览器因为本地缓存过中间证书所以看着一切正常，而手机端和一部分客户端没有缓存，握手直接失败。

这件事之后我把团队的 HTTPS 配置标准重写了一遍。借这个机会，系统地把 HTTPS 详解一遍：它到底防住了什么，握手过程里那些随机数和公钥各起什么作用，证书链是怎么一级一级验到根的，TLS 1.3 相比 1.2 砍掉了哪些东西又付出了什么代价，以及服务端从申请证书到上线自检的完整动作。这篇内容写给所有需要把 HTTPS 配明白的人——不管是刚接手站点配置的新同学，还是已经能背出握手流程但没踩过真实坑的老手，都能从里面找到能直接用的结论和排查思路。

1. HTTPS 到底在防谁：先把威胁模型摆清楚

聊技术细节之前必须先明确一个问题：HTTPS 的存在意义不是"让地址栏有个小锁"，而是对抗一组非常具体的攻击者。如果你不清楚对手能做什么，后面所有的配置取舍都会变成机械照抄，出了问题也不知道从哪个环节查起。

1.1 明文 HTTP 的三类现实风险

在一条完全明文的链路上，数据从用户到服务端要经过家庭路由、楼道交换机、园区出口、运营商骨干、CDN 节点、机房入口等多个环节，任何一个环节的持有者都能看到完整报文。最直接的风险是窃听：请求体里的账号、手机号、订单金额、会话凭证全部以可读文本暴露，公共网络环境下这类监听的成本低到几乎为零。

第二类是篡改。中间环节不光能看，还能改——往返回的页面里插一段脚本、把下载链接换成另一个地址、把接口返回的价格改掉，用户端完全无法感知。早年间不少"莫名其妙弹出广告"的现象，本质就是明文流量被人动了手脚。

第三类是冒充。攻击者伪造一个和真实站点几乎一样的页面，或者把用户的请求导向一台假的服务器，用户输入的密码直接就进了别人的口袋。这三类风险对应到密码学上，就是机密性、完整性和身份认证三个目标，HTTPS 的全部设计都围绕这三个词展开。

1.2 HTTPS 的三根支柱与各自的实现方式

机密性由加密保证，但这里用的不是一把钥匙开到底的算法，而是混合加密：握手阶段用非对称算法协商出一个只有通信双方知道的临时密钥，之后所有业务数据都用这个临时密钥做对称加密。完整性由消息认证码或认证加密算法（AEAD）保证，每个加密记录都带一个校验标签，改动任何一个比特都会导致校验失败，连接被立即中断。

身份认证是最容易被低估的一环，它靠证书体系完成——服务端出示一张由第三方机构签发的证书，证明"我确实是这个域名的主人"，客户端则用本地预置的信任根去验证这张证书的签名链条。三者缺一不可：只加密不认证，等于把保险箱的钥匙交给一个伪装成快递员的人；只认证不加密，等于验完身份之后当街宣读机密。

1.3 一个常被忽略的前提：信任锚点从哪来

证书体系的安全性最终落在一个问题上：客户端凭什么相信那个"第三方机构"？答案朴素到有点让人不安——因为操作系统和浏览器在出厂时就内置了一份受信任的根证书列表，这些根证书的公钥就是整个体系的信任锚点。你的站点证书之所以被认可，是因为能一路签名验证到某个预置在信任库里的根。

这意味着两件事。一是自签证书在公网环境永远不可信，不是技术上有缺陷，而是它不在任何信任库里。二是信任库是可以被人工修改的，企业内部为了内网系统自签证书能正常使用，经常会下发私有根证书到员工设备，这在受控环境下是合理做法，但也说明"证书验证通过"这件事的强度取决于信任库的干净程度。理解到这一层，你再看客户端报错信息就不会一头雾水了。

2. 混合加密的密码学底座：为什么不能只用一种算法

"既然非对称加密能解决密钥分发问题，为什么还要绕一圈用对称加密？"这是我带新人时被问得最多的问题之一。答案很实在：非对称算法慢得离谱，而且能加密的数据长度有限，直接拿它传业务数据在性能上完全不可接受。

2.1 对称与非对称的能力边界

对称加密（如 AES、ChaCha20）加解密用的是同一把密钥，速度极快，现代处理器上还有专门的指令集加速，吞吐能做到每秒数 GB，但它的死穴是密钥怎么安全地送到对方手里——你总不能把密钥明文写在第一个数据包里发过去。

非对称加密（如 RSA、椭圆曲线算法）用公钥加密、私钥解密，公钥可以随便公开，天然解决了分发问题，但代价是运算开销大几十倍到上百倍，而且 RSA 一次能加密的数据量受模长严格限制，2048 位密钥最多也就加密两百多字节。所以工程上的标准做法是把两者拼起来用：用非对称算法解决"临时密钥怎么安全协商"的问题，用对称算法解决"业务数据怎么高速加密"的问题。

注意：这里的"非对称算法"在现代 TLS 里主要不是用来加密，而是用来做密钥协商和数字签名。密钥协商允许双方各自算出同一个共享秘密而不需要把它发到网络上，签名则用来证明握手消息确实来自持有证书私钥的那一方。

2.2 握手阶段实际交换了什么

以最常见的临时椭圆曲线密钥交换为例，把一次握手里与密钥相关的东西摊开看，其实只有三样：客户端生成一个 32 字节的随机数并发送，服务端也生成一个 32 字节随机数并发送，然后双方各自现场生成一对临时密钥，互相交换公钥。客户端拿到服务端公钥、结合自己的私钥，算出一个共享秘密；服务端拿客户端公钥、结合自己的私钥，算出的结果完全相同。

这个共享秘密从头到尾没有在网络上传输过，中间人即使截获了双方交换的公钥，没有对应的私钥也算不出来。两个随机数的作用是防止重放——每次握手的随机数都不一样，算出来的会话密钥也就不一样，攻击者录下昨天的一整段加密流量，今天没有任何复用价值。

2.3 从共享秘密到会话密钥：密钥派生的必要性

算出来的共享秘密并不能直接当密钥用。原因有两个：一是不同算法的密钥长度要求不同，共享秘密的位数未必匹配；二是握手过程中需要的密钥不止一把——客户端发数据用一把，服务端发数据用一把，还要各自配一个初始向量，四把密钥都得从同一个源头派生出来但不能相同。

所以协议里定义了一套密钥派生函数，输入是共享秘密加上双方随机数，输出是一个密钥块，从中切出客户端写密钥、服务端写密钥、客户端写初始向量、服务端写初始向量。TLS 1.2 用的是基于哈希的消息扩展函数，TLS 1.3 换成了更现代的提取-扩展两段式结构，每一把密钥都有独立的标签，杜绝了密钥之间相互推导的可能。这个设计细节看着枯燥，但它决定了整个加密体系的强度上限。

2.4 前向保密：为什么必须用临时密钥

早期 TLS 有一种做法是用服务端证书里的 RSA 公钥直接加密预主密钥发过去。这种模式的问题在于：一旦服务端私钥泄露，攻击者可以解密他历史上录下的所有流量——因为他只需要用私钥解开每个连接里的预主密钥。

临时密钥交换彻底改变了这一点。每次握手都现场生成一对一次性密钥，用完即弃，握手结束后私钥就销毁了。即便某天服务端证书私钥真的泄露，攻击者也只能冒充站点去骗未来的连接，对已经录下来的历史流量无能为力。这就是前向保密。现在的主流实践里，静态 RSA 密钥交换已经因为缺乏前向保密能力被完全淘汰，选密码套件时看到不带 ECDHE 字样的组合，基本可以直接划掉。

3. 证书与信任链：身份认证是怎么一步步落地的

加密只保证"别人看不懂"，但没法保证"对面是谁"。真正的身份认证靠证书完成，而证书的核心是一句话：某个受信任的第三方，用它的私钥给你的公钥和域名绑定关系签了个字。

3.1 一张证书里到底装了什么

证书的实质是一段结构化的二进制数据，核心字段可以拆成下面几块。看懂了这些字段，你在排查证书问题时就不会只会说"证书有问题"。

有一点要特别提醒：主体字段里的通用名称早已不参与域名匹配，现代客户端一律只看 SAN 扩展。有些老工具生成的证书把域名只写进通用名称、SAN 留空，桌面浏览器可能勉强大意放过，移动端和很多客户端库会直接拒绝。这是自制证书时踩得最多的一个坑。

3.2 证书链验证的完整流程

客户端拿到服务端下发的证书后，做的事情并不是"看看有没有过期"这么简单，而是一套完整的链式验证。第一步，检查服务端发来的证书是不是自己的、域名对不对、有效期覆盖当前时间。第二步，从这张叶子证书往上找签发者，用签发者的公钥去验证叶子证书上的签名。

第三步最关键：如果签发者不是本地信任库里的根，就要继续往上找，直到某张证书的签发者出现在信任库中。这个"往上找"的动作，依赖的就是服务端在握手时把中间证书一并发下来。第四步，检查链上每一张证书的有效期、基本约束、密钥用途是否合规——中间证书必须明确标识自己是中间证书，否则不能用来签发下级。

最后一步是吊销状态检查：证书是否被签发方提前作废。整条链走通，身份认证才算完成。

这里就回到开头那个事故：服务端只发了叶子证书，没发中间证书。桌面浏览器因为之前访问过同类站点，本地缓存了那张中间证书，能自己把链接上；手机端是全新的环境，链断在中间，握手失败。两边表现不一致，排查时极容易误判。

实操心得：配置证书时永远要配完整链文件，即叶子证书在前、中间证书在后拼接成一个文件，而不是只配叶子证书。上线前用一台干净的设备或一个没有缓存的客户端验证一次，能避开九成的"部分用户打不开"问题。

3.3 域名匹配、通配符与吊销检查的真实成本

域名匹配有几个容易搞错的细节。通配符证书只能匹配一级标签：*.某域名能覆盖a.某域名，但覆盖不了a.b.某域名。另外通配符不能用在顶级标签位置，也不能匹配空标签。多域名站点建议直接用 SAN 扩展列出所有需要的域名，一张证书管多个名字，比维护一堆单域名证书省心。

吊销检查在工程上是个麻烦事。撤销列表文件体积大、更新有延迟，靠它拦住已泄露的证书并不现实；在线查询虽然实时，但每次握手多一次外部请求，会把首字节时间拖慢，而且查询行为本身暴露了用户正在访问哪个站点。折中的方案是服务端主动去查询并把结果缓存下来，握手时直接随证书一起下发给客户端，客户端就不需要再单独发请求。

这个机制叫 OCSP 装订（Stapling）。它同时解决了延迟和隐私两个问题，代价是服务端要维护这份缓存。装订配置不当（比如上游查询超时没兜底）会导致握手变慢甚至失败，所以上线后要盯着握手耗时的分位值看。

4. 握手流程全景：TLS 1.2 和 1.3 差在哪

协议版本的选择直接影响首屏速度和安全性，但很多人只会照着"要求 TLS 1.2 以上"这句话抄配置，并不知道 1.3 到底改了什么。把两个版本的握手段落摆在一起对比，差别一目了然。

4.1 TLS 1.2 完整握手逐步拆解

一次不使用会话复用的 TLS 1.2 握手，需要两个完整往返才能开始传数据。按顺序大致是这些步骤：

1. 客户端发送问候消息，包含客户端随机数、支持的密码套件列表、支持的曲线列表、签名算法列表，以及扩展字段（域名指示、应用层协议协商等）。
2. 服务端回应问候消息，包含服务端随机数、最终选定的密码套件。
3. 服务端下发证书（完整链），必要时附带临时密钥交换参数，并用证书私钥对"两个随机数 + 密钥交换参数"做签名，证明自己确实持有私钥。
4. 服务端宣告问候阶段结束。
5. 客户端验证证书链，校验签名，生成自己的临时密钥对并发送公钥。
6. 双方各自算出共享秘密，派生会话密钥。
7. 双方分别发送"切换加密规格"提示，再发送完成消息，完成消息里带着对之前所有握手消息的哈希摘要，用来确认握手中途没有被篡改。
8. 开始传输应用数据。

注意到第 3 步和第 5 步各占半个往返，加起来就是两个往返。第 7 步的完成消息是整个握手的安全收口，任何一步被中间人动过手脚，两边的摘要都对不上，握手立刻终止。

4.2 TLS 1.3 做的减法与代价

TLS 1.3 把完整握手压缩到一个往返。它做的最重要一件事是：客户端在第一条消息里就把自己猜测的密钥交换公钥带上了。服务端收到后立刻能算出共享秘密并回自己的公钥，第二条消息之后所有内容——包括证书、证书验证、完成消息——全部在加密通道里传输。

这个改动带来两个好处。一是省了一个往返，跨地域访问时能省几十到上百毫秒。二是证书不再明文暴露，被动监听者无法从握手流量里看出你访问的是哪个站点（域名指示字段仍是明文，这是另一个话题）。同时 1.3 删掉了大量历史包袱：静态 RSA 密钥交换、CBC 模式的套件、RC4 和 DES 这类老算法、压缩、以及部分重协商能力，全部移除，只保留认证加密套件。

代价也有。如果客户端猜错了曲线，服务端会回一个"重试请求"让客户端用正确参数重来，握手就会退化成两个往返。所以服务端支持的曲线列表和客户端常用曲线要尽量对齐，主流选择集中在 X25519 和 P-256 上，配置时把这两个放前面基本不会踩坑。

4.3 0-RTT 与会话恢复：快是有代价的

会话恢复的思路是：客户端记住上一次握手协商好的密钥材料，下次连接时直接用它加密第一条消息，省掉协商过程。TLS 1.2 时代这靠会话标识或会话票据实现，TLS 1.3 把它统一成预共享密钥恢复机制。

TLS 1.3 的 0-RTT 更进一步，客户端在第一条消息里就带上了加密的应用数据，服务端理论上可以立刻处理，零往返延迟。听起来很香，但有个必须说清楚的限制：0-RTT 的数据可以被重放。攻击者录下这段加密数据，隔一段时间原样重发一次，服务端无法从密码学上分辨它是新的还是重放的。

所以工程上的通行做法是：只允许幂等请求走 0-RTT，比如首页加载、静态资源获取；涉及下单、支付、状态变更的请求一律等握手完成后再发。另外恢复用的票据密钥需要定期轮换，否则一张票据被泄露的影响时间会被无限拉长。这个轮换周期一般在几小时到一天之间，太频繁会降低恢复命中率，太懒惰则失去意义。

5. 服务端落地：从证书申请到配置上线

前面讲的都是原理，落到操作层面其实是一串很固定的动作。我带过的团队里，凡是把 HTTPS 配得三天两头出问题的，基本都是跳过了其中某一步没有固化下来。

5.1 证书申请路径怎么选

现在拿证书基本不用手工递交材料了，主流方式是走自动化签发协议。核心思路是：客户端向签发方证明"我控制着这个域名"，签发方验证通过后自动下发证书，整个流程可以脚本化，到期前自动续期。证明域名控制权的方式有三种，选哪种取决于你的部署形态。

泛域名证书只能通过 DNS 验证签发，因为它需要证明你控制的是整个域，而不是某一个具体主机名。这一条经常被忽略，有人拿着 HTTP 验证的脚本去签泛域名，卡在那里半天不知道为什么失败。

从证书类型看，只验证域名控制权的是域名型证书，签发快、自动化程度高，绝大多数站点用这个就够。再往上的组织型证书需要人工核验主体信息，签发周期长，一般用于对主体展示有明确要求的场景。选购时不必迷信更高级别一定更好，先把自动化续期做扎实，比多花钱买类型更实际。

5.2 服务端配置的关键参数

配置项不多，但每一项都有明确目的。下面这段示意写了最核心的几组，具体指令名按你用的软件对照文档替换，思路是通用的。

# 协议版本：只保留 1.2 与 1.3，禁用历史版本 protocol_versions enabled = 1.2 1.3 # 密码套件：优先认证加密 + 临时密钥交换 cipher_suites = (TLS1.3 默认套件) ECDHE-ECDSA-AES128-GCM ECDHE-RSA-AES128-GCM ECDHE-ECDSA-CHACHA20 ECDHE-RSA-CHACHA20 # 证书：必须下发完整链（叶子在前，中间在后） certificate_chain = fullchain.pem private_key = privkey.pem # 吊销状态装订：减轻客户端查询负担 ocsp_stapling = on ocsp_cache_ttl = 1h # 会话票据密钥轮换：兼顾恢复命中率与泄露风险 session_ticket_rotate = 12h # 强制跳转：所有明文请求 301 到加密端口 redirect_http_to_https = on

有几个参数需要展开说。协议版本只留 1.2 和 1.3 是当前的标准做法，1.0 和 1.1 早已被主流客户端弃用，保留它们只会给降级攻击留口子。密码套件的顺序有价值，把认证加密和临时密钥交换的组合放前面，等于告诉服务端优先选这些，虽然最终是客户端主导选择，但服务端的偏好列表能影响不少客户端的决策。

静态资源响应头的配置也常被忽略。启用严格传输安全策略能让浏览器在指定时间内强制用加密方式访问该域名，配合子域包含和预加载列表可以进一步压缩降级空间。但这个头一旦下错就是灾难——比如给一个还有大量明文子域的站点加了子域包含，那些子域会直接被浏览器拒绝访问。上线前一定要把域名资产盘一遍。

注意：严格传输安全策略的生效时间以年计，而且是不可撤销的（用户浏览器记住了就是记住了）。第一次上线时把有效期设短一点，比如几百秒，观察一周没有异常再逐步拉长，这个习惯能救你一命。

5.3 上线后的自检清单

配完不等于配对。每次变更证书或配置后，我会固定跑一遍下面这组检查，几分钟的事，能挡住绝大多数低级事故。

• 用一个没有缓存的全新客户端访问站点，确认不报任何证书警告。
• 确认服务端下发的证书链是完整的，叶子证书后面跟着中间证书，数量正确。
• 检查证书覆盖的域名列表是否包含当前访问的全部主机名，包括带 www 和不带 www 的。
• 确认明文请求能正确跳转到加密地址，跳转状态码是永久跳转而不是临时跳转。
• 检查页面引用的所有外部资源（脚本、样式、图片、字体、接口）是否都是加密地址，控制台不能有混合内容告警。
• 确认协议版本下限生效，主动用旧版本协议去连，应当连接失败。
• 检查严格传输安全策略头的有效期、子域包含、预加载标记是否符合当前阶段预期。
• 验证自动续期脚本能跑通，用一个临时域名完整走一遍签发流程。
• 记录握手耗时的分位值基线，方便后续比对是否有劣化。

清单里第九条最容易被跳过，但它是一个长期主义的动作。HTTPS 的性能问题往往不是突然出现的，而是某次证书链变长、某个中间证书换成了更长密钥、装订缓存失效之后，握手时间悄悄多了一截。有基线才能发现。

6. 常见故障与排查实录

HTTPS 的故障有个特点：现象高度相似，原因千差万别。浏览器上都显示"您的连接不是私密连接"，背后可能是证书过期、域名不匹配、链不完整、时间不同步、协议不兼容，甚至只是本机系统时间错了。学会分层定位比背答案重要得多。

6.1 证书链不完整：最隐蔽的一类问题

这类故障的典型特征是"部分用户能打开"。桌面浏览器因为访问过的站点多，本地缓存了各种中间证书；移动端、命令行客户端、某些语言的网络库则是干净环境，链一断就失败。更麻烦的是有些客户端会尝试自己去补全链，补全成功就正常，补全失败就报错，表现随机。

判断方法很直接：用一个干净的客户端去连，看服务端下发的证书链里有几张证书。如果只有一张，而签发方不是根机构，那基本可以确定缺了中间证书。修复方式是把中间证书拼到叶子证书后面，顺序不能反——反了部分客户端会解析失败。

还有一种变体是链上混入了多余的证书。有些教程教你"把所有证书都拼进去"，结果把根证书也配上了，反而增大了握手包的体积，某些客户端还会因为链路径存在歧义而报错。正确做法是只配叶子加中间，根证书由客户端自己从信任库里找。

6.2 时间、域名与协议版本：三个高频误判点

时间不同步是最冤的一类。服务端或客户端任何一边的系统时间偏移超过证书有效期范围，验证就会失败。容器化部署尤其容易遇到，镜像启动时如果依赖外部时间同步且同步失败，就会出现"昨天还好的，今天突然全挂"。排查时先看两边时间差，比看证书本身快得多。

域名不匹配往往发生在证书换了但配置没跟上的时候。比如站点从www.某域名迁移到裸域，证书 SAN 里没加裸域，访问裸域就报错。或者反向代理上有多个站点，默认站点没有配域名指示扩展，客户端连上来拿到的是默认站点的证书，域名自然不匹配。这类问题的特征是"直接访问 IP 或者用某个特定域名访问才出错"，可以据此缩小范围。

协议版本不兼容在老旧客户端上依然存在。有些内网设备、老版本客户端库只支持 1.0 或 1.1，你把下限提到 1.2 之后它们就连不上了。这时候不是简单地把下限调回去，而是要评估这些客户端能否升级，或者为它们单独保留一个受限入口并明确记录技术债。安全配置的收紧一定要有灰度过程和数据支撑。

6.3 混合内容与跳转环路

页面本身走加密，但里面引用了一个明文的脚本或图片，浏览器会拦截或告警，这就是混合内容。它不导致握手失败，但会让地址栏的安全标识失效，某些严格策略下功能直接被阻断。排查方式是打开控制台看告警列表，把里面所有明文地址改成加密地址或者改成协议相对写法。

跳转环路则是配置错误的经典产物：反向代理把明文请求跳转到加密端口，但代理和后端之间的转发头没配对，后端以为请求还是明文的，又跳一次，形成无限循环。现象是浏览器报"重定向次数过多"。修复的关键是让后端能正确识别原始请求的协议，通常靠代理层传递的协议标识头，后端据此判断是否需要跳转。

6.4 排查速查表

下面这张表是我这些年攒下来的，按"现象"索引比按"原因"索引好用得多。

还有一条经验值得单独讲：排查时优先用命令行客户端而不是浏览器。浏览器会缓存证书、走代理、应用各种策略，变量太多；命令行客户端能直接把服务端下发的证书链、协商出的协议版本和套件打印出来，信息干净得多。一条连接命令加上详细输出，往往比在浏览器里点半天设置快十倍。

7. 性能与安全的取舍：别把 HTTPS 当成纯开销

有个流传很广的说法是"上了 HTTPS 网站会变慢"。这话在十年前有一定道理，放到今天基本站不住脚——现代硬件上的加密开销可以忽略，真正的成本在握手往返和证书体积上，而这两项都有明确的优化手段。

7.1 握手开销的量化与优化路径

一次完整握手在 TLS 1.2 下需要两个往返，TLS 1.3 下一个往返。假设用户与服务端之间的往返时延是 40 毫秒，那么 TLS 1.2 光握手就要 80 毫秒，1.3 只要 40 毫秒。如果再叠加会话恢复，第二次访问可以做到零额外往返（1.3 的 0-RTT）或者一个往返（常规恢复）。

优化顺序应该是：先升协议版本，再开会话恢复，最后才考虑证书算法。很多团队一上来就纠结换什么证书，却把协议版本留在 1.2，等于捡了芝麻。会话恢复的命中率也值得监控，如果票据密钥轮换太频繁或者多台服务器之间密钥不同步，命中率会掉到很低，恢复机制形同虚设。多机部署时要确保票据密钥在所有节点间共享，否则用户每次命中不同节点都要重新完整握手。

7.2 证书算法的选择：体积和兼容性的平衡

同样是 2048 位强度，椭圆曲线证书的体积比 RSA 证书小一大截。握手时证书是明文（1.2）或半明文传输的，体积直接影响前几个包的传输时间，在弱网环境下差异明显。椭圆曲线证书的另一个优势是签名验证更快，服务端在握手高峰期的 CPU 压力更小。

代价是兼容性。非常老的客户端可能不支持椭圆曲线，不过这个范围在持续缩小。比较稳妥的做法是双证书部署：同时配置一张 RSA 证书和一张椭圆曲线证书，让服务端根据客户端的能力自动选择。这样新客户端享受小体积和快验证，老客户端也不至于连不上。配置复杂度增加不多，收益很实在。

7.3 部署形态带来的差异

证书放在哪一层，决定了优化手段能不能用上。放在负载均衡或 CDN 上，能做统一管理、集中装订、快速轮换，但要注意和后端之间的转发是否还保持着加密，以及原始协议信息有没有正确传递。放在应用服务器上，配置灵活但规模一大就难以统一，容易出现某台机器漏配、某台机器证书版本旧的情况。

我个人的偏好是证书终止在离用户最近的那一层，同时保证内网段也走加密或者有明确的边界防护。这样证书轮换只改一处，监控指标也集中。代价是内网流量多一层加解密开销，但在现代硬件上这个开销通常是可接受的，换来的是运维复杂度的大幅下降。

最后分享一个我在实际配置中养成的习惯：把证书到期时间做成一个会主动报警的监控项，提前三十天、七天、一天各报一次，而不是依赖日历提醒或者某个人的记忆。自动续期脚本一定会有失败的时候——权限变了、验证路径被新加的路由规则挡住了、DNS 接口的凭据过期了——这些都不是脚本本身的问题，而是环境在变。有监控兜底，才有可能在证书真正过期之前发现。上面那个凌晨的事故，如果当时有这么一条报警，根本不会发生。