企业官网建设流程全解析

这条建议我在不同的项目里见过不下十次，几乎每次都是安全扫描报告里的一句原话：“放弃使用sslv2、sslv3协议，请使用tlsv1.2、tlsv1.1版本”。多数人的处理方式很统一：找到配置文件，把协议白名单改成TLSv1.1 TLSv1.2，重启，复扫，报告变绿，收工。但我要先泼一盆冷水——如果你的目标只是让扫描器闭嘴，到这一步确实够了；如果你的目标是真正把传输层的攻击面收窄，那么按这句话字面执行，你大概率会得到一个“看起来合规、实际上仍然脆弱”的系统。

原因不复杂：SSLv2和SSLv3被弃用是十几年前就已经形成共识的事情，而TLS 1.1在2021年也被正式列入了弃用清单，它和TLS 1.0一样存在可被利用的弱点，主流浏览器早就停止支持。也就是说，这条建议的“推荐值”本身已经落后于当前的安全基线。真正合理的落点是TLS 1.2作为下限、TLS 1.3作为首选，把1.0和1.1一起关掉。

下面我把这件事从头拆一遍：为什么要关、怎么摸清现状、各个服务端栈具体怎么改、客户端兼容性怎么兜、改完怎么验证和回滚，以及我在实际操作中踩过的几个印象比较深的坑。适合正在处理传输层加固的运维、后端开发、安全测试同学对照参考，也适合刚接触这块、只知道“配置个证书就行”的朋友补一补底层逻辑。

1. 这条“禁用SSLv2/SSLv3”的建议，放到今天该怎么理解

1.1 扫描器告警背后的真实风险面

先说清楚SSLv2和SSLv3到底危险在哪，不然改配置的时候心里没底，遇到业务方质疑“好好的为什么要动”也很难解释。

SSLv2是1995年的产物，它的握手过程没有完整性保护，攻击者可以在握手阶段做中间人降级，把客户端和服务端一起拖回最弱的密码套件。更直接的缺陷是它能被用来做针对性的暴力破解——由于协议设计允许在不建立完整连接的情况下反复试探，配合当时的弱导出级密码，攻击成本被压得很低。这个协议在1996年就被SSLv3取代，RFC 6176在2011年正式宣布禁止使用。

SSLv3的问题更出名一些，就是2014年公开的POODLE攻击。它的核心缺陷在于CBC模式填充校验的处理方式：攻击者如果能诱导客户端反复发送同一段明文（比如通过页面里的脚本控制请求内容），就能利用填充错误的反馈逐字节猜出密文内容。当时整个行业用了不到一个月的时间集体宣布禁用SSLv3，这个反应速度在安全史上都算罕见。

TLS 1.0和1.1继承了SSLv3的大部分结构，同样使用CBC模式、同样允许RC4、同样在MAC计算上存在可被利用的时间差。RFC 8996在2021年明确把TLS 1.0和TLS 1.1列为弃用状态，理由就是“这些版本依赖的密码学原语已不被认为安全”。

所以标题里那句“请使用tlsv1.2、tlsv1.1版本”，前半句是对的，后半句需要修正。TLS 1.1不是安全港，它只是比SSLv3稍好的过渡品。

这张表建议直接抄进你给业务方的说明文档里。很多时候阻力不是因为技术问题，而是因为对方不知道“为什么非改不可”。

1.2 为什么我不建议停在TLS 1.1

有人会问：既然扫描器只要求关掉SSLv2和SSLv3，我留着TLS 1.1不是兼容性更好吗？这个思路在五年前还算合理，现在不行了。

第一个原因是客户端根本不会用。主流浏览器从2020年起陆续移除了TLS 1.0/1.1的支持，你在服务端留着这个协议，实际握手中永远不会被选中，唯一的“收益”是让扫描器多报一条“支持已弃用协议”。这是纯粹的负收益。

第二个原因是配置复杂度反而上升。如果你同时允许1.1和1.2，就必须准备一套能同时满足两者的密码套件列表，而1.1不支持AEAD类套件（GCM、ChaCha20-Poly1305），意味着你不得不保留CBC模式的套件在列表里。CBC套件一旦存在，就有被选中的可能，前面说的那些填充类攻击面就重新打开了。

第三个原因是TLS 1.3的红利拿不到。1.3把密钥交换强制为前向安全的ECDHE、删掉了所有CBC和RC4、把握手压缩到1-RTT甚至0-RTT，性能和安全性都是净提升。但如果你的配置里混着1.1，某些老旧的负载均衡或中间设备可能会在协商时做出奇怪的行为，反而增加排查成本。

我的做法是：下限直接设在TLS 1.2，同时开启TLS 1.3，套件列表只保留ECDHE + AEAD组合。这套配置在近几年的项目里没有遇到过真正的兼容性障碍，唯一需要单独处理的是那些跑在老旧系统上的嵌入式终端，这个后面第4节专门讲。

有一点需要提前说明：如果你的运行环境是JDK 8，TLS 1.3的支持是从8u261版本开始才有的，更早的版本即使配置里写了TLSv1.3也会被静默忽略。上线前务必确认JDK补丁版本，这个我在第3节会展开。

2. 摸清家底：你的服务端究竟在跑哪些协议

2.1 用openssl s_client把协议逐个点名

改配置之前，先确认现状。最直接的工具就是openssl s_client，它允许你强制指定协议版本去握手，握手成功说明服务端支持，失败说明不支持。

# 逐个协议试探，-brief 只输出结果摘要 for v in ssl3 tls1 tls1_1 tls1_2 tls1_3; do echo "=== $v ===" echo | openssl s_client -connect api.example.com:443 -$v -brief 2>&1 | head -5 done

这条命令跑完，你会得到一张清晰的支持矩阵。注意几个细节：

• -ssl2这个参数在新版OpenSSL里已经被移除，想验证SSLv2支持情况基本只能靠nmap --script ssl-enum-ciphers或者testssl.sh这类工具。
• 有些服务端配置了SNI虚拟主机，不带-servername参数可能拿到的是默认站点的证书和配置。如果你的服务部署在共享入口上，一定要加上-servername api.example.com。
• 握手成功不代表业务可用。我遇到过服务端支持TLS 1.2但只挂了RSA密钥交换套件的情况，握手能通，但现代客户端因为不支持RSA密钥交换而连接失败。所以协议验证之后还要看套件。

testssl.sh是我更推荐的批量方案，它会把协议、套件、证书链、已知漏洞一次性列全：

./testssl.sh --protocols --fs --server-defaults https://api.example.com:443

输出里的SSLv2、SSLv3、TLS 1、TLS 1.1几行如果是红色offered，就是需要处理的目标。这个工具的好处是它还会检查降级保护（SCSV）和Renegotiation支持，这两项在等保测评里也常被提及。

2.2 一张表盘清所有可能藏配置的地方

协议配置最容易被漏掉的不是主站，而是那些“顺手搭起来”的附属服务。我在一个项目里做过统计，一个中等规模的系统，涉及TLS配置的地方能有十几处。

这张表不是让你一次全改完，而是提醒你：改之前先列出所有需要改的地方，否则复扫时会出现“主站绿了、旁站还红着”的尴尬。

有个实用技巧：在Linux上直接用grep扫一遍配置文件目录，把所有涉及协议关键字的行捞出来，比一个个翻配置文件快得多。

grep -rniE "ssl_protocols|SSLProtocol|sslEnabledProtocols|enabled-protocols|tls_version|tls-protocols" \ /etc/nginx /etc/httpd /opt/tomcat/conf /etc/mysql /etc/redis 2>/dev/null

这条命令的输出就是你的改造清单。我习惯把它存成一个文件，改一处划掉一处，避免遗漏。

3. 主流服务端栈的改法：从Nginx到JVM

3.1 Nginx与Apache的协议白名单写法

Nginx的配置最直接，两行就能搞定协议和套件：

server { listen 443 ssl; server_name api.example.com; ssl_certificate /etc/nginx/certs/fullchain.pem; ssl_certificate_key /etc/nginx/certs/privkey.pem; # 协议白名单，显式列出而非排除 ssl_protocols TLSv1.2 TLSv1.3; # 只保留 ECDHE + AEAD 组合 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; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; }

几个值得解释的点：

ssl_protocols用的是白名单写法而不是all -SSLv3这种排除式。排除式的风险在于，将来Nginx升级引入新协议时，默认行为可能变化，白名单则永远只开你列出的那几个。这一点在安全加固里是通用原则：默认拒绝，显式允许。

ssl_ciphers里我故意没有写HIGH:!aNULL:!MD5这类简写。简写看起来省事，但它的实际生效列表会随OpenSSL版本变化，你今天觉得安全的配置，升级后可能悄悄多出几个不想要的套件。显式列全虽然啰嗦，但可控。注意TLS 1.3的套件不由ssl_ciphers控制，它由OpenSSL的默认套件集决定，一般不需要额外配置，确实要控的话用ssl_conf_command Ciphersuites。

ssl_prefer_server_ciphers on的作用是让服务端的套件优先级生效。在不设这个参数的情况下，客户端列表优先，某些老旧客户端可能挑中你并不想用的套件。开启后由服务端说了算。

Apache的写法略有不同，它用的是加减法：

<VirtualHost *:443> SSLEngine on SSLCertificateFile /etc/httpd/certs/fullchain.pem SSLCertificateKeyFile /etc/httpd/certs/privkey.pem # 全部开启后逐项排除，等价于白名单 SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384 SSLHonorCipherOrder on </VirtualHost>

这里有个坑要说清楚：SSLProtocol写在<VirtualHost>内部和外部效果不同。写在外部是全局默认，写在内部覆盖全局。如果你的配置里有多个VirtualHost，而某个忘了写SSLProtocol，它会继承全局值。所以要么在全局写一份正确的、所有VirtualHost都不写，要么每个VirtualHost都显式写。混着写最容易出问题，我在第6节会讲一个具体的翻车案例。

改完配置别忘了nginx -t或apachectl configtest做语法检查，然后平滑重载。Nginx用nginx -s reload，Apache用apachectl graceful，都能做到不断连接。

3.2 Tomcat、Spring Boot与JVM层的开关

Java体系的协议配置分散在三个层次：容器层、应用层、JVM层。这三层任何一层没配对，都可能让前面的努力白费。

Tomcat的server.xml里，Connector节点的配置是这样的：

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="200" SSLEnabled="true" scheme="https" secure="true" keystoreFile="/opt/tomcat/conf/server.p12" keystoreType="PKCS12" keystorePass="changeit" sslEnabledProtocols="TLSv1.2,TLSv1.3" ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256" />

sslEnabledProtocols就是协议白名单，逗号分隔。ciphers这里用的是JSSE的套件命名（TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256），和OpenSSL的命名（ECDHE-RSA-AES128-GCM-SHA256）不一样，混用会导致配置不生效。这个细节坑过不少人，我见过配置里写了OpenSSL命名结果Tomcat启动报错的。

Spring Boot内嵌容器的话，配置在application.yml：

server: port: 8443 ssl: enabled: true key-store: classpath:server.p12 key-store-type: PKCS12 key-store-password: changeit enabled-protocols: TLSv1.2,TLSv1.3 ciphers: - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

注意enabled-protocols的写法是逗号分隔的字符串，不是YAML列表。写成列表形式会启动失败，这个在官方文档里写得不算明显，我第一次配的时候试了两遍才通过。

JVM层是Java客户端发起HTTPS请求的默认协议，这一层最容易被忽略：

# 服务启动参数里加上 -Dhttps.protocols=TLSv1.2,TLSv1.3 -Djdk.tls.client.protocols=TLSv1.2,TLSv1.3

https.protocols控制的是HttpsURLConnection的默认协议，jdk.tls.client.protocols控制的是JSSE层的客户端默认协议。如果你用的是Apache HttpClient、OkHttp这类第三方库，它们可能有自己的默认值，需要单独确认。

举个实际例子：一个服务用JDK 8u151，jdk.tls.client.protocols设了TLSv1.2，但代码里用的是某个老版本HTTP客户端，它内部硬编码了SSLv3作为fallback。结果就是对端关掉SSLv3之后，这个客户端在握手阶段直接抛SSLHandshakeException。排查时先看异常栈里的协议名，再看客户端库版本，比盲目改JVM参数高效得多。

还有一个版本相关的点：JDK 8对TLS 1.3的支持要到8u261才完整。低于这个版本，配置里写TLSv1.3会被静默忽略，不报错，只是不生效。检查方法很简单：

import javax.net.ssl.SSLContext; public class TlsProbe { public static void main(String[] args) throws Exception { SSLContext ctx = SSLContext.getDefault(); for (String p : ctx.getSupportedSSLParameters().getProtocols()) { System.out.println(p); } } }

输出的列表里有没有TLSv1.3，一眼就能看出。没有的话，要么升级JDK补丁版本，要么在文档里注明“当前环境仅支持到TLS 1.2”，避免后续排查时误判。

3.3 数据库、消息队列、反向代理这些“隐秘角落”

主站改完只是第一步，后端组件才是真正的隐蔽战场。

MySQL在8.0版本之后默认就是tls_version=TLSv1.2,TLSv1.3，但5.7及更早版本默认允许TLSv1，需要在my.cnf里显式配置：

[mysqld] tls_version = TLSv1.2,TLSv1.3 ssl_ca = /etc/mysql/certs/ca.pem ssl_cert = /etc/mysql/certs/server-cert.pem ssl_key = /etc/mysql/certs/server-key.pem

改完重启后，用SHOW VARIABLES LIKE 'tls_version';确认生效。这里有个容易忽略的点：MySQL的复制链路（主从同步）走的是同一个tls_version配置，如果从库版本较老不支持TLS 1.2，主从同步会直接断掉。改之前务必确认所有节点的版本。

PostgreSQL的配置在postgresql.conf：

ssl = on ssl_cert_file = 'server.crt' ssl_key_file = 'server.key' ssl_min_protocol_version = 'TLSv1.2'

ssl_min_protocol_version是PG 12才引入的参数，更早的版本只能靠OpenSSL的全局配置间接控制。如果你的PG版本低于12，升级是唯一干净的解法。

Redis 6开始支持TLS，配置项是tls-protocols：

tls-port 6379 tls-cert-file /etc/redis/certs/redis.crt tls-key-file /etc/redis/certs/redis.key tls-ca-cert-file /etc/redis/certs/ca.crt tls-protocols "TLSv1.2 TLSv1.3"

注意Redis这里的分隔符是空格，不是逗号。这个细节在不同组件之间没有统一标准，配的时候最好对照官方文档确认一遍，别凭记忆写。

反向代理这一层特殊一点：它有两段链路，客户端到代理、代理到后端。两段都要配协议，但配置位置不同。以Nginx为例，server块管的是客户端一侧，location里的proxy_ssl_protocols管的是后端一侧：

location /api/ { proxy_pass https://backend_upstream; proxy_ssl_protocols TLSv1.2 TLSv1.3; proxy_ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384; proxy_ssl_server_name on; }

proxy_ssl_server_name on这一行很关键，它让Nginx在连接后端时发送SNI。如果后端是多域名共享的入口，不设这个参数会拿到默认证书，导致证书校验失败。这个坑我在第6节详细说。

4. 客户端兼容性：改完服务端之后才是麻烦的开始

4.1 旧SDK、嵌入式终端与IoT设备的困局

服务端配置改完、验证通过，按理说该结束了。但现实里经常出现的情况是：上线第二天，某个业务方反馈“我们对接的终端连不上了”。

这类问题几乎全部来自客户端一侧的TLS支持能力不足。我把常见的老旧客户端分了几类，处理策略各不相同：

处理思路可以归成三层：能升级的升级，不能升级的隔离，实在隔离不了的设置明确的淘汰时间表。

升级优先，是因为这是唯一能带来净收益的方案，长期维护成本最低。数据库驱动的坑尤其多，比如某版本MySQL Connector/J在useSSL=true时默认尝试TLS 1.0，升级驱动就能解决。

隔离的做法是在边缘层做一个协议转接。比如在负载均衡上开一个单独的监听端口，只对这个老旧终端开放TLS 1.0/1.1，后端到应用服务器仍然走TLS 1.2。这样内网的传输层基线不受影响，攻击面被限制在边缘的一小段链路上，配合访问控制列表还能进一步收窄。

设置淘汰时间表是最不理想但有时必须的选择。我在一个项目里遇到过一个跑了七八年的自助终端，固件厂商已经停止支持，现场升级成本很高。最后的方案是给它单独一个入口、单独的证书、单独的白名单策略，同时在项目管理里挂了一个明确的替换计划。这种做法不优雅，但比“为了一个终端把整个系统的协议基线拉回去”要好得多。

有个判断原则值得记住：协议基线的制定不应该被最落后的那个客户端绑架。正确的做法是基线统一拉高，落后者走例外通道，例外通道有明确的负责人和到期时间。否则你会陷入“每次想升级都有人拿老设备说事”的死循环。

4.2 握手失败的报错怎么读

排查兼容性问题，第一步是读懂报错。不同语言栈的异常信息差别很大，但核心线索都是一样的：握手在哪个阶段断的、断的原因是什么。

用openssl s_client能最快定位问题出在哪一步：

# 加 -state 看握手状态机，-msg 看具体报文 echo | openssl s_client -connect api.example.com:443 \ -servername api.example.com -tls1_2 -state -msg 2>&1 | head -40

输出里会看到SSL_connect:before SSL initialization、SSL_connect:SSLv3/TLS read server hello这类状态流转。卡在哪一步，问题就在那一步对应的环节。

举个典型的例子：state显示走到了read server certificate然后报certificate verify failed，说明握手本身没问题是证书链的问题。这时候用-showcerts把服务端返回的整条链打出来，看中间证书有没有缺失。很多服务端只配了站点证书没配中间证书，浏览器能靠AIA自动补全，但Java、Python这类客户端不会，直接报错。

如果state卡在before SSL initialization，通常是TCP层就失败了，和TLS无关，先查网络连通性。

5. 验证与回滚：别让一次安全加固变成一次事故

5.1 验证矩阵怎么搭

改完之后光看扫描器变绿是不够的，扫描器只验证协议层面，不验证业务层面。我习惯做一个三维验证矩阵：协议维度、客户端维度、业务维度。

协议维度用前面说的testssl.sh或openssl s_client扫一遍，确认SSLv2/SSLv3/TLS 1.0/TLS 1.1都是not offered，TLS 1.2和1.3是offered。

客户端维度要覆盖实际会连接这个服务的所有客户端类型。这一项最容易走过场，我的做法是写一个简单的检查脚本，把常用客户端的握手结果批量跑一遍：

import ssl, socket HOST, PORT = "api.example.com", 443 def probe(proto_name, min_ver=None, max_ver=None): ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT) ctx.check_hostname = False ctx.verify_mode = ssl.CERT_NONE if min_ver: ctx.minimum_version = min_ver if max_ver: ctx.maximum_version = max_ver try: with socket.create_connection((HOST, PORT), timeout=5) as sock: with ctx.wrap_socket(sock, server_hostname=HOST) as ssock: return f"{proto_name}: OK -> {ssock.version()}" except Exception as e: return f"{proto_name}: FAIL -> {type(e).__name__}" print(probe("default")) print(probe("TLSv1.2", ssl.TLSVersion.TLSv1_2, ssl.TLSVersion.TLSv1_2)) print(probe("TLSv1.3", ssl.TLSVersion.TLSv1_3, ssl.TLSVersion.TLSv1_3)) print(probe("TLSv1.1", ssl.TLSVersion.TLSv1_1, ssl.TLSVersion.TLSv1_1))

这个脚本的价值在于它能一次性告诉你“服务端现在到底接受哪些协议”，比逐个敲命令快。而且Python的ssl模块行为比较接近Java客户端，能提前发现一部分兼容性问题。

业务维度最实在：把核心接口的调用链路完整跑一遍，特别是那些涉及外部系统对接的。我见过协议改完后主流程正常、但某个异步回调接口挂掉的情况，因为那个回调走的是另一套HTTP客户端配置，主流程测试根本没覆盖到。

5.2 灰度发布与回滚预案

TLS配置改动属于“影响面大、验证手段有限”的变更类型，一定要灰度。我的常规节奏是这样的：

第一步在预发布环境改，完整跑一遍验证矩阵。第二步在生产环境挑一台负载较低的节点改，观察24小时，重点看错误日志里有没有新增的握手失败。第三步全量改。第四步是观察期，一般给三天。

回滚预案要提前准备好，不是等出事了再想。具体来说：

保留旧配置文件的备份，文件名带时间戳，比如nginx.conf.bak.20240115。这个动作看起来笨，但真出事的时候能省掉十分钟的慌乱。

确认重载命令不会中断连接。nginx -s reload是平滑的，已有连接继续用旧配置，新连接用新配置。但如果你用的是systemctl restart nginx，那就是硬重启，会断连。这种细节在平时无所谓，在回滚场景下就是事故放大的倍数。

准备一个快速诊断脚本，把前面那些openssl s_client的探测命令打包，出问题时能一键跑出当前状态。我在几个项目里都留了这样一个脚本，平时不用，出事时能立刻判断是“配置没生效”还是“客户端不支持”。

诚实一点说，TLS配置的回滚代价其实不高，改回去重启就行。真正麻烦的是已经发出去的客户端——如果服务端强制TLS 1.2之后，某个客户端连不上，你回滚了服务端，但客户端那边可能已经因为连接失败触发了降级逻辑或者告警，清理这些副作用比回滚配置本身费劲得多。所以灰度这一步不能省。

6. 几个实际踩过的坑

6.1 协议禁了，请求却卡在超时

这是我在一个项目里遇到的怪事：服务端按计划禁掉了TLS 1.0/1.1，复扫全绿，主流程正常。但上线第三天，监控显示某个内部服务的调用延迟从50ms涨到了3秒，而且不是每次都慢，大概十分之一的概率。

排查顺序是这样的：先看服务端日志，没有异常；再看客户端日志，也没有报错，就是慢；用tcpdump抓包，发现慢的请求在TCP建连之后有一段明显的空白期，大约3秒后才开始TLS握手。

3秒这个数字很关键，它是TCP重传的经典时间窗口（1s + 2s）。说明SYN包发出去了，但握手包丢了或者被拦了。

最后定位到是中间的一台安全设备。它的策略库里配了“拦截SSLv3及以下”的规则，规则匹配的方式比较粗糙——只要Client Hello里的版本号字段看起来像老版本就拦。某些老旧客户端在Client Hello里会把版本字段填成TLS 1.0但实际支持1.2，被设备误判后直接丢包，客户端重传，第二次可能就过了，表现就是随机变慢。

这个问题的修复不在服务端，而在安全设备的策略调整。但排查过程说明了一件事：协议升级的影响面不止两端，中间的每一跳都可能对协议字段有自己的解读。负载均衡、WAF、IPS、代理服务器、SDN控制器，这些设备的策略都值得在变更前确认一遍。

判断方法很简单：在客户端和服务端同时抓包，对比两边看到的握手报文。如果客户端发了Client Hello但服务端没收到，中间就有设备在干预。

# 客户端侧 tcpdump -i eth0 -w client.pcap 'tcp port 443' # 服务端侧 tcpdump -i eth0 -w server.pcap 'tcp port 443'

两边抓完用Wireshark对比时间戳和报文序号，能很快定位丢包位置。

6.2 SNI、会话复用与证书链的边角问题

还有几个坑属于“不常见但一踩就很懵”的类型，我打包说一下。

SNI缺失导致证书错配。前面提过proxy_ssl_server_name on，这里展开讲。一个入口承载多个域名时，服务端靠Client Hello里的SNI字段决定返回哪张证书。如果客户端不发送SNI（老版本Java的某些配置、部分命令行工具、某些嵌入式栈），服务端只能返回默认证书。客户端拿默认证书去校验目标域名，自然失败。

判断方法：用openssl s_client不带-servername和带-servername各跑一次，对比返回的证书CN。

echo | openssl s_client -connect api.example.com:443 2>/dev/null | openssl x509 -noout -subject echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null | openssl x509 -noout -subject

两次结果不一样，说明这个入口依赖SNI。这种情况下，不带SNI的客户端必须有单独的处理方案，比如给它一个专用IP或专用端口。

会话复用导致的“改了不生效”。这个坑很迷惑人：配置改完重启了，用openssl s_client测也是新协议，但业务监控显示还有老协议的连接。原因是会话票据（Session Ticket）的复用——客户端拿着之前协商好的会话票据直接恢复会话，跳过了完整的协议协商。

会话票据的有效期默认可以达到几小时甚至几天，取决于服务端的ssl_session_timeout配置。这时候需要在服务端轮换票据密钥，或者临时把ssl_session_tickets关掉再开，强制所有会话重建。

Nginx里的相关配置：

ssl_session_tickets off; # 或者 ssl_session_timeout 10m; # 缩短复用窗口

证书链不完整的“浏览器能通、代码不通”。这个问题特别常见，因为浏览器有AIA（Authority Information Access）机制，能自动去下载缺失的中间证书，而大多数编程语言的TLS库不会。所以现象就是：用浏览器访问正常，用curl、Java、Python全报证书错误。

检查方法：

echo | openssl s_client -connect api.example.com:443 -showcerts 2>/dev/null | grep -c "BEGIN CERTIFICATE"

正常应该返回2或3（站点证书 + 1~2张中间证书）。只返回1说明只配了站点证书，需要在服务端配置里把完整的fullchain.pem挂上。这个文件通常是CA机构签发时一起给的，别只拿cert.pem。

TLS 1.3的0-RTT与重放风险。TLS 1.3引入的0-RTT能让客户端在第一个包就带上应用数据，延迟更低。但对于非幂等的请求（比如支付、下单），0-RTT的数据可能被攻击者截获重放。

Nginx默认是开启0-RTT的，如果你的服务里有非幂等接口，建议评估后关掉：

ssl_early_data off;

关掉之后只损失一点点首包延迟，换来的是重放攻击面的消除。对于绝大多数业务系统，这个交换是值得的。

最后再分享一个我自己的习惯：每次做完协议变更，我都会把变更前后的testssl.sh完整输出存档，包括变更时间、变更人、影响的域名列表。这个存档在半年后做审计或者排查历史问题时特别有用——你能清楚知道“当时改了什么、改成什么样、为什么这么改”。靠记忆是不行的，三个月后你只会记得“好像改过”，具体参数一定想不起来。