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

一次证书盘点最让人头疼的,往往不是证书数量多,而是扫描结果里出现了这样一批对象:域名还在解析,端口仍然对外提供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
- 点赞
- 收藏
- 关注作者
评论(0)