2018年12月6日，一张嵌在爱立信SGSN-MME软件里的证书悄然到期：当天日本软银全国4G业务中断4小时25分，英国O2数据网瘫痪大半天，全球11个国家的运营商在同一时刻中招。没有任何割接、没有配置变更、没有升级——一次“无变更故障”。本文以爱立信官方声明与软银官方说明为事实底座（经ZDNet、Light Reading等报道核实），复盘这起事故，并给出一套核心网证书运维的可落地体系：怎么建账、怎么监控、怎么灰度续期、怎么演练。
2018年12月6日，星期四。这一天成了全球核心网运维史上被引用最多的案例之一。
先看日本。东京时间13点39分，软银网络中心的监控屏上，东京中心和大阪中心的所有爱立信分组交换机同时报出软件故障——不是几台，是全部。这些设备承载着软银全国4G LTE分组域，SoftBank和Y!mobile用户的手机上网、语音，乃至固定电话业务「Ouchi-No-Denwa」和SoftBank Air，成片掉线，范围是全国。直到18点04分，业务才全部恢复，全程4小时25分。
再看英国。同一天，O2的3G/4G数据业务大面积中断，殃及搭载其网络的Sky Mobile、Tesco Mobile等虚拟运营商用户。当晚21点30分（GMT）前后3G数据业务率先恢复，4G则由O2与爱立信团队通宵抢修，次日清晨才恢复全网。
事后软银在官方说明中交代了三个关键事实：其一，出问题的软件已经上线运行了9个月，期间风平浪静；其二，同一软件的故障在11个国家的运营商网络上同时发生；其三，恢复手段是把全部分组交换机回退到旧版本软件。
爱立信当天的声明则点破了根因：「初步根因分析表明，主要问题是这些客户所装软件版本中的证书过期。」涉及SGSN-MME（分组域核心网元）的两个特定软件版本。CEO博瑞·埃克霍姆公开道歉：「引发问题的故障软件正在被退役，我们不仅向客户道歉，也向客户的客户道歉。」
timeline
title 2018年12月6日 一张证书引发的跨洲瘫网
section 日本软银
13时39分 JST : 网络中心发现东京与大阪中心全部爱立信分组交换机软件故障
当天下午 : 全国4G LTE、固话与SoftBank Air业务中断
18时04分 : 全部设备回退旧版本软件 业务恢复 共4小时25分
section 英国O2
当天 : 3G与4G数据业务大面积中断 殃及Sky Mobile等MVNO
21时30分 GMT : 3G数据业务恢复
次日清晨 : 通宵抢修后4G恢复全网正常
section 爱立信
当天 : 声明确认根因为SGSN-MME两个软件版本中证书过期
当天 : 确认11国运营商同时受影响 故障软件退役 CEO公开道歉
把公开信息摆在一起，这起事故的骨架非常清晰。事实层面，来源是爱立信与软银的官方表述（可交叉验证于ZDNet的报道）：SGSN-MME、两个特定软件版本、证书过期、11国同时、软件已运行9个月、恢复靠回退旧版本。
「已运行9个月」这个细节尤其扎心。它说明这张证书是随软件版本一起打包签发的——生命周期绑定的是软件版本，而不是运营商自建CA的签发策略。软件上线那天起，它的到期日就已经写死在9个月后的某个UTC时刻。到了那一刻，全网装着同版本软件的设备状态一起翻转。
机制层面，为什么一张证书过期会直接放倒分组域，而不是让业务优雅降级？这里要先说明：爱立信官方只确认了「证书过期是主要问题」，节点内部的具体失效路径没有公开细节。以下是基于通用PKI机制的工程推断。4G分组域的安全架构里，网元之间、网元与安全网关之间的通信依赖IPsec安全隧道，身份验证靠机器证书，对应3GPP TS 33.210定义的NDS/IP框架。证书一旦过期，理论上正确的姿势是「拒绝新建连接、尽力维持存量业务」，但现实行为完全取决于软件怎么处理校验失败——如果实现把证书失效当成致命错误，节点进程可能反复重启、起不来，进入崩溃循环。更致命的是同质性：全网同版本设备用的是同一张证书，同一时刻一起翻车，而「备用的那台」和「生产的那台」握着的是同一张过期证书，容灾形同虚设。
还有一个细节值得咀嚼：恢复手段是回退旧版本软件。这意味着旧版本里的证书还没过期（或者校验逻辑不同）。一张9个月前签发的证书，决定了9个月后的网络可用性——而它不在任何一张运维台账上。
干了这么多年核心网，我的经验是：证书出事从来不是技术难题，而是管理盲区。核心网的证书大致分三类，每一类都有各自的死法。
| 使用场景 | 相关标准与协议 | 过期后果 | 纳管难点 |
|---|---|---|---|
| 回传与网间IPsec | IPsec/IKEv2、3GPP TS 33.210 | 安全隧道重建失败、基站脱管 | 证书分散在安全网关与网元侧 |
| 5GC服务化接口 | HTTP/2 over TLS、3GPP TS 33.501 | NF间互访失败、业务倒换 | 数量爆炸、随NF生命周期滚动 |
| 漫游边界SEPP | N32接口、3GPP TS 33.501 | 国际漫游业务中断 | 依赖对端运营商协同换证 |
| 网管与北向接口 | TLS、SSH | 网元失管、监控盲区 | 常被当IT资产漏管 |
| 软件内嵌证书 | 随版本打包签发 | 触发软件故障、节点宕机 | 运营商台账里根本没有它 |
前三行的证书，运营商理论上可以纳管，现实中却普遍靠一张Excel台账加人工续期——Excel第一行永远是最新的，第二行开始就是历史。而最后一行，也就是2018年12月6日的主角，是彻底的盲区：软件包里嵌了证书、什么时候到期、到期会发生什么，运营商一概不知，因为厂商的软件发布说明里压根没有「内嵌证书到期日」这个字段。
归纳起来，证书管理的四个痛点：第一，证书长在网元肚子里，北向网管的告警清单里通常没有「证书到期」这一项；第二，续期等于割接，换证书要重启进程甚至重启节点，没有人愿意为「还没出事的东西」申请割接窗口；第三，台账靠人肉，网元数百、证书数千，靠手感维护；第四，厂商交付不透明，采购合同里没有证书相关的SLA条款。四个痛点叠在一起，就是12月6日那个下午。
这起事故最值得传承的不是「爱立信翻车了」，而是运营商侧能做什么。我把它整理成五个动作，按优先级排序。
第一，普查建账，三路并进。对TLS类证书，用探针脚本对全网服务端口做握手采集，直接抓有效期；对IPsec类，逐台核查安全网关的证书配置与SA状态；同时向厂家索要全网证书与密钥清单，并倒查采购、集成合同里的证书交付物。三路结果汇总成台账，字段至少包括：证书用途、所属网元、签发方、生效与到期时间、续期责任人、续期是否需要割接。
第二，到期监控进网管。所有证书的到期时间采集进监控系统，做90天、30天、7天三级预警，告警进工单系统而不是沉在邮件组里。没有商用证书管理平台的局站，先用探针脚本加北向告警顶着，两周内就能把全网TLS类证书纳管——这件事的边际成本极低，收益却是规避一次全国性故障。
第三，灰度续期。换证顺序按「灾备节点、边缘节点、核心节点」排，分批进行，批与批之间留足观察窗口；严禁同一个维护窗口全网批量换证。每次换证必须有回退预案：旧证书保留、回退脚本预先验证过。证书续期要当成和割接同级的生产变更来管理，哪怕它听起来只是「换个文件」。
第四，把厂商纳进来。软件版本发布说明强制包含内嵌证书的到期日；升级评估检查单里加一项「内嵌证书到期日与本网维护计划的关系」；维保合同SLA里写明厂商的证书到期预警义务。2018年这一课的核心教训就是：运营商根本不知道软件里有证书，这条必须从合同层面堵死。
第五，演练。在测试环境做「证书过期」故障注入，验证三件事：业务是降级还是中断、告警是否及时准确、值班人员能否在30分钟内把根因定位到证书。应急SOP的第一页我建议永远写一行字：先查昨晚有没有什么东西到期了。证书、许可证、域名、防火墙策略——到期类故障是NOC最经典的隐形杀手，特征高度一致：无变更、同时刻、多节点、一起死。
flowchart TB
A[证书签发] --> B[部署入网]
B --> C[台账登记]
C --> D[到期监控]
D -->|到期前90天| E[预警工单]
D -->|到期前30天| F[制定灰度续期方案]
E --> F
F --> G[分批续期 灾备先行]
G --> H[业务验证与观察]
H --> C
D -->|发现已过期| I[应急SOP 定位与回退]
I --> C
如果说2018年的证书问题是「百级」规模的管理疏漏，5G把它变成了「万级」的工程课题。5G核心网的服务化架构（SBA）把网元间通信变成了一个巨大的TLS网格：NF之间的服务化接口基于HTTP/2 over TLS并做双向认证，3GPP TS 33.501把这套安全机制写进了标准；更关键的是漫游边界——SEPP之间的N32接口同样依赖证书建立安全通道，也就是说，连国际漫游业务的可用性，现在都系于证书续期的及时性。
做一个工程估算（非精确统计）：一个省级5GC，NF实例数十个，每个NF一到多张证书，再算上网络切片、漫游边界、管理与编排域，证书数量轻松到万级。人工台账在这个规模面前彻底失效，自动化不是加分项，是必选项。
但电信域的自动化有现实约束：核心网是私有CA加离线、准离线部署的天下，公网ACME那套自动续期不能照搬。可行的路径是把「采集、预警、工单、灰度变更」这条闭环自动化，签发环节保持人工审批。标准允许多种实现，具体方案以各厂家官方文档为准。
反过来看，这次事故发生在4G分组域，代价是「上不了网」；放到5GC，一张过期证书的效果是NF之间TLS握手失败，注册、会话类信令成片失败——故障形态更隐蔽，现象散落在各个业务里，定位路径更绕。级别只升不降。
2018年12月6日那个下午没有坏人：厂商不该让证书随软件悄悄过期，运营商不该对软件内嵌证书一无所知——但事故恰恰发生在所有人都「没做错操作」的地方。可用性从来不只取决于你做了什么变更，还取决于那些9个月前就已注定、却没有任何人登记过的到期日。把证书当生产资源管起来，是这个案例教给每一代核心网运维人的必修课。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。