企业里那些“没人认领”的SSL证书从哪里来?一次证书资产盘点的排查路径

举报
yd_218044062 发表于 2026/09/23 18:44:44 2026/09/23
【摘要】 一次证书盘点最让人头疼的,往往不是证书数量多,而是扫描结果里出现了这样一批对象:域名还在解析,端口仍然对外提供TLS服务,证书也没有过期,但没有团队承认自己在维护。采购记录查不到,CMDB里没有对应关系,原项目负责人可能已经离职。它们通常被称为“影子证书”。遇到这种情况,不能只把扫描结果导出成表格就算完成盘点。真正有效的盘点,需要回答三个问题:证书部署在哪里,当前由谁负责,它还应不应该继续存...

微信图片_20260923164540_991_4.png

一次证书盘点最让人头疼的,往往不是证书数量多,而是扫描结果里出现了这样一批对象:域名还在解析,端口仍然对外提供TLS服务,证书也没有过期,但没有团队承认自己在维护。采购记录查不到,CMDB里没有对应关系,原项目负责人可能已经离职。它们通常被称为“影子证书”。

遇到这种情况,不能只把扫描结果导出成表格就算完成盘点。真正有效的盘点,需要回答三个问题:证书部署在哪里,当前由谁负责,它还应不应该继续存在。下面给出一条可落地的排查路径。

没人认领的证书通常从哪里来

证书没有“凭空出现”。它只是脱离了原来的管理关系。常见来源主要集中在以下几类。

• 业务部门绕过统一采购,自行向其他CA或云平台申请证书。证书能正常使用,但没有进入公司的集中台账。

• 临时项目、测试环境或活动页面结束后,服务器和域名没有及时回收,证书继续留在公网入口。

• 并购、组织调整或系统移交时,只移交了服务器和域名,没有同步移交证书、私钥位置及续期责任。

• CDN、负载均衡、API网关和WAF等托管入口保存了证书副本,源站台账却只记录了Web服务器上的证书。

• 自动化脚本或云服务曾经自动签发证书,后来任务停用,但已经部署的证书仍在提供服务。

• 同一域名存在IPv4、IPv6、不同地域节点或多个SNI配置,管理员只检查了其中一个入口。

因此,证书盘点不能只从“买过哪些证书”出发。采购记录只能看到已知资产,无法证明网络里没有其他证书。

第一步 先定义扫描范围

很多盘点失败,是因为一开始就把范围等同于公网443端口。实际上,TLS可能存在于内网管理端口、邮件系统、API网关、数据库代理、容器入口、VPN设备和测试环境。盘点前应先把范围拆成几张清单:公网域名与IP、内网网段、云账号与区域、CDN和负载均衡实例、容器集群、网络及安全设备。

扫描时还要注意SNI。多个域名可能共用一个IP,如果只按IP建立连接,服务器返回的可能是默认证书,其他域名对应的证书会被漏掉。非标准TLS端口也应结合资产清单和端口扫描结果单独确认。

第二步 用多个来源交叉建立候选清单

单一数据源很难得到完整答案。比较稳妥的方法是把网络扫描结果与内部系统记录并排比对。

信息来源

能发现什么

容易遗漏什么

公网及内网扫描

真实在线的TLS端点、证书指纹、有效期和SAN

未开放访问的设备、需要特定SNI或客户端认证的端点

DNS与域名管理

仍在使用的域名、CNAME链路和可能的托管平台

没有DNS记录的内网服务和直接使用IP的系统

CMDB及云资产

服务器、负载均衡、网关、集群和所属项目

未登记资产、临时资源及已漂移的配置

采购与CA记录

已购买证书、申请部门、订单和签发来源

其他CA、自签名证书及云平台自动签发证书

配置仓库与密钥系统

证书文件引用、部署脚本、Secret及变更历史

控制台手工上传、设备本地存储的证书


清单合并时不要只用域名去重。相同域名可能同时存在多张证书,也可能在多个节点部署不同版本。更可靠的识别字段包括证书指纹、序列号、颁发者、SAN、有效期和实际探测端点。

第三步 从技术线索反推责任人

对“无人认领”的记录,可以按由近到远的顺序找线索。先看证书实际部署在哪个资源上,再查资源归属,而不是先在群里询问谁认识这个域名。

• 从IP、负载均衡器、CDN域名或网关实例查云账号、资源标签、项目名称和费用归属。

• 从DNS变更记录、证书申请邮件、工单和代码仓库提交历史查最初的创建人。

• 从Web页面、接口返回、证书SAN和组织字段判断对应的业务系统。

• 从访问日志和流量监控确认它是否仍有真实请求,避免把仍在使用的低流量接口误判为废弃资产。

• 如果原团队已经撤销,应由当前系统承接部门或基础设施团队临时接管,而不是继续保留“未知”状态。

第四步 不要急着删除 先给证书分状态

无人认领不等于可以立即下线。证书可能服务于不显眼但关键的系统间调用。建议至少分为四类:已确认在用、待确认、计划下线和异常高风险。

状态

判断依据

下一步

已确认在用

有明确系统、负责人和流量

补齐台账,纳入续期及告警

待确认

端点在线但责任关系不清

保留服务,设置确认期限并继续追踪

计划下线

业务确认停用且依赖已解除

先移除DNS或入口配置,观察后再回收证书

异常高风险

已过期、弱算法、私钥暴露或用途不明

立即升级处理,必要时更换或吊销


下线动作应保留回滚窗口。对于外部接口、移动端旧版本或合作伙伴系统,还要确认是否存在无法从日常监控中直接看到的调用。

第五步 把一次盘点变成持续管理

如果盘点结束后仍然依赖一张静态Excel,几个月后同样的问题会再次出现。最低限度的证书台账应记录:证书指纹或序列号、域名与SAN、签发CA、有效期、部署位置、业务系统、责任团队、续期方式、变更时间和当前状态。

更重要的是让台账能够持续更新。网络扫描负责发现“实际存在什么”,采购及CA记录负责说明“计划管理什么”,CMDB负责说明“资源属于谁”。三类信息需要定期比对,新增证书、端点变化和责任人变化都应进入变更流程。

GlobalSign Atlas Discovery提供证书发现和清单能力,可搜索公共及专用网络中的SSL/TLS证书,并将不同CA颁发的证书纳入同一视图,同时检查有效期、密钥长度和算法等信息。对于已经存在多CA、多云或历史遗留环境的企业,这类能力适合用来补充人工台账无法持续发现变化的问题。

盘点完成的标准不是得到一张表

一张证书只有同时对应到端点、业务和责任人,才算真正纳入管理。盘点的最终结果不应只是“发现了多少张证书”,而应是每张证书都有明确状态:继续使用并纳管、等待确认、安排替换,或者按流程下线。

从网络事实出发,再用组织和流程信息补齐归属,企业才能找到那些长期游离在管理边界之外的证书,并避免它们在某一天以过期、弱算法或未知私钥的形式突然变成事故。

参考资料

• GlobalSign Atlas Discovery和证书管理:https://www.globalsign.cn/atlas-discovery-certificate-management

• Atlas发现和证书管理产品资料:https://www.globalsign.cn/resources/datasheets/Atlas%E5%8F%91%E7%8E%B0%E5%92%8C%E8%AF%81%E4%B9%A6%E7%AE%A1%E7%90%86.pdf

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0)

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。