一、为什么申请方法要先讲"顺序"
1.1 证书的本质是一句被背书的承诺
SSL证书做的事,说到底是回答两个问题:这个域名的控制权属于你吗?站在域名背后的主体是不是它自称的那一个?证书本身只是一小段经过签名的数据,浏览器之所以愿意显示那把小锁,是因为这段数据由受信任的签发机构用它的私钥签过名,而签发机构之所以敢签名,是因为它在签名之前完成了对你身份的核验。所以申请方法的每一步,本质上都是在为"我敢签名"这件事积累证据。
1.2 每一步都在给上一步盖章
把七步按顺序排开,依赖关系就一目了然:
1、证书类型决定了后面要准备哪些材料、走过几道核验,所以它必须排在最前面;
2、密钥对与申请文件是后续所有核验的对象,它们必须在提交申请之前就生成好;
3、域名核验和组织核验是签发的前置条件,签发机构看到核验通过的记录才会落笔签名;
4、签发出来的文件要成套拿走,才能完整部署;部署之后还要做一次验证,确认整条信任链没有断点;到期之前再安排续期与轮换,让防护不出现空窗。
1.3 顺序颠倒的三种典型代价
① 先提交、后定类型:类型一变,所需材料与核验深度随之改变,已经提交的信息要重新补交,核验流程从头再走一遍。
② 私钥由他人代生成:私钥一旦脱离自己的掌控,这份证书所承诺的"只有你能解密"就失去了意义,只能作废重来。
③ 先部署、后验证:部署完成不等于链路完整,缺少中间证书时,多数环境能正常打开,个别环境却会提示不受信任,排查起来格外费时。
二、第一步:先定类型,再谈流程
2.1 三档证书核验的深度不同
按照核验深度由浅到深,常见的证书分为三类:
1、域名型:只核验你对域名的控制权,签发速度快,适合个人站点、测试环境、内部系统等对主体身份展示要求不高的场景;
2、组织型:在域名核验之外,还要核验申请主体的真实存在与合法性,证书里会带上单位名称,适合企业官网、对外业务系统等场景;
3、扩展型:核验最为严格,除域名与主体信息外,还会对主体的存续状态、经营信息、申请意愿等进行多轮确认,适合金融、政务、交易类业务。
2.2 类型选错,代价在后面才显现
类型不是"越深越好",而是"与场景匹配最好"。一个只做内容展示的站点选了扩展型,多出来的核验材料会拖慢上线节奏;一个承载登录与交易的业务选了域名型,虽然能加密传输通道,但访问者看不到单位身份,信任展示就不完整。所以在动手之前,先把三个问题想清楚:这个域名承载什么业务、访问者是否需要看到主体身份、这个业务要接受什么样的合规检查。
2.2.1 域名数量也要一并想清楚
一个证书可以只保护一个域名,也可以覆盖一个主域名下的多个子域名,或者在一张证书里列出若干个互不相同的域名。这一步同样属于"先定类型"的范畴,因为域名范围直接写进申请文件,签发之后再想增删,只能重新申请。
三、第二步:密钥对与申请文件,必须在提交之前诞生
3.1 私钥留在自己手里
申请的第一步技术动作,是在自己的服务器上生成一对密钥:一把公开出去的公钥,一把绝不外传的私钥。访问端与服务端握手时,用公钥加密的信息只有对应的私钥能解开,这就是加密传输通道得以建立的根基。生成密钥对时有两个常见选择:
① 采用广泛支持的算法,密钥长度一般不低于2048位,对安全要求更高的场景可以用到4096位;
② 采用同等安全强度下长度更短、握手更快的椭圆曲线算法,在移动网络环境下体验更好。
在有国产密码应用要求的场景里,还可以选择采用国产密码算法的证书,具体支持情况以天翼云官网和官方渠道的说明为准。
3.1.1 私钥保管的三条底线
1、生成私钥的环境必须是自己可控的服务器或硬件设备,不要在不明环境里生成后传给自己;
2、私钥文件的访问权限要收紧到必要的服务进程,不要放在对外可读取的目录里;
3、私钥一旦疑似泄露,正确的处理方式是重新生成密钥对并重新申请证书,而不是继续使用。
3.2 申请文件里写了什么
这份申请文件由刚生成的那把私钥签名,里面写着域名、主体名称、所在地、公钥等内容。签发机构收到后,会用文件里的公钥校验签名是否匹配,确认"你确实持有与这把公钥配对的私钥",再对文件里的域名与主体信息展开核验。换句话说,申请文件既是申请表,也是一次自我证明。
四、第三步:域名核验,三种方式各有适用场合
域名核验要证明的是"这个域名归你管"。常见做法有三种,选择哪一种,取决于你对域名解析和服务器文件的控制能力。
4.1 解析记录核验
在域名的解析记录里添加一条指定内容的记录,签发机构查询到这条记录即视为核验通过。这种方式对服务器没有额外要求,也支持一次核验覆盖多个子域名,是最通用的一种,唯一的变量是解析生效需要一点时间。
4.2 文件核验
把签发机构给的一个指定文件放到网站的特定目录下,让它能通过地址栏访问到,即完成核验。这种方式生效快,但要求服务器的对应端口对外可达,且文件路径不能被其他规则拦截。
4.3 邮箱核验
签发机构向域名注册信息中登记的邮箱或约定前缀的邮箱发送一封确认邮件,按邮件提示完成确认即通过核验。这种方式最为省事,难点在于邮箱地址必须真实可用、且收信权限掌握在申请者手里。
4.3.1 核验失败,多半卡在这三处
① 新添加的解析记录尚未生效,可以稍候再用查询工具确认;
② 指定文件被重定向规则或访问控制挡住,返回的内容与预期不一致;
③ 确认邮件落在了无人值守的邮箱里,或者被邮件网关拦下。
五、第四步:组织核验,让"你是谁"被确认
域名型证书走到上一步就可以进入签发,组织型与扩展型还要多走一道组织核验。
5.1 材料准备的两个原则
1、一致:申请文件里的主体名称、证件信息、公开可查的登记信息三者必须完全对应,简称、曾用名、多余空格都可能成为卡点;
2、有效:提交的联系渠道要能接通,核验电话与确认邮件会在短时间内到达,接不上就会拖长整个周期。
5.2 回访确认是流程的一部分
签发机构可能会通过公开渠道查到的联系方式进行回访,确认本次申请确实是主体自愿发起。这不是额外刁难,而是整条信任链上不可省略的一环:只有经过这一步,"证书里写的单位名称就是这个单位"这句话才成立。
六、第五步:签发与下载,一次拿全三样东西
核验通过后,签发机构会用中间证书对应的私钥为你的证书签名,中间证书又由根证书签名,这样就形成了"根证书—中间证书—你的证书"三级链条。下载时要拿全的是:
1、你的证书文件,也就是那条链条的末端;
2、中间证书文件,用来把你的证书和根证书串起来;
3、此前生成的私钥文件,它不在签发机构那里,必须由你自己妥善保管,部署时与证书配对使用。
6.1 少拿中间证书会怎样
如果只部署了末端证书,多数环境能依靠自身补全链条正常工作,但总有一部分环境因为拿不到中间环节而无法确认信任关系,表现为"有的地方能打开、有的地方提示不受信任"。这类问题排查成本高,最好的办法是从一开始就成套部署。
七、第六步:部署与验证,别让链条断在最后一环
7.1 部署位置取决于入口在哪里
证书要部署在真正终止加密连接的位置上:如果加密通道在负载均衡或内容分发节点上就结束了,证书就要部署在那里;如果直达源站,就部署在源站的网页服务上。部署位置搞错,表现出来的是"证书配了却没生效"。
7.2 验证要做的三件事
① 用外部工具检查证书链是否完整、证书里的域名与正在访问的域名是否完全匹配;
② 检查协议与加密套件配置,关闭存在已知弱点的旧版本协议与弱套件;
③ 检查页面内的资源引用是否都走加密通道,避免"主页面是加密的、部分资源不是"的混合情况。
7.3 到期时间要提前算清楚
公开信任证书的最长有效期近年来持续收敛,已从过去的数年缩短到一年左右,行业规范还在进一步收紧。这意味着续期从"几年想起来一次"变成了"每年都要安排的动作",把到期日写进运维清单,是部署完成后就要立刻做的事。
八、第七步:把续期做成常规动作
8.1 建立一份证书台账
一个稍具规模的业务往往有几十张证书,散落在不同环境里。建议用一份台账记录每张证书的域名、类型、签发时间、到期时间、部署位置与负责人,并设定到期前两次提醒:一次留足材料准备与核验的时间,一次作为临期兜底。
8.2 轮换与应急都要提前想好
续期时可以选择沿用原私钥重新签发,也可以在续期的同时更换密钥对,后者安全性更好。此外还要准备一套应急办法:万一某张证书因主体信息变更、私钥外泄等原因需要作废,要能在最短时间内完成重新申请与部署。值得一提的是,证书被作废后,访问端会通过在线状态查询机制或吊销列表获知这一情况,因此应急流程演练同样重要。
九、天翼云SSL证书服务:把七步串成一条线
9.1 申请入口统一,材料一次沉淀
天翼云SSL证书服务提供域名型、组织型、扩展型等多种证书类型的申请通道,申请过程中的类型选择、域名范围确认、主体信息填写、核验状态跟踪都在统一的控制台内完成,材料与进度可随时查看,减少了在多个系统之间来回切换的麻烦。
9.2 统一管理,让台账不再靠记忆
证书签发之后,天翼云提供统一管理能力:证书的域名、类型、状态与到期时间集中呈现,配合到期提醒,可以把上文提到的那份台账交给系统来维护,到期风险从"靠人记"变成"系统提前告知"。
9.3 与云上安全能力形成合力
证书只是加密传输与身份展示的一环。天翼云可将证书服务与云防火墙、安全加固等安全产品协同使用,在加密通道之外补上访问控制、入侵防范等能力,让"通道可信"与"访问可控"两件事一起成立。
9.4 国家云的合规与本地化支撑
作为国家云服务商,天翼云在合规资质、数据安全与本地化服务方面持续投入,证书申请与管理流程依托这套体系运行,能够适配政务、金融、教育等行业对合规与审计的要求。涉及产品能力、资质与荣誉的具体内容,以天翼云官网和官方渠道发布的信息为准。
十、三个高频疑问
1、一个域名可以同时用多张证书吗?可以,但同一个服务入口在同一时刻只对外呈现一张,多余的做法会增加管理复杂度,按需申请即可。
2、换了服务器,证书要重新申请吗?通常不需要,只要把证书文件与私钥一起迁移到新的服务器正确配置即可;但如果私钥在迁移过程中脱离了可控范围,就应当重新生成并重新申请。
3、子域名很多,是逐张申请还是用通配形式?数量少且各自独立时,逐张申请更清晰;同属一个主域名、且需要频繁新增时,覆盖子域名的形式更省事。两种做法在核验方式上略有差异,可按实际运维习惯选择。
十一、小结
SSL证书申请方法看似是"填资料、等签发",实则是一条环环相扣的凭据链:类型定在最先,密钥对在提交前诞生,域名与组织核验为签发背书,签发后成套下载、完整部署、及时验证,最后把续期与轮换变成常规动作。把这七步的顺序走对,申请过程就会顺畅许多;而天翼云SSL证书服务所做的,正是把申请、管理、部署与提醒串成一条不断裂的线,让每一次加密连接的背后,都有凭有据。