摘要：CA 账户应当是统一入口，但它本身不是证书管理制度。避免重复购买的关键，是让每一次申请都能说明服务什么业务、由谁负责，以及现有证书是否已能覆盖需求。
企业的 SSL 证书管理失控，往往不是因为没人会申请，而是因为每个团队都能自己申请。官网团队需要新域名，应用团队要给API 上 HTTPS，云团队在负载均衡上补一张证书，外包团队为了赶上线又单独下单。几个月后回头看，同一个业务可能有两三张用途相近的证书：有的已部署，有的只完成申请，有的快到期却找不到负责人。
一、先把谁能申请拆成不同责任
最容易出问题的做法，是把 CA 账户密码发给多个团队，谁有需求谁下单。这样虽然快，但会失去证书资产的判断和留痕。更合理的做法不是增加审批层级，而是把提出需求、决定是否购买和完成部署分开。
| 角色 | 主要责任 | 不应承担的责任 |
| 业务负责人 | 确认域名归属、业务用途与上线时间 | 自行判断证书是否需要重新购买 |
| 证书管理员 | 查询现有库存、确定申请或续期方式、统一操作 CA 账户 | 替业务决定是否上线 |
| 部署负责人 | 生成 CSR、保管私钥、完成部署与验证 | 自行采购同类证书 |
| 采购或财务 | 合同、付款、预算和订单归档 | 直接管理证书生命周期 |
二、申请前先查，不要先买
每一张新证书申请，都建议经过一次预检查。先确认域名是否已被现有证书覆盖、现有证书是否仍在有效期内、新业务是否可以使用同一张SAN 或通配符证书，以及是否因私钥隔离、业务隔离或主体不同而必须单独签发。
例如，api.example.com 要上线时，不能只看账户里有没有证书。还要确认现有证书是否覆盖该域名、是否已经部署在其他环境、私钥是否允许复用，以及业务是否要求独立吊销和审计。这样既能避免已有证书可用却重复购买，也能避免为了节省成本而错误复用。
三、一张证书至少要有这些字段
· 业务系统名称、域名及所属环境，例如生产、预发和测试。
· 证书类型、覆盖范围、CA 订单号、签发日期和到期日。
· 业务负责人、部署负责人，以及证书实际部署的位置。
· 续期决策日期、续期责任人、是否允许复用和是否需要独立私钥。
· 停用或撤销的原因，以及对应的业务确认记录。
其中“业务负责人”和“部署位置”尤其重要。没有这两个字段，即使知道证书即将到期，也很难判断该联系谁、是否仍有业务在使用。
四、统一账户，不等于共享密码
多个团队共用一个 CA 账户时，应尽量避免共享主账号密码、私钥文件或长期有效的操作凭据。需求可以由各团队提出，但签发和续期操作应集中管理，并保留申请人与部署责任人的记录。对支持独立用户、操作日志或权限分离的平台，可按岗位配置访问；人员离职、项目下线或外包结束时，应同步完成责任交接。
五、从看见证书开始建立管理闭环
当企业管理的证书逐渐增多时，仅靠 Excel 很容易出现版本不同步、更新滞后和责任字段缺失的问题。
GlobalSign 的 TLS Connect 可用于集中查看证书资产、监控到期状态和管理续期，适合希望先建立统一可视化入口的中小团队。但平台能发现和提示证书，不会自动知道哪项业务该由谁负责；业务、域名与负责人之间的映射，仍需要企业自己维护。
真正有效的管理方式是：申请前查库存，签发后登记部署关系，到期前由明确责任人确认续期，下线时再决定撤销或保留。
六、常见问题
多个团队共用一个 CA 账户，是否每个人都需要登录？
不需要。需求可以由各团队提出，但签发和续期操作应集中管理，并保留申请与部署责任记录。
发现一张没人认领的证书，能不能立即撤销？
不能。先确认它是否仍被 CDN、负载均衡、旧服务器或第三方服务使用。撤销前应完成业务影响确认。
证书数量不多，还需要建立管理流程吗？
需要。20 张证书时建立责任字段和申请前核验的成本最低，等证书分散到多个团队和云平台后再补，往往更困难。