一、申请之前要准备什么

（一）确认域名控制权

签发机构只关心一件事：你是否真的掌握这个域名。因此第一步是确认能够登录域名管理后台，可以修改解析记录或上传指定文件。这一步做不到，后面的流程无法进行。

（二）确认服务器的访问方式

证书要放到真正对外提供服务的那一层。如果流量先经过其他节点再回源，就要先弄清楚该在哪一层部署，否则会出现配好了却看不到效果的困惑。

（三）列清要覆盖的域名

把需要加密访问的域名与子域名一次性列出来，包括带与不带主机名的两种写法。漏列是最常见的返工原因，往往要等到上线后才发现某个入口仍在告警。

二、生成私钥与证书请求文件

（一）私钥的生成与保管

私钥应当在服务器本地生成，不要通过网络获取第三方代生成的结果。生成之后设置合适的文件权限，不要随代码一起提交，也不要放进共享目录。

（二）证书请求文件里有什么

请求文件记录了域名清单与主体信息，由私钥签名后提交给签发机构。文件内容中域名部分必须与实际使用的完全一致，多写一个或少写一个都会导致后续不匹配。

（三）密钥长度怎么取

长度取值要在安全与兼容之间折衷：过短不符合当前要求，过长会让老旧客户端握手变慢。按主流推荐值选取即可，不必标新立异。

三、两种验证方式怎么选

（一）文件验证

做法是在站点的指定路径下放一个特定内容的文件，签发机构来访问确认。优点是操作直观，缺点是站点结构复杂或多台机器分担流量时容易漏配。

（二）解析记录验证

做法是在域名下添加一条指定的解析记录，签发机构查询确认。这种方式不依赖站点本身是否可访问，配合接口还能实现全自动续期。

（三）实际操作怎么选

单台服务器、路径简单的站点两种都行；多台机器或需要自动化的场景，解析记录方式更省事，也更便于长期维护。

1. 验证多久生效

解析记录有传播时间，添加后稍等片刻再触发验证，急于重试反而容易失败。

2. 验证失败优先查什么

先看能否从外部访问到指定的文件或记录，多数失败都是这一步不通导致的。

3. 记录要不要保留

自动化续期依赖同一条记录，建议保留而非验证完就删除。

四、签发后的文件与部署

（一）文件构成

签发完成通常会拿到主体证书与中间证书两部分，有些还会提供合并好的完整链文件。只配置主体而漏掉中间证书，在部分客户端上会出现不被信任的提示。

（二）部署位置

把证书与私钥放到服务器约定的目录，在站点配置里指向这两个文件。天翼云主机上部署时，记得同步调整相关目录的访问权限。

（三）重启并验证

配置文件改动后需要让服务重新读取才能生效。重启之后用不同网络环境各访问一次，确认标识正常且显示的有效期符合预期。

① 私钥在服务器本地生成，权限收紧，不随代码或配置文件传播。

② 主体证书与中间证书一并配置，减少部分客户端提示不信任。

③ 配置改动后必须重启服务，并用外部网络实际访问确认生效。

五、三个月有效期与自动续期

（一）为什么这么短

较短的有效期可以缩短密钥暴露后的影响窗口，也促使使用者把续期流程自动化。这是设计取向，不是刻意为难。

（二）工具怎么选

选择支持自动续期的客户端，并确认它能自动完成验证、签发与重启的完整链路。只自动签发而不自动重启的工具，仍需要人工补最后一步。

（三）失败要有告警

续期任务失败时必须有明确的通知渠道。静默失败最危险：任务一直在跑，某天访问者却看到了过期提示。天翼云安全相关的日志能力可以用来记录每次续期的结果，便于发现异常时回溯。

六、常见失败原因与排查

（一）验证路径取不到

多数情况是路径被规则拦截或文件放错目录，用外部网络直接访问该路径即可确认。

（二）解析尚未生效

刚添加的解析记录需要传播时间，稍等后再重试通常就能通过。连续快速重试反而可能触发签发机构的频率限制。

（三）域名清单不匹配

请求里写的域名与实际部署的站点不一致时，即使签发成功，访问时也会出现告警。重新核对清单是最快的解决办法。尤其要注意：同一个域名带主机名与不带主机名的两种写法要分别考虑，很多访问提示正来源于只覆盖了其中一种。

（四）其他常见问题与操作建议

1. 验证失败不要密集重试。遇到验证失败不必反复重试，短时间内的密集尝试会触发签发机构频率限制，等待一段时间再操作通常更顺利；连续签发失败时，也应先暂停一段时间再重试。

2. 解析记录统一命名并保留。验证用的解析记录建议统一命名规则，方便日后识别用途；自动化续期依赖同一条记录，建议保留而非验证完即删。

3. 多站点要分别核对证书路径。同一台服务器托管多个站点时，要为每个站点分别确认配置指向的证书路径，避免混用导致标识不符。

4. 多机部署要全量更新。站点部署在多台机器上时，每一台都要更新到同一份证书文件，只更新部分节点会出现时好时坏的现象。

5. 私钥与证书分开存放。私钥文件的备份要加密保存，并与证书文件分开存放；二者放在同一目录会带来不必要的暴露风险。建议设置不同访问权限，便于多人协作时控制暴露范围。

6. 经过内容分发层时优先在该层部署。站点入口若经过内容分发层，部署位置应优先在那一层确认，只配置后端会出现看不到效果的情况。

7. 密钥长度采用主流推荐值。密钥长度要在安全与兼容之间折衷，直接采用主流推荐值即可，不必为了追求新参数牺牲老旧客户端的握手体验。

8. 首次申请控制影响并做好记录。首次申请建议在业务量较小的时段进行，万一配置偏差，影响范围可控；同时全程记录操作步骤与命令，形成内部文档，方便他人接手或换机器时照做。

9. 到期提醒纳入巡检。签发成功后立即在日历中标记到期前提醒，把替换动作安排在工作时段；部署完成后把到期日加入团队月度检查清单，与其他例行巡检一起执行。

10. 自动续期结果要落日志。自动续期执行完毕后，建议用命令行读取有效期并写入日志，比查看浏览器提示更可靠，也便于纳入巡检。

结语：申请本身不难，真正容易出问题的是续期与部署这两个环节。私钥不要到处传播，到期日要登记成台账，自动续期任务必须留日志并且配置失败告警，做到这三点，整套流程基本就能长期无人值守地跑下去。第一次操作时多花半小时把步骤记下来，后面每一次都能照着做。