说实话，市面上讲SSL证书的文章，大半是给运维看使用说明的。今天想聊点引擎盖下面的东西。不是让你背一遍X.509结构，而是把TLS握手那点数学和协议博弈拆开来看看。说得难听点，你只是把证书装上去，跟没装的区别不大——除非你知道它到底在保护什么。
先说一个反直觉的事实：SSL证书本身不加密数据。真正干活的是TLS握手派生出的会话密钥。证书只是用来证明“你就是你”的一张数字身份证。但问题来了——这张身份证怎么验？怎么用？这里面的门道比多数人想的多得多。
一、握手里的三角博弈
每次建立HTTPS连接，浏览器和服务器都要玩一轮“猜数字”游戏。传统RSA握手是这样：服务器把公钥丢给客户端，客户端生成一个随机数，用公钥加密发回去。服务器用私钥解密，于是双方有了同一个密钥。简单粗暴，但有个致命伤——如果服务器私钥泄漏，以前所有记录都能被解密。这叫前向保密缺失。
所以现在主流方案是ECDHE。相当于双方各自生成一个临时数，通过椭圆曲线计算出共享密钥。整个过程不传输私钥，即使服务器私钥事后泄露，历史流量依旧安全。代价是计算量上去了——但TLS 1.3把这一步优化到了极致，直接省掉一个RTT。
我拿openssl s_server跑过对比。同样环境下，TLS 1.2完整握手要两个RTT的延迟，而TLS 1.3只要一个。数据看起来不大：本地百兆网络也就差个0.2ms，但放在跨洋链路上，这就是实打实的50ms以上差距。你想想，移动端弱网环境下，用户等得焦躁的根源有很大一部分就在这。
更微妙的是证书验证。浏览器拿到证书后，要回源站做OCSP查询，确认这个证书没被吊销。这一趟网络往返，往往比握手本身还慢。除非你开了OCSP stapling——让服务器把验证结果直接缓存下来，塞进握手包。可惜很多站点没意识到这个细节，白白牺牲了20%~30%的握手性能。别再骂运营商了，先看看自己的服务器配置。
二、压测数字不会骗人
光说理论没感觉。我自己在阿里云一台4核8G的ECS上做过一轮压测，工具是wrk，模拟1000并发，持续60秒。测试对象是同一个nginx，分别走HTTP和HTTPS（TLS 1.3，ECDHE-RSA-AES256-GCM）。结果出来，HTTPS的QPS只有HTTP的52%——等等，你先别急着关页面。这个差距大部分来自握手的CPU密码运算。但我把会话复用打开后（TLS session ticket），第二波请求的QPS直接回升到94%。
这意味着什么？对于短连接为主的API服务，握手占比高，性能损失就大。但HTTP/2多路复用技术可以让你在一个连接上做多次请求，重复握手的成本被摊薄。所以别再拿“HTTPS性能差”当借口了，技术选型就能救回来。
顺带说个有意思的数字。我对比过RSA 2048和ECC P-256的握手性能。在同样并发下，ECC的握手延迟中位数比RSA低了18%左右。原因很简单：ECDHE计算量小，而且密钥交换所需的参数传递更精简。如果你还在用全站RSA，别犹豫，该换国密或者ECC了。
三、落地时的三个大坑
证书买了，配好了，但网站还是被别人提示“不安全”。这算是我见过最频繁的翻车现场。
坑一：证书链不完整
很多站长只装域名证书，忽略中间证书。服务器返回的证书链缺了中间一环，客户端无法构建完整的信任链，直接报错。解法？在部署时把证书文件、中间证书、根证书按顺序拼接成一个PEM。但注意，根证书一般不用发，否则反而可能被拒。具体做法：cat 域名.crt 中间证书.crt > 完整证书.crt。就这么简单，但踩坑的十个里有两个。
坑二：OCSP stapling没开
上面提了，不加这个，每个新连接都会去CA的服务器查状态。我见过某站点因为这个，握手时间从2ms飙到30ms。开法也简单：nginx里加一句 ssl_stapling on; 再加 resolver 8.8.8.8;。注意别漏了resolver，否则不生效。
坑三：密钥长度自以为是
有人觉得RSA 4096比2048更安全，于是全站用。但4096的握手速度比2048慢得多，消耗的CPU也更多。实际上2048的安全性足够满足绝大多数业务，除非你对抗的是国家级情报机构。选用ECC P-256反而能兼顾安全与性能。别为了那点心理安慰牺牲用户体验。
还有个小坑，警告你：千万别用免费的自签名证书。虽然它能加密，但客户端会怒吼“证书无效”。内部测试无所谓，线上就这么搞就是作死。
说到底，SSL证书这事儿，不是装完就完的。它是一个需要持续运维的系统组件。你不管是性能还是安全性，都得心里有数。否则等到POC（Proof of Concept）黑了才反应过来，那就真成了大型社死现场了。
