一、动手之前先备齐三样

第一样是域名的控制权。验证环节要证明你确实管着这个域名，所以要么能往站点根目录里放一个指定文件，要么能在域名解析里加一条记录。要留意的是，控制权通常落在能操作解析或服务器的那几个人手里，如果你只有内容编辑权限，得先找对人，否则流程会卡在第一步。第二样是服务器的部署权限，证书签发出来要装到站点上，装的位置可能是反向代理层、也可能是应用层，提前确认清楚由谁改配置。第三样是一个能收信的联系邮箱，用于接收签发通知与到期提醒。三样备齐再动手，比一边申请一边找人要快得多。还有个常被低估的细节：若域名解析由外部服务方代管，加记录往往要走对方的管理入口，提前问清谁来操作、多久能生效，也算备料的一部分，否则很容易在验证环节空等一天。顺手再做件小事：把域名、部署位置、负责维护的人三栏写成一页纸，后续交接或排查时都有据可查。

二、先定清楚这张证书要覆盖哪些名字

证书不是绑一台服务器，而是绑一组域名。申请之前把清单列出来：主域、带 www 的别名、移动站、后台管理入口、接口域名，以及未来半年内计划上线的子域。清单列完再决定形态：只覆盖一个名字的、覆盖若干个指定名字的、覆盖某一级全部子域的，三种形态的申请方式与后续维护成本都不一样。这一步最容易出的错是漏掉别名——主域配好了，带 www 的访问仍然报警，用户从搜索结果或他人转发的地址点进来恰好落在没配的那个名字上。另一种常见疏漏是把内网与测试环境的域名混进同一张证书，正式环境的证书里出现测试域，既不专业也没有必要。清单建议存一份，半年后新增子域时可据此判断是给现有证书加名字还是另签一张，不必临时拍脑袋。判断依据其实就一条：这张证书后续还会不会持续加名字，会，就选可扩展的形态；只是偶尔加一个，现签更省事。还有个副作用值得提前知道：一张证书里堆的名字越多，任何一处变更都要重签整张，牵连面也就越广，管理复杂度会跟着上去。

三、域名验证的三种方式

第一种是文件验证，在站点根目录放一个指定内容的文件，签发方从外部访问确认。这种最直观，但如果站点有跳转规则、访问限制或者缓存层，验证请求可能被拦在外面。第二种是解析验证，在域名解析里加一条指定记录，等生效后由签发方查询确认。它的好处是不依赖站点可用性，站点暂时没起来也能签；代价是要等解析生效，有时几分钟、有时更久，急着上线时容易误判为失败。第三种是邮箱验证，向域名管理邮箱发一封确认信。要记住一条硬性规则：需要覆盖某一级全部子域的形态，通常只能走解析验证，用文件验证覆盖不了尚未建站的子域。选方式时按这个顺序想：先看证书形态是否只支持解析验证，再看站点当前能不能对外访问，最后才考虑邮箱这种方式。失败时也能靠提示定位：提示找不到文件，问题多在站点的访问路径或跳转规则；提示记录不存在，问题多在解析尚未生效或记录值填错。这两类原因的处理方式完全不同，看提示比反复重试有效。三种方式并不互斥，有的签发方允许失败后换一种再试，但同一张申请反复来回切换容易被判定为异常，建议一次选定，按提示排查根因。

四、签发环节的关键在私钥

签发前要在服务器上生成一对密钥，公钥部分随申请一起提交，私钥必须留在自己手里，任何时候都不该交给第三方。这一点常被忽略：有人图省事把私钥发给服务方代装，等于把站点的身份凭据交了出去，后续出事很难界定责任。签发的另一个细节是证书链，签发方发给你的通常不止一张证书，而是站点证书加一到两张中间证书。少了中间证书，桌面浏览器有时能自行补齐，手机端却可能直接报错，于是出现“电脑打开正常、手机提示不安全”的怪现象。拿到文件后先核一遍：文件是否完整、域名是否与申请清单一致、有效期起止时间是否正确。私钥的存放也值得说一句：放在只有服务进程可读的目录，权限收窄，不要随手拷进代码仓库或聊天工具，一旦外流就等同于站点身份被他人掌握。

五、部署要做对三件事

第一件是把证书与中间证书按正确顺序装到站点上，顺序颠倒会导致链路校验失败。第二件是确认绑定关系，证书要绑在承接该域名的那个入口上；如果前面有流量转发层，证书通常装在这一层而不是后面的应用服务器上。第三件是选择允许的协议版本与加密套件，把明显过时的版本关掉，同时保证主流客户端仍能连上，两者需要兼顾，一味道收紧会把一部分正常用户挡在门外。同一台入口上跑多个站点时，还要确认是否按访问的域名自动选择对应证书，否则会出现访问甲站点却返回乙站点证书的情况，浏览器直接判为不匹配。改配置之前建议先留一份回滚预案：旧证书与旧配置各存一版，新证书若在部分客户端上出问题，能迅速退回原状，而不是急着再签一张来填坑。

六、从外部视角验收一遍

装完之后不要只在服务器本机上测。本机测试往往走的是内部路径，绕过了真实的解析与转发链路，结果是自测通过、外部打不开。更可靠的做法是从外部的检测入口发起一次校验，看三件事：证书链是否完整、域名是否匹配、有效期剩余多久。然后打开页面看有没有混合内容提示——页面本身走加密连接，但里面引用了不加密的图片、脚本或样式，浏览器会把整体标为部分不安全，这类问题通常出在模板里的固定地址上。最后用手机流量而不是站内无线网络再试一次，能发现一些只在移动网络下暴露的链路问题。验收时间建议挑业务低峰，万一需要改动入口配置，影响面最小；检测结果显示证书链缺项时，回部署那一步补齐即可，不必重新申请。另外浏览器会把检测结果缓存一段时间，改完配置后换个无痕窗口或换台设备复看，防止被旧状态误导、对着已经修好的问题继续查。

七、把续期做成自动的

不收费的证书有效期普遍不长，这是签发机制决定的，目的是缩短凭据失效后的暴露窗口。短有效期意味着续期必须自动化，靠人工记日子迟早会漏。可行做法有两条：一是用签发方提供的自动化方式，让客户端定期自检、到期前自动换新并通知服务重新读取配置；二是在自动化之外再挂一层到期提醒，作为兜底，因为自动化本身也可能因为验证记录变动、目录权限变化而失败。提醒建议设在到期前两周与前三天各一次，收到后确认新证书是否已生效。最后留一份部署记录，写清证书装在哪里、由谁维护、续期由哪条链路完成，换人接手时才不至于从零排查。自动化跑起来之后也要定期抽查一次：确认实际生效的确实是新签发的那张证书，而不是自动化执行成功、部署却没落到位。这种情形不算罕见，且往往要到证书真的过期才被发现。

结语

申请不收费的证书，流程本身并不复杂：备齐域名控制权与部署权限，按实际域名清单选对形态，验证方式按形态与站点状态来定，签发后守住私钥、装全证书链，部署时对齐绑定关系与协议设置，验收从外部视角看链路与混合内容。真正决定长期省不省心的，是最后一步：把续期交给自动化并留一层到期提醒。走通一次之后，这套流程就变成了可重复的例行操作。