上了证书不等于配置到位

装好证书、地址栏出现小锁，只说明流量被加密了，不代表加密的方式是安全的。协议版本、加密套件、证书链是否完整、有没有开启强制跳转，这些决定了一次连接到底有多可靠。老旧的协议版本存在已知问题，一些早期的加密算法也可以被降级利用，配置里如果还留着它们，等于给连接留了后门。

判断配置是否合适，最直接的办法是拿域名做一次在线检测，报告里会列出支持的协议版本、加密套件、证书链和常见问题。看报告时重点关注三件事：是否还允许年代久远的协议版本、是否支持强度不足的加密套件、证书链是否完整。

检测工具给的是当下的状态。协议和套件会随着时间被淘汰，去年合格的配置，今年可能已经列入需要调整的范围，所以这件事要定期做，而不是装完看一次就结束。

协议版本和加密套件怎么取舍

协议版本上，通行的做法是只保留较新的两三个版本，把更早的关掉。风险在于老旧的客户端可能连不上，比如一些还在使用的旧系统、嵌入式设备和老的采集程序。决定之前，看一下自己的访问日志里还有多少这类客户端，占比很低就可以直接关，占比不低就先留一个过渡期。

加密套件也是同样的思路。优先保留支持前向保密的组合，把使用静态密钥交换的、强度不足的算法排到后面或者直接去掉。顺序会影响协商结果，把强的放在前面，大多数客户端会自动选到更安全的那一个。

有些兼容性问题会在调整后一段时间才暴露，比如某个合作方的接口调用忽然失败，或者某个地区的用户反馈打不开。保留调整前的配置，出问题能快速还原。

如果站点有多个域名或者多个后端服务，尽量在统一的入口处做这些设置。分散在各个服务里改，很容易改漏一处，日后排查差异也会花掉很多时间。

几个容易被忽略的设置

强制跳转值得单独配置。只把站点做成同时支持两种访问方式，用户还有可能停在明文连接上，登录信息和会话凭据都可能被中间的环节看到。把明文访问统一跳到加密地址，是成本很低的一步。

证书链的完整性常被忽略。本地测试一切正常，是因为浏览器补全了缺失的中间证书；换一个环境访问，就会出现证书不受信任的提示。部署时把中间证书一起配上，能省掉这类难排查的问题。

还有一处是混合内容。页面本身走加密连接，里面却引用了明文的图片或脚本，浏览器会给出警告，脚本还可能被替换。上线之后用浏览器的控制台看一遍有没有这类提示，比只看地址栏的小锁可靠。

证书的续期方式也要确认。自动续期看起来省事，但续期失败的通知如果没人看，仍然会等到过期那天才发现。

改完之后怎么验证

验证先从外部做。换一台不常使用的设备、换一个网络环境访问，确认证书有效、连接正常、没有安全提示。这一步能发现本地缓存和信任链带来的假象。

再用检测工具复查一遍，确认关闭的协议版本确实不再被接受，加密套件列表符合预期。改完不看结果，等于不知道有没有生效。

最后把配置的改动记下来，包括时间、原因和涉及的范围。协议版本这类内容日后还会再调整，有记录才知道上一次是什么时候改的、为什么改。把这些设置和调整记录放进运维文档，交接时能直接看到现状。

上线之后的日常检查

证书和协议配置一旦稳定，容易被放进抽屉里不再过问。更实际的做法是把它纳入固定的检查周期：证书到期前是否有提醒、续期是否真的成功、配置有没有被人改动过。这些检查花不了几分钟，却能避免某天突然出现大面积访问异常。

配置的变更也要留痕。谁在什么时候调整了协议版本或者加密套件，为什么调整，写下来。团队里换人之后，这些记录就是判断当前状态的唯一依据。

如果站点还挂着其他服务，顺手确认它们用的是不是同一套配置，别只改了主站。

改动时容易忽略的一处

调整协议和套件之后，建议用几款常见的客户端实际访问一次，包括手机浏览器、桌面浏览器和接口调用工具。有些差异只在特定客户端上出现，检测工具的评分看不出来。