一、微信侧到底校验哪几条

把要求归拢，实质是七条。第一，必须走 HTTPS，明文请求不被接受。第二，证书必须由受信任的签发方签出，自签名证书一律不可用，终端策略更严的一侧会直接拒绝。第三，证书里的名字必须与部署的域名一致，填了哪个域名就配哪个证书，两者对不上请求即失败。第四，证书要在有效期内，过期即中断。第五，证书链必须完整，服务端要把中间证书一并出示，只给站点证书会让部分终端校验失败。第六，传输协议版本有下限，过低的版本已被排除在支持范围之外。第七，域名本身要满足基础合规条件，未完成备案的域名无法通过校验，也不能用地址段或本地地址代替。七条里前六条与证书直接相关，第七条属于前置条件，动手前先确认，能省掉大量白工。这七条还有一个共同点：任一条不满足时，用户在终端上看到的往往只是一句笼统的“请求失败”，没有具体原因。这也是为什么排查时要按顺序逐条排除，而不是凭印象改配置——证书问题在小程序里的表现相当一致，容易与域名未登记、后端接口异常混在一起。

二、域名配置的规则细节

证书备好了，还要在小程序后台把域名登记进去，这一步有几条规则容易踩。第一，分类登记：请求、上传、取回、长连接四类各有一份名单，分别配置，把上传用的域名填进请求名单里不会生效。第二，数量上限：每类名单的条目数有上限，量级在两百条左右，多数项目够用，但对接多个业务系统的项目要提前盘点。第三，修改次数：名单的调整有周期次数限制，量级在每月五十次上下，改之前先想清楚要加哪几个，别把调整当日常操作。第四，填写形态：以具体域名为准，不要写星号形态，也不要填地址段。第五，生效时间：保存后通常很快生效，但存在缓存，改完等几分钟再测，防止把缓存当成配置失败。第六，环境区分：测试、预发、正式若各用独立域名，都要分别登记，只在后台登记正式域名的项目，往往在体验版测试阶段卡住。

三、只核域名的证书够不够

先给结论：从加密级别与握手过程看，只核域名控制权的证书与核验单位身份的证书没有区别，微信侧的校验也不区分这两个等级，个人开发者与小体量项目用它完全够。需要斟酌的是业务属性。若小程序涉及支付、会员、用户敏感信息的收集与传输，往往会被要求提供更高的身份核验等级，这类要求通常来自支付通道的资质审核或行业规范，而不是微信的证书校验本身。判断办法很简单：看业务是否涉及资金与个人信息，看合作方是否在合同或接入要求里点明等级。若是，选核验单位身份的；若只是展示与查询类，选只核域名的即可。还有一点值得权衡：只核域名的证书有效期普遍偏短，一年要换几次，若续期不能自动化，反而会因为疏漏导致中断，这一点常被忽略。若业务当前用不上更高的核验等级，也不必为“以后可能要用”提前买单：等级不够时缺的是身份展示，而这类需求往往伴随业务阶段变化，等真到了那个阶段再换，比提前一两年签下来更合适。反过来，若合作方在接入时就明确要求展示单位身份，那就在第一次申请时选到位，省得中途返工。

四、覆盖形态按清单来定

小程序的域名往往不止一个：接口一个、静态资源一个、上传一个，加上测试与预发，很容易到五六个。选形态时按清单算三件事。第一，层级是否集中：若全部在一层子域下，用星号形态覆盖整层最省事，签一次，后续新增子域不必动证书。第二，是否跨主域：跨了不同主域，星号形态跨不过去，要么按主域各签一张，要么用一张多域名证书把具体名字列全，后者清单直观但每次加名字都要重签。第三，是否存在更深层级：星号只覆盖一层，两级以上的名字必须单列，规划时容易漏。除了形态，还要注意一条边界：不要把内部管理入口与对外接口放进同一张证书，两者的访问范围与风险不同，混在一起会让私钥外流的影响面扩大。若两张证书的成本差异不大，拆分通常更划算。清单列的另一个作用在后期：接口域名一旦增加，能立刻判断是给现有证书加名字还是另签一张。前者要重走签发与部署，后者只需新增一次部署，两者的时间成本差别不小，提前有清单就不至于临时拍脑袋。

五、失败率偏高的几个环节

把线上最常见的失败原因排一排，会发现多数不在证书质量上，而在部署细节。第一位是证书链不完整：服务端只出示站点证书，桌面端有时能自行补齐，小程序运行环境却会直接判定校验失败，表现为真机上请求失败、开发者工具里却正常。第二位是名字对不上：接口域名是二级的，证书里只有主域与带前缀的别名，请求必然被拒。第三位是签名算法与密钥长度不合要求：摘要算法过旧的证书已被排除在支持范围外，密钥长度也有下限，老旧证书在这两处最容易出问题。第四位是协议版本：服务端下限设得过高会把部分终端挡在外面，设得过低又不符合要求，两端要兼顾。第五位是真机与工具的差异：开发者工具可以关闭域名校验，看起来一切正常，真机上才暴露问题，所以上线前一定要用体验版在真机跑一遍，且安卓与另一类终端各测一次。

六、部署链路要全覆盖

一个请求从终端到后端，中间可能经过若干跳，任何一跳出示的证书不对，整体就失败。需要逐一确认的点包括：后端服务自身终止加密的地方、前置转发层、内容分发节点及其回源链路、以及各类安全设备上做加密连接终止的位置。这几处常出现的问题是“只换了后端”：后端证书更新了，前置层还挂着旧证书或者默认证书，外部访问拿到的仍是旧的那张，表现是后台看一切正常、线上却报警。处理办法是先把链路画出来，标出每一处终止加密的点，再逐个核对证书的签发对象与到期时间，形成一张对照表。换证时按这张表逐项替换，替换后逐项验证，防止漏项。链路较长的项目，建议在换证前先做一次全链路盘点，把没人维护的旧节点清理掉，比事后排查便宜得多。盘点时可以顺手做一件事：把每一处终止加密的节点对应的负责人写进表里。证书到期这类事情，最怕的不是技术难，而是不知道该找谁确认，有了负责人一栏，提醒发出去就能落到具体的人头上。

七、上线前核对清单

第一，域名已完成备案，且能通过外部访问。第二，证书覆盖的名字与后台登记的域名逐条对齐，主域与带前缀的别名都不缺。第三，服务端出示的证书链完整，从中间证书能一路追到受信任的根。第四，协议版本下限符合要求，同时不会把仍在使用的终端挡在外面。第五，摘要算法与密钥长度符合通行要求，没有沿用多年前签发的旧证书。第六，四类域名名单已按用途分别登记，测试环境域名也在其中。第七，链路上每一处终止加密的节点都已换上新证书，并逐个验证。第八，用体验版在真机上测试，两类终端各测一次，且换网络再测一次。第九，设置到期提醒并把续期做成自动化，同时在自动化之外留一层人工兜底。九条核完，上线环节基本不会再被证书问题拦住。

结语

选小程序的证书，实质是把三件事对齐：微信侧的七条校验、自己那张域名清单、以及链路上每一处终止加密的节点。验证等级按业务属性定，涉及资金与个人信息的往深一档走，其余不必过度投入；覆盖形态按层级与主域结构定，星号形态覆盖一层、跨主域要另做安排；部署时把证书链、名字匹配、算法与协议下限这几处守住，再用真机复测。