一、为什么不同站点做法不同

1.1 起决定作用的是两个变量

第一个变量是名字结构：要保护的是一个名字、几个并列的名字，还是一整层派生名字。名字结构决定了该选哪种类型的凭证，也决定了以后新增站点时要不要重新申请。

第二个变量是入口数量：加密在哪一层结束，是网站服务本身、负载均衡入口，还是分发节点。入口决定了凭证要装几次、装在哪里，也决定了更换时的操作量。

把这两个变量代进去，常见的站点大体分成五类。认清类别之后，很多看起来棘手的问题会自然消失，因为你知道它属于哪一步的正常现象。

1.2 认清形态能省掉哪些返工

① 名字漏申请。把一个名字当成了几个，最常见的是把带前缀与不带前缀的访问名字视为同一个；

② 装错位置。凭证装在机器上，实际对外却是经由入口访问，结果访问时仍提示不安全；

③ 覆盖不足。子域新增以后才发现所选类型覆盖不到，只能重新申请并重新部署。

这三类返工都不难避免，前提是动手前花几分钟把形态判断清楚。

1.3 一句话的结论

先定名字清单，再定落点位置，最后才动手提交。顺序反过来，就容易出现“申请下来了却装不上”“装上了却不覆盖”的尴尬。

二、三个名词先说清楚

2.1 名字结构：凭证究竟保护哪些名字

按覆盖方式，常见的凭证类型可以归为三类。覆盖单个名字的，只保护明确写下的那一个；覆盖多个指定名字的，在一张凭证里列出若干名字，数量固定；覆盖同一级派生的，用通配写法一次性覆盖某个名字下的所有同级派生名字。

2.1.1 通配写法的边界

通配只能覆盖一层。以某个名字为例，通配写法可以覆盖它下一级的各种派生名字，但无法覆盖再下一级。理解了这一层，就能判断单靠通配够不够用，还是需要补充一张覆盖其他名字的凭证。

2.1.2 数量、结构、增长趋势一起看

名字少而固定，按名字逐一覆盖即可，管理最简单；名字数量中等但散在不同层级，用多名字类型更整齐；子域较多并且还在持续新增，通配写法更从容，新站点上线时不必每次重开一张。判断标准不是“哪个更高级”，而是“未来半年会不会新增”。

2.2 落点：加密在哪一层结束

一次访问可能穿过若干环节：入口、分发节点、网站服务。凭证只需装在“对外应答的那一层”，后面的链路可以选择继续保持加密，也可以按内部约定处理。落点选得对，一张凭证就能管住一个站点；落点没想清楚，就容易出现同一个站点装了两张、或者一张都没装对的情况。

2.3 覆盖范围不等于整页都安全

凭证保护的是通道，不是页面里的每一项资源。如果页面中引用了以明码方式加载的图片、脚本或样式，浏览器仍会提示“部分内容不安全”。这类现象常被误认为凭证没装好，实际是页面里的引用地址没有统一。自查时把这一条单独看，能省下不少排查时间。

三、五类站点的具体做法

3.1 第一类：单站点、单名字

这是最常见也最简单的一类。判断标准是：只有一个对外访问名字，一台机器承载，没有前置入口。做法上，提交一个名字，完成核验，把拿到的凭证装进网站服务的配置，重启或重载服务，再按后面的自查动作确认一遍即可。

这一类最容易被忽略的细节是：带前缀与不带前缀的访问名字，在凭证看来是两个名字。只申请其中一个，另一个访问时仍会提示不安全。完整的做法是提交时把两个名字都列上，或者统一访问入口，把其中一个重定向到另一个。

3.2 第二类：主站加若干子域

主站之外还有若干子域，比如文档、帮助、活动页各自独立。这一类要先数清两件事：现在有几个，未来半年会不会再增加。数量固定且不多，用多名字类型一次覆盖指定名字，管理上最清楚；数量多且持续新增，用通配写法更省事。

需要提醒的是，覆盖方式一旦确定，新增名字的处理方式也随之确定。用多名字类型的，新增就要重新提交；用通配写法的，同一层的新名字直接生效。这一点在规划阶段想清楚，比上线后返工要轻松得多。

3.3 第三类：一台机器挂多个站点

多个站点共用一个入口时，问题不在于能不能装，而在于访问时凭什么判断该用哪一张。常见做法是按访问名字区分凭证，服务软件按名字选择对应的那一张。需要先确认所用软件支持这种按名字选择的方式，再按站点分别绑定。

操作上有两个要点：一是每个站点使用独立目录存放凭证与私有部分，避免混放；二是保留一张默认凭证作为兜底，用于那些没有单独配置名字的访问，否则可能连默认站点都无法正常建立连接。

3.4 第四类：经负载均衡或分发入口对外

这一类站点的加密在入口层结束，凭证只需要装在入口，不必逐台机器安装。好处是更换时只改一处，几十台后端也不用跟着动；前提是入口与后端之间的链路按内部约定处理，且后端不直接对外暴露。

容易忽略的一点是回源策略：凭证更新后要确认入口与后端仍是同一套衔接方式，别把原本正常的内部访问规则改坏。另外，如果源站地址仍可被直接访问，那么即使入口配好了凭证，用户从别处进入时依然可能看不到安全标识，这一点需要在架构上收口。

3.5 第五类：只对外提供接口的站点

给应用、小程序或内部门户提供接口的站点，没有可浏览的页面，也就无法靠“看地址栏”判断是否生效。做法上要换个自查方式：用请求工具发起一次访问，查看握手是否成功、返回的凭证信息里名字与有效期是否正确。

这一类最常出问题的地方是名字对不上：页面走一个名字，接口走另一个名字，申请时只覆盖了前者，接口调用方就会因名字不一致而拒绝连接。提交之前把调用方实际使用的名字逐个核对，比事后排查要省时得多。

四、天翼云如何承接这五类站点

4.1 一个入口完成申请与核验

在天翼云SSL证书服务里，类型选择、名字提交、归属核验、凭证下载集中在同一处，不需要在多个系统之间来回切换。三类覆盖方式都在可选项里，按前面说的名字结构直接对号入座即可。

4.2 落点可选，不必迁就架构

凭证既可以装在自己管理的云主机上，也可以直接配置到负载均衡或内容分发入口，由平台完成下发与生效确认。对第三、第四类站点来说，这意味着加密可以落在最合适的那一层，而不是被迫在每台机器上重复配置。

4.3 集中管理与到期提示

凭证数量一多，管理方式就得跟着变。集中管理让每张凭证的使用位置、覆盖名字与有效期在同一处可查，临近到期时由系统主动提示，而不是等人想起来。配合按项目与角色划分的权限，谁能提交、谁能下载、谁能下发，可以分开设置，人员调整时按角色变更即可。

4.4 合规资质与公开认可

作为国家云，天翼云在云网安全与合规方面持续投入，相关资质与安全能力通过官方渠道公开发布，为需要接受检查与审计的单位提供了可引用的依据。在公开报道中，天翼云入选央企十大超级工程，获得算力中国年度突破成果、十大硬核科技等评价，并获世界互联网大会杰出贡献奖。这些认可指向的是基础设施层面的规范与稳定，也正是一张凭证能长期安稳运行的前提。

五、申请之后的三件事

1、给每张凭证建一条记录。写清覆盖哪些名字、装在哪一层、由谁维护、到期时点，四条足够。凭证一多，这份记录就是唯一能说清“哪张在用”的东西。

2、把到期提示接到团队能看到的地方。提示发给一个人，那个人休假或调岗就会断档；接到共享的通道里，事情就不依赖某个人的记忆。

3、每次改动后按同一套动作自查。主名字与常用别名逐个访问、核对凭证详情、抽查含表单与登录的页面，三步固定下来，改动再多也不会漏。

回到最初的问题：天翼云免费SSL证书怎么申请？操作上确实只有提交、核验、取得、部署这几步，把这些步骤与自己的站点形态对上，才是真正省事的地方。名字写全、落点选对、自查固定，这三件事做到，一次申请就能长期安稳。