SSL证书怎么选？DV、OV、EV与免费证书的区别与部署避坑指南

前阵子一个做独立站的朋友半夜给我打电话，说他的网站在浏览器里弹了一整屏的“您的连接不是私密连接”，用户全跑了。我远程登上去一看，证书过期三天，他完全没注意到。他问我：当初买证书的时候选的是最便宜的，现在到底该换哪一种？市面上说的DV、OV、EV、泛域名到底有什么区别？

这个问题我隔三差五就会碰到。SSL证书这东西平时看不见摸不着，但对一个网站的安全和转化率而言，它是最基础的一道信任门槛。市面上的证书类型看着多，价格从一年几十块到几千美金都有，第一次接触的人很容易懵。这篇就把主流类型拆开讲清楚，从原理讲到选型、部署和排错，最后再把免费证书那些坑一并说透。准备给网站上HTTPS的人、正在比价选证书的老板、以及不想在证书问题上反复踩坑的运维和开发者，都可以直接照着看。

1. SSL证书在网站安全里扮演的角色，比“加锁”更复杂

很多朋友以为SSL证书就是给网站加个锁，装上以后数据就加密了。这个理解只对了一半。真正负责加密的是TLS协议，证书在里面扮演的其实是“身份证”的角色。先搞清楚这一点，后面选型才不会跑偏。

1.1 TLS加密本身不需要证书，证书解决的是“对面是谁”

HTTPS的通信过程可以简化成两步。第一步，浏览器和服务器协商出一把临时的对称加密密钥，之后所有实际数据都用这把密钥加密传输，速度快、计算开销小。第二步是用非对称加密把“协商过程”保护起来，确保中途没人能看到和篡改密钥。

问题来了：当浏览器第一次连上服务器时，它凭什么相信对面就是你要访问的那个网站？中间人完全可以在网络链路里伪装成目标服务器，主动和浏览器完成密钥协商，然后转发数据，用户根本察觉不到。这时候就需要证书出场。

TLS证书的核心作用有三个：确认域名归属、携带服务器公钥、证明这份公钥确实属于该域名的运营者。浏览器内置了一组受信任的证书签发机构名单，收到服务器证书后会顺着签名链条向上追溯，验证签发者是否在名单里、域名是否匹配、有效期是否覆盖当前时间。全部通过，才会进入密钥协商环节。

用生活里的例子来说，TLS加密是保险柜本身，证书则是保险柜上贴的运营方执照。没有执照的人也可以放一个一模一样的保险柜，但用户无法确认他是不是官方人员。没有证书的技术方案也能做加密，但那份加密建立在“对方身份存疑”的基础上，安全价值大打折扣。这也是为什么从浏览器到搜索引擎，都把证书视为网站安全的基线配置。

1.2 没有证书或不规范部署时，网站在真实用户面前是什么样

现在随便打开一个HTTP明文网站，主流浏览器的处理方式已经不是默默容忍，而是直接在地址栏打出“不安全”三个字，部分浏览器还会拦截部分高级功能。我实测过一个没有证书的内容网站，用户跳出率明显高于同类型HTTPS站点，尤其是新用户，看到浏览器警告后第一反应是关页面而不是继续浏览。

除此之外还有三层隐性损失。搜索引擎在排序时会把HTTPS作为基础参考项，同样的内容，加了证书的站点在收录优先级上更占优势。现代Web技术的很多增强功能也都建立在HTTPS之上，比如HTTP/2协议、地理位置接口、剪贴板权限、PWA离线能力，明文站点在这些能力上直接受限。再往深处说，数据明文传输意味着用户的登录口令、表单内容、支付信息在中间链路节点上是裸奔的，被截取的代价太高。

所以我的观点很明确：证书不是一个“要不要装”的问题，而是一个“装哪种、怎么装好”的问题。接下来这四种主流类型，才是大多数人真正需要弄清楚的。

2. 四大类型：按验证级别切分的DV、OV、EV，和按域名范围切分的“第四类”

“四大类型”这个说法在不同销售渠道口径不太一样，但拆开来看无外乎两个维度：验证级别和域名覆盖范围。验证级别决定证书里面包含多少真实身份信息，域名覆盖范围决定一张证书能管多少个域名。

2.1 DV域名验证：恨不得一分钟签完的低门槛证书

DV是Domain Validation的缩写，只验证你对域名有控制权，验证手段一般是两种：在网站根目录放一个指定字符串的文件，或者在域名解析记录里加一条TXT记录。CA看到记录生效，就认为这个域名归你管，随后签发证书。

DV证书有几个特点决定了它是入门首选。签发速度快，快的时候自动流程几分钟就能拿到证书；价格低，大量免费证书都属于DV；部署简单，几乎不涉及任何人工审核环节。但代价也随之而来：证书里只有域名信息，没有任何企业身份信息，访问者点击证书详情时看不到主体名称，只能看到“这是一张加密证书”。

换句话说，DV证书证明的是“你控制着这个域名”，但不能证明“这个域名的运营者到底是谁”。这让它天然不适合高信任业务。钓鱼网站、仿冒域名也同样能申请到DV证书，所以如果网站涉及支付、用户隐私、品牌形象，DV通常在信任等级上是不够的。

2.2 OV企业验证：把域名和真实企业绑在一起

OV是Organization Validation的缩写，在DV验证的基础上增加了一轮真实企业主体审核。申请的时候，需要提交营业执照等注册文件，CA会通过电话回访、工商信息数据库比对等方式确认申请主体真实存在，而且对域名确实有合法使用权。签发周期通常在1到5个工作日，价格也明显高于DV。

OV证书的价值在于，浏览器在证书信息里可以看到明确的公司名称、所在地、统一信用代码等真实身份数据。普通用户可能平时不会点开证书详情去看，但关键场景下这份信息很有用：比如用户在一个陌生链接前犹豫要不要输入信息时，点开证书看到的是一个真实注册企业的名字，和一个只能看到“域名已验证”的证书，心理信任度完全不一样。

从合规角度讲，很多机构在对接供应商、第三方API、企业内部系统时，会明确要求对方网站必须提供企业级别的加密证书。这类硬性要求直接把DV档在门外，OV往往是入场券。

2.3 EV扩展验证：曾经地址栏最显眼的标记，现在的价值变了

EV是Extended Validation的缩写，验证强度比OV再高一个台阶。除了企业资料，CA还会对申请主体的法律存在、运营地址、授权范围做多轮交叉核验，甚至要追溯授权书的签发链。早年装上EV证书后，浏览器地址栏会把公司名直接显示出来，锁标志也从灰色变成醒目的绿色，视觉上非常拉风。

但最近几年情况变了。主流浏览器出于对HTTPS普及化的考虑，陆续弱化了EV证书的特殊视觉标识。现在打开一个EV证书站点，地址栏显示规则和OV、DV基本上一样，不再有绿色高亮公司名的待遇。很多老运营者还是照旧买EV，但实际得到的“门面效果”已经大打折扣。

那EV还有没有价值？有，但不是视觉层面，而是审核层面。EV的审核流程一方面极其严格，能被审核通过的站点，其主体真实性几乎是得到了一轮接近尽职调查级别的核验，在信任背书层面依然是最高的；另一方面，部分金融、证券、高客单业务场景的合规要求里仍然会指定EV等级证书。如果你的业务不需要这类硬要求，我的个人建议是不要为了那一丝“最高等级”的心理安慰多花几倍的钱，OV通常已经够用。

2.4 按域名范围切分的“第四类”：通配符与多域名SAN

第四类其实不是一个单独的验证等级，而是从域名覆盖范围上切出来的一类，常见的有通配符证书和多域名证书。

通配符证书的特点是可以用一个证书保护某个域名下的所有二级子域名，比如一张证书同时覆盖domain.com、a.domain.com、b.domain.com。签一张，整站全包，运维成本极其友好。但代价是子域名列表不能跨主域名，而且因为公钥只有一个，任何一个子域名的私钥泄露都会牵连整个证书范围，权限管控要求更高。现在主流CA在签发通配符证书时，验证方式也普遍限制为必须使用DNS验证，避免通过HTTP方式验证后被滥用。

多域名证书则允许一张证书里包含多个完全不同的域名，比如domain.com、another-site.com、service.net同时塞在一张SAN证书里。它最大的好处是一个证书管到底，统一到期时间，统一管理入口，很适合域名数量不多但归属复杂的小团队。缺点和通配符类似，证书域名列表一旦要扩容，通常需要重新签发；而且因为一张证书同时关联多个域名，证书链体的风险面也会相应扩大。

3. 不同业务场景下的选型判断：别只看价格和验证级别

绕开那些被宣传话术包装的“高等级”概念，实际选型要看的是你的业务到底需要什么样的信任、多少域名、什么维护强度。我按这几年见过的大量客户场景整理了几个判断逻辑。

3.1 个人博客与内容站：DV免费足够

个人博客、技术文档站、内部工具站、临时活动页，这些场景的核心诉求是让浏览器不报警、让数据在传输过程加密。用户不会因为你用的是DV还是OV就决定要不要关注你，他们只会看有没有那个锁的标识。

这类站点我一般建议直接用免费DV证书加上自动化续期，一年成本为0，维护成本也低。需要提醒的是，免费DV证书通常在有效期上很短，后续必须做好自动续期，否则就是本文开头那个朋友的结局——过期三天不自知，用户全跑光。这部分细节我在后面专门展开。

3.2 创业公司与SaaS产品：起步DV，商业阶段OV

很多SaaS团队早期用DV证书跑通了MVP，到了对接客户、开通企业版、吸引付费用户阶段，才意识到证书等级在商业谈判里是真的会被翻出来看的。我见过不止一个案例：商务聊到落地环节，对方安全团队要求提供OV及以上等级的加密证书，结果一边催着申请一边让客户等了三天。

我的建议是把证书升级纳入商业化节奏。拿了种子轮、准备认真做付费产品的时候，就把OV证书提上排期。价格多出来的部分一年通常也就几百元，换来的是商业对接中的一块敲门砖，同时证书里显示的企业主体名称还能变成一次免费的品牌曝光，对提升注册页转化率有一定帮助。

3.3 电商、支付、高信任业务：OV保底，EV按合规要求决定

做独立站电商、预定系统、会员充值平台这类涉及真实交易和隐私信息的业务，OV应该作为底线配置，不要在这个环节省。支付环节用户输入的每一项信息都是敏感数据，一旦中间环节出问题，损失的不只是资金，还有整个品牌的信任底盘。

EV是不是需要，取决于业务合规要求。有些平台接入支付服务商时，对方会要求证书达到EV等级；有些金融机构的合作伙伴准入审核也点明要EV。如果你的业务没有这种硬性限制，OV已经能完成绝大多数信任建设目标。把EV省下来的钱拿去买终端防护、日志审计、双因素认证，对真实安全水平的提升更明显。

3.4 多域名和多子域场景：先算一遍证书数量再决定

遇到域名结构复杂的情况，我的习惯是先画一张域名清单：有几个根域名、每个根域名下面有多少个子域、子域是否还会动态增加。画完之后，选型其实就清晰了。

子域数量多且都在同一个主域下面，优先考虑通配符证书，维护量直线下降。调用API的服务域、活动落地页域、静态资源CDN域都在不同根域名下，则用多域名证书打包管理。还有一类场景是子域数量极少、根域名也就一个，那就老老实实签单域名DV或OV，没必要为通配符埋单。

这里有个容易忽略的点：证书数量管理本身就是一种隐性成本。之前帮一个团队处理事故，发现他们三个子域各签了各的证书，到期时间完全错开，运维要分三次更新，每次都有遗漏风险。后来换成通配符，到期提醒从三个变成一条，省力不少。所以别只看单张证书多少钱，还要看你要维护几张。

4. 免费证书的真实水平：自动化签发协议与90天有效期

免费证书到底能不能用？这是我从博客到企业客户那里听过最多的问题。先说结论：技术上完全可用，加密强度和商业付费证书没有本质区别。它真正缺的是身份背书和服务保障，以及你可能没有意识到的自动化维护成本。

4.1 免费证书为什么能免费：统一签发、验证方式简化

目前互联网上主流的免费证书基本都来自公益性的CA项目，通过标准化接口向所有人开放DV级别的签发服务。免费证书在密码学强度和TLS握手过程中占用的资源，跟商业CA签发的DV证书没有区别，浏览器同样是按同一套信任链规则在验证。

免费证书的签发全部走自动化流程：你向CA的自动化接口提交一次性验证请求，验证方式通常是HTTP方式或DNS方式。HTTP验证要求你有一个能被访问的站点，把CA给的校验文件放到指定路径；DNS验证则是解析一条TXT记录。校验通过后，CA立即签名并返回证书文件。全程没有任何人工介入，所以签发成本可以压到接近零，也就能免费提供。

但这也意味着免费证书只能支持DV级别。想让证书里带上企业名称、支撑起商业对接场景，就必须要人工核验，这部分成本免费项目无法承担，所以低至几分钟的免费签发体验，在高等级证书上是享受不到的。

4.2 90天有效期背后的取舍：短有效期和安全性的关系

免费证书普遍采用短有效期策略，多数是90天，这也是业内公认目前最稳妥的平衡点。很多人觉得有效期越长越省事，其实恰恰相反，在数字证书这个领域，短有效期对安全更有帮助。

证书一旦泄露或被滥用，有效期越长，受害时间就越长。短有效期能迫使证书持有人定期更新，每次更新都是一次重新验证身份的机会，域名过期、主体异常、私钥泄露等问题会被更快暴露出来。CA也用这个机制倒逼证书生态保持健康，避免一张旧证书在角落里偷偷使用很多年。

代价也很直接：如果你的网站不是自动化续期，每90天就要手动换一次证书。我见过太多免费证书用户，第一次配置时很开心，三个月后忘了，结果站点突然打不开到处求救。免费证书的正确打开方式是这样的：第一次申请时可以手动，但从第二次开始，必须把续期做到完全自动化。

4.3 自动化续期常见的三个翻车点

自动化续期听起来高大上，实际踩坑的人不少。我总结三个高频翻车点，这些我都在真实环境里见过。

第一个翻车点是HTTP验证失败。HTTP验证要求CA服务器能访问到你指定路径下的校验文件。如果你的站点前面套了CDN、开启了强制跳转、或者正在维护挡了访问，CA来验证的时候拉不到文件，续期就会失败。解决思路是优先选DNS验证方式，DNS验证不依赖站点可访问性，只要解析服务正常就行。

第二个翻车点是续期成功了，但Web服务没有重载。证书文件更新了，进程还抱着旧证书不撒手，浏览器看到的是旧证书，直到过期才暴露问题。这就是典型的“看起来很成功，实际没生效”。自动化脚本里一定要加上重载Web服务的步骤，并在续期完成后做一次在线校验。

第三个翻车点是私钥没有被妥善管理。自动化工具生成的新私钥如果是一次性生成的，续期后会覆盖旧私钥。如果私钥文件权限过宽、备份不完整、被其他服务共用，一旦出错就需要重新签发。我在部署时会给私钥设置独立用户权限，并定期加密备份，避免换台服务器就找不回私钥的情况。

4.4 免费证书真正的边界：没有企业身份背书、没有服务承诺

免费证书最大的限制不是技术，而是信任和服务。因为只做DV验证，证书里无法体现企业主体信息，面对高信任业务、商业合作审核、支付安全要求就束手无策。另一方面，免费CA的签发生态强调自助服务，如果遇到签发失败、证书吊销争议等异常，基本只能靠社区问答或工单排队，没有专属支持。

所以我的选型建议是：能用免费的领域别多花钱，需要背书和服务别硬省。个人站点、测试环境、内部系统，免费证书完全足够；企业官网、付费产品、任何和钱打交道的页面，把OV证书作为基本预算写入年度成本，这几十到几百块换来的是一份可追溯的企业身份，和一张万一出问题时能找人对接的售后服务通道。

5. 证书从申请到上线的完整流程：私钥、证书链与排错经验

选定了类型，接下来就是落地。哪怕你用的是托管平台的一键证书，我也建议至少把下面这几个关键概念搞清楚，否则出了问题连日志都看不懂。

5.1 申请前必须做的两件事：生成CSR和保管私钥

几乎所有证书申请流程，第一步都是生成密钥对。私钥留在自己服务器上，公钥放进CSR文件提交给CA签名。一个常见的错误是把CSR和证书混为一谈，实际上CSR只是请求文件，真正的证书是CA签名后返回的那一段内容。

生成CSR时，核心字段和私钥必须后续保持一致。私钥生成后建议放在独立目录，权限设置明确，只让运行Web服务的用户和部署账户可读。我见过不少团队把私钥直接放在网站根目录，结果被爬虫抓走，证书安全问题在这个时候就不是加密够不够强的问题，而是钥匙直接放门口的问题。

私钥的备份方式也很重要。我一般加密后放在独立的存储空间，并标注好别名和有效期，防止服务迁移时找不着。注意备份的一定是当前私钥，而不是初始化时生成的旧私钥，否则新证书和旧私钥不匹配，就会多一个“配不上对”的故障现场。

5.2 证书配置的顺序：证书链与私钥的拼接逻辑

CA返回的证书通常不止一段，而是包含了站点证书、中间CA证书和可能的根证书。浏览器验证站点证书时，需要从站点证书一路追溯到根证书。如果你只把站点证书贴进去，中间断链，很多客户端会报“证书链不完整”。

实际配置里，大多数Web服务器要求提供一个合并后的证书链文件，顺序是站点证书在最上面，中间证书跟在后面，根证书一般不需要包含。合并顺序错了也不行，我用Nginx排查过不少案例，客户说“明明证书没问题”，结果打开一看，证书内容顺序颠倒了。

使用Caddy这类自带自动化证书管理的Web服务时，证书链拼接是自动完成的。手动配置Nginx时，流程大致是这样：

# 生成私钥和CSR openssl req -new -newkey rsa:2048 -nodes \ -keyout domain.key -out domain.csr \ -subj "/CN=domain.com" # 签发完成后，组合证书链（站点证书在前，中间证书在后） cat domain.crt intermediate.crt > fullchain.crt # Nginx配置片段 server { listen 443 ssl; server_name domain.com; ssl_certificate /etc/ssl/fullchain.crt; ssl_certificate_key /etc/ssl/domain.key; }

配置完成后，第一件事不是刷新页面，而是先执行重载命令让配置生效。Nginx是nginx -t && nginx -s reload，这一点在上一节里也提过，是最容易被漏掉的动作。

5.3 上线后的验证手段：在线评分工具和命令行检查

证书上线后，别急着发朋友圈，先用工具打个分。业界公认比较严格的在线检测服务会从证书链完整性、协议版本、加密套件、漏洞风险等维度做评分，跑一遍基本能发现大部分配置问题。评分在B或A-以下，我一般不会让站点进入正式推广阶段。

命令行验证同样有必要，特别是排查具体报错时，在线工具往往只能给到“整体不合格”，定位不到具体证书段：

# 查看站点实际下发证书的详细信息 openssl s_client -connect domain.com:443 -servername domain.com \ -showcerts -state

重点检查输出里s的签发者和使用者字段是否匹配你申请的域名，也要确认返回的证书段是否只包含站点证书而没有中间证书。早年在Nginx上遇到过只配置单段证书的情况，客户端反复握手失败但浏览器却显示正常，打开命令行才发现异常。

5.4 我遇到过的三类高频故障：链不完整、没重载、SAN缺失

把多年踩坑经历浓缩成三类最常遇到的问题，每个都对应一套排查思路。

第一，证书链不完整。浏览器提示“不信任的证书颁发机构”或“证书链错误”，这类问题优先检查证书合并文件里的排列顺序和文件完整性，不要只看第一段。确认中间证书没有被漏掉，尤其是连续续期后，CA可能会更换中间证书结构，旧文件可能已失效。

第二，证书没被重载。修改证书文件之后服务没重启，要么弹旧证书，要么提示“私钥与证书不匹配”。排查时先比对系统里证书的实际指纹和签发时间，再确认进程是否还在使用旧文件。这个过程我用过很多次，基本三步就能定位：md5sum对比文件、nginx -t检查配置、reload后重测。

第三，SAN域名缺失。只签了domain.com，但访问www.domain.com的时候浏览器报警，因为证书里的主体备用名称没有匹配该域名。这种问题反复出现，尤其是团队里同时管理多个二级域名时。解决办法是申请时把所有需要保护的域名写进SAN列表，别默认CA会帮你把子域都包进去，这个预设几乎每次都是错的。

另外一个容易被忽略的细节是证书到期监控。别依赖你的记忆，也别依赖某一个人的排班表。我在部署任何证书时都会顺手设置一个自动检查任务，每天跑一次，剩余天数低于阈值就触发告警。这类可以写进网站的监控脚本里，也可以在证书管理平台开通到期提醒，总之别等到过期了才让用户告诉你。

6. 证书上线后容易被忽视的加固项：HSTS、OCSP Stapling与算法选择

证书装上、HTTPS通了，距离“安全”还差几道工序。这几个项目讨论得不多，但直接影响连接速度、隐私保护和兼容性。

6.1 OCSP Stapling：让证书吊销状态查询不再成为性能黑洞

浏览器收到证书后，需要确认该证书有没有被提前吊销。传统方式下，浏览器会主动去访问CA的在线查询接口，也就是OCSP服务。这个额外请求会拖慢首次连接速度，更重要的是，它会把用户的访问行为暴露给CA，形成一层隐私泄露风险。

服务器主动提供OCSP查询结果的方式叫OCSP Stapling，相当于提前把“该证书未被吊销”的凭证和证书一起发给浏览器，浏览器省掉一次外部查询。启用后，握手阶段少一次RTT，同时用户隐私也得到保护。

实际部署时有一点要注意：操作系统和Web服务需要能正常访问签发该证书的CA的OCSP地址，如果这个地址连不通，Stapling会静默失效，签发的状态缓存也无法更新。我见过不少站点启用了Stapling，但证书链里带的OCSP地址指向一个老旧域名，结果请求超时失效，变成了摆设。排查时可以用命令行输出里的OCSP响应信息来判断Stapling是否真正生效。

6.2 HSTS别急着开：max-age、includeSubDomains和预加载

HSTS是一个安全策略，强制浏览器在一段时间内只能用HTTPS访问你的站点，一旦开启，浏览器就不会再尝试HTTP。它能够彻底杜绝降级攻击和中间人浏览器劫持，但配置不当会带来一个更麻烦的局面：当你还没做好全站HTTPS时，一旦声明了HSTS并设置了较长的max-age，客户端会记住这个约定，后续你想临时让某个子域走HTTP做调试，会发现根本访问不上。

我用HSTS的经验是分阶段推进。第一阶段先把HTTPS真正做到整个站点可访问，所有HTTP请求都有301跳转到HTTPS版本，确认没有混用。第二阶段再开启HSTS，max-age先从一小段时间开始，比如几天，观察一段时间没有异常再逐步拉长。最后如果你想提交到浏览器官方维护的预加载列表，会变成持久化约定，回退极其麻烦，所以这一步只在确认短期内不会再改动的时候做。

还有includeSubDomains这个字段，开了之后所有子域全部强制HTTPS。如果你的某个子域还挂着纯HTTP的接口、老旧设备或内部工具，直接开这个字段几乎一定会出事。子域结构不清理干净之前，不要开。

6.3 RSA还是ECDSA：加密算法选型对照

证书的密钥算法也直接影响兼容性和握手速度。RSA是通用性最强的算法，几乎所有设备都能兼容，2048位是当前基线强度；ECDSA密钥短、计算快，握手中CPU开销更少，移动设备和新一代浏览器表现更好，但老旧的系统可能不识别。

现在的实践做法，如果条件允许，可以同时配置两套证书，Web服务根据客户端能力自动选择。做不到双证书时，我建议默认选择RSA 2048，因为兼容性上限最高。追求极致性能的团队可以用ECDSA证书作为主力，但要在测试环境里跑一遍主流操作系统的旧版本浏览器，确认兼容性符合你的用户群体。

另外还有一个小提醒：密钥抢占和证书重新签发有时是两回事。如果怀疑私钥泄露，不仅需要换新的密钥对，还要走一次吊销旧证书的流程，光重新签一张并不能让泄露的旧证书失效。

6.4 TLS版本与套件的收紧标准：我实际用的配置

证书解决的是“你是谁”，TLS版本和加密套件解决的是“传输过程用什么方式保护”。现在业界统一的方向是只启用TLS 1.2及以上版本，把TLS 1.0、TLS 1.1从配置里移除。早期系统默认支持的范围都很宽，需要手动收紧。

加密套件的选择优先级，我一般按这个顺序判断：优先启用支持前向保密的套件；禁用旧版弱套件；在TLS 1.3环境下，加密套件本身被简化，重点反而是确认没有开启不安全的协议版本。很多第三方测评工具会直接列出不安全的协议选项，按提示逐个关掉就好。

配置完成之后，我会再跑一轮全量测试，确保主流浏览器、手机端、接口调用方都能顺利握手。加密不是越强越好，而是要在你的用户能顺畅访问的前提下，把不安全的选项全部关掉。这一步做完，证书的完整价值才算真正落地。

最后分享一个我自己的小习惯：每次帮客户处理完证书相关的事务，我都会顺手在日历里记一个复检提醒，证书到期前30天就开始准备续期，续期完成后再跑一次在线评分和命令行验证，双重确认。证书这个事，容易让人产生“装上就完事”的错觉，实际上从申请、部署到日常维护都是持续性的工程。把这个流程养成习惯之后，你会发现绝大多数SSL相关的事故都能在发生之前被拦下来。