# 一枚过期证书，撂倒两张国网 **概述**：2018年12月6日，英国O2与日本软银两张国家级移动网络在同一天大面积瘫痪，波及用户以千万计。事后爱立信确认：根因是其软件版本中**一枚过期的证书**，导致受影响的核心网设备停机。本文复盘这一事件的完整时间线与根因链条，并从一线运维视角展开：电信网里的证书有哪几类、过期会炸掉什么、证书台账怎么建、到期告警怎么分级、验收和应急SOP怎么写——把一次惨痛事故，转化为一份可以直接落地的证书运维清单。 ## 目录 - 一、事件回顾：两张国家级网络的至暗一天 - 二、根因分析：一枚证书如何撂倒一张网 - 三、影响面评估：不只是打不了电话 - 四、运维实战：证书台账怎么建、怎么盯 - 五、5G时代，这个风险正在被放大 - 六、写在最后：把事故变成清单 - 参考来源 --- ## 一、事件回顾：两张国家级网络的至暗一天 2018年12月6日，星期四。英国当地时间凌晨5点30分前后，O2 UK的用户开始在社交媒体上抱怨手机上不了网。起初大家以为是局部故障，但很快发现：这是**全国范围**的3G/4G数据业务中断，语音和短信也因网络拥塞出现失败。据维基百科援引BBC的报道，这次故障导致O2及其虚拟运营商（MVNO）用户最多达**3200万**，数据业务中断持续了**最长约24小时**。 几乎在同一时间，地球另一端的日本软银（SoftBank）也出现了全国性的数据业务故障。ZDNet的报道标题直接把两件事绑在了一起：《爱立信：过期证书导致O2与软银断网》。两家运营商相隔近万公里、网络彼此独立，却在同一天被同一个厂商的同一个问题击中——这在移动网络故障史上极为罕见。 先把关键时间线捋一遍： | 时间（当地时间） | 事件 | 来源 | | --- | --- | --- | | 2018-12-06 凌晨约05:30 | O2用户开始报告数据业务中断，故障迅速演变为全国性 | 据外媒报道 | | 12-06 上午 | O2确认3G/4G数据业务全国中断；语音、短信因拥塞劣化；giffgaff、Tesco Mobile等MVNO同步受影响 | 维基百科援引BBC | | 12-06 白天 | 使用O2物联卡的伦敦公交到站显示屏等服务受波及；初步定位与爱立信设备软件有关 | 据BBC等媒体报道 | | 12-06 全天 | 日本软银全国范围数据业务故障，受影响规模外媒报道约3000万用户量级；当晚陆续恢复 | ZDNet、The Verge | | 12-07 | 爱立信发布初步根因声明：软件版本中的证书过期；O2数据业务基本恢复 | The Register、TechMonitor | | 12-07 之后 | 英国监管机构Ofcom介入，要求O2作出解释；爱立信承诺完成完整根因分析 | 据外媒报道 | 一个值得玩味的细节：这不是O2第一次大面积断网。2012年7月，O2曾因交换子系统故障经历约24小时的业务中断，波及约800万用户，事后拿出账单九折的赔偿方案。而2018年这次，O2并未宣布类似的大规模赔偿——彼时英国Ofcom的自动赔偿机制主要覆盖固话与宽带业务，移动业务并不在其列。对用户来说，这次只能收下道歉。 ## 二、根因分析：一枚证书如何撂倒一张网 12月7日，爱立信给出了官方初步结论，TechMonitor与itnews都原文引用了这段声明： > "An initial root cause analysis indicates that the main issue was an expired certificate in the software versions installed with these customers." > （初步根因分析表明，主要问题是随这些客户部署的软件版本中，一枚证书过期了。） The Register在首日报道中进一步指出，过期证书位于爱立信**管理软件的一个版本**之中；随后多家媒体的后续分析把受影响设备指向**分组域核心节点（SGSN/MME）**——爱立信官方通报并未具体点名网元型号，这一点读者需要注意区分：哪些是官方口径，哪些是媒体推断。 很多刚入行的同行会困惑：证书过期，顶多是告警栏里多一条黄色告警，怎么就能把一张国网打瘫？这里把机制掰开讲清楚。 现代电信设备里的证书，不是我们日常理解的“HTTPS网页证书”那么简单。厂商交付的核心网软件里，会内置用于**软件完整性校验和授权控制**的证书：节点启动时、以及运行过程中周期性地用这些证书验证软件模块的签名与授权状态。这套机制的本意是安全——防止未授权软件被加载、防止软件被篡改。但它的另一面是：**一旦校验失败，节点的标准动作不是“降级运行”，而是“拒绝工作”**。这是安全设计里的fail-stop哲学：宁可停机，不跑来路不明的代码。 于是完整的因果链条是这样的： ```mermaid flowchart TD A["软件版本内置证书到期"] --> B["节点完整性校验失败"] B --> C["核心网分组域节点停机自保护"] C --> D["MME池容量骤降"] D --> E["附着与承载建立失败"] E --> F["3G与4G数据业务全国中断"] C --> G["物联卡连接失联"] G --> H["公交到站屏等下游服务波及"] ``` 这个链条里最要命的是第三步：节点停机自保护。据当时外媒报道，**受影响节点重启后可以恢复业务**——这也解释了为什么恢复过程持续了大半天：工程师需要对全网成百上千个节点分批执行重启操作，还要避开业务高峰、控制信令冲击，一 node 一 node 地救回来。ZDNet的报道证实，软银在日本侧率先完成恢复，O2则一直拖到12月7日才宣布数据业务全部恢复。 顺着这根链条，还能解释两个容易被追问的问题： **为什么语音还能通？** 2G/3G语音走电路域（CS），4G语音走VoLTE回落，数据中断后终端会尝试回落到CS域，所以语音表现为“拥塞、难打通”，而不是“彻底归零”。3200万用户同时挤在语音和短信通道上，拥塞本身就足以让接通率雪崩。 **为什么物联网最先崩溃？** 公交到站屏、POS机这类物联卡终端没有语音回落能力，数据一断就是彻底失联，而且运维人员很难第一时间把“伦敦的公交屏不亮了”和“移动核心网故障”关联起来——**物联网对核心网故障的敏感度远高于手机**，这是这次事件里最容易被忽视的运维知识点。 ## 三、影响面评估：不只是打不了电话 把影响面摊开看，这次事故的评估维度远超“多少用户打不了电话”： **用户侧**：O2自身加MVNO用户最高3200万（维基百科援引BBC口径），占英国移动市场的四分之一以上；软银侧外媒报道约3000万用户量级。The Verge还确认，爱立信承认其他国家的运营商也同时受到了影响——完整名单至今没有完全公开。 **垂直行业侧**：伦敦公交到站显示屏等物联卡业务中断，把移动网络故障的传导边界从“人”扩展到了“城市基础设施”。这是近年来“电信网故障外溢”的经典样本：**你的网挂了，别人的业务跟着挂**。 **财务与商誉侧**：据外媒估算，故障导致O2当日直接业务损失与后续处理成本不菲（有第三方博客给出约1亿英镑量级的说法，未经官方证实，仅作参考）；更深层的是信任损失——设备商的单点软件缺陷，一次事故就暴露在三个大洲的用户面前。 **监管侧**：Ofcom要求O2作出正式解释。事后看，这次事件推动各运营商开始重新审视厂商软件供应链里的“隐形资产”——证书，就是其中最典型的一类。 这里要补一句公道话：爱立信的反应速度不算慢，故障次日就给出初步根因并公开承认问题，CEO鲍毅康（Börje Ekholm）公开致歉。对比业界某些“挤牙膏式”的故障通报，这个危机应对是及格的。但反过来说，**能让一枚过期证书 simultaneously 击穿多个国家客户的交付流程，说明设备商内部的软件生命周期管理存在系统性缺口**——这一点后来爱立信在完整根因报告中也不讳言。 ## 四、运维实战：证书台账怎么建、怎么盯 事故复盘完了，落点还是在运维。以我这些年带核心网维优团队的经验，证书管理在大多数运营商内部是“三不管”地带：网安认为这是网维的事，网维认为这是设备商的事，设备商认为你已经签了维保合同。三方互相指望的结果，就是2018年12月6日这样的“定时炸弹”没人拆。 下面这套做法，是从多起真实故障里淬出来的，可以直接照抄： ### 第一步：摸清家底——全网证书盘点 先把电信网里的证书分清楚类。不同证书过期后的爆炸当量完全不同： | 证书类型 | 典型部署位置 | 过期后果 | 监控手段 | | --- | --- | --- | --- | | 软件内置/授权证书 | 厂商软件包内，核心网节点 | **节点停机自保护**，业务中断 | 厂商交付文档核对+网管告警 | | IPsec隧道证书 | 网元与安全网关（SEG）之间 | 隧道协商失败，信令/业务中断 | 网关侧批量导出+探针 | | SBA接口TLS证书 | 5GC各NF之间 | 服务注册、订阅、调用失败 | 自动化巡检脚本 | | 网管/北向接口证书 | OMC与网元、OSS与OMC之间 | 管理面失联，**故障变盲区** | 探针+到期台账 | | 运营方自签发证书 | 运营商自己的PKI体系 | 可控，走正常续期 | CA侧统一管理 | 第一类就是这次事件的主角——它最大的坑在于**它不在你自己的CA体系里，你既看不到它的有效期，也无法给它续期**，唯一的处理路径是让厂商出新版本。所以盘点的重点是：向厂商索取每在网软件版本的内置证书有效期清单，写进维保合同或验收文档。 第二类以后的证书，运营自己是可控的。以最常用的开源工具为例，一条命令就能拿到任意TLS服务端证书的有效期： ```bash openssl s_client -connect mme01:8443 2>/dev/null | \ openssl x509 -noout -subject -enddate ``` 把这个命令做成定时任务，输出喂给CMDB，一个粗粒度的证书台账当天就能建起来。 ### 第二步：分级告警——让证书到期“有预告” 证书过期的最恶劣之处在于：**它是一个100%可预测的故障**。过期日期是数学问题，不是概率问题。所以告警策略必须前置： - **T-90天**：提示级，进工单，责任人确认续期计划； - **T-60天**：预警级，升级到科室负责人，纳入变更窗口排期； - **T-30天**：告警级，纳入本周期割接清单，开始走审批； - **T-7天**：紧急级，值班经理督办，未完成续期的启动应急预案。 监控落地不需要什么高精尖：Zabbix的TLS监控项、Prometheus的blackbox exporter（`probe_ssl_earliest_cert_expiry`指标）都能对网管侧证书做在线探测；网元内部证书则依赖厂商网管的告警转发——这一条务必在维保协议里写死“证书到期告警必须可上报北向”。 ### 第三步：验收防线——别让厂商把炸弹打包进来 这次事件最刺痛的一点是：炸弹是**随软件包一起交付**的。所以软件验收清单里必须增加证书检查项：新版本内置证书的有效期、是否可替换、到期后行为是“降级”还是“停机”。最后一问尤其关键——同样是证书过期，**节点选择拒停还是降级，直接决定了故障的爆炸当量**。把这个问题写进招标技术规范，让设备商在商务承诺里回答，比事后追责有用得多。 ### 第四步：应急SOP——假设炸弹已经爆了 再严密的防线也要准备兜底方案。证书过期类故障的应急SOP至少要写清楚四件事：受影响节点的**重启恢复顺序**（按业务权重排序，先救高容量MME/AMF）；**分批节奏**（避免重启风暴引发二次信令拥塞）；**业务影响矩阵**（哪些物联卡用户会失联，提前通知重点政企客户）；以及**对厂商的升级路径**（谁在几点前必须给出修复版本）。把这套流程做成年度演练科目，演练一次，比开十次会都管用。 ```mermaid flowchart LR T["台账纳管"] --> M["在线探针监测"] M --> W["分级到期告警"] W --> P["续期与变更"] P --> V["厂商交付验收"] V --> T W --> S["应急SOP与演练"] S --> T ``` 这个闭环里，**演练分支**最常被砍掉——预算紧、人手少，演练总被当成“非生产活动”。但2018年那次事故里，O2工程师面对的是一张没人演练过“全网核心节点分批重启”的网。没演练过的预案，等于没有预案。 ## 五、5G时代，这个风险正在被放大 如果说4G时代证书还是“藏在深闺”的隐性资产，5G就是把它推到了台前。按3GPP的安全架构（TS 33.501《5G系统安全架构与流程》）和网络域安全框架（TS 33.210、TS 33.310），5G核心网的SBA服务化接口全面TLS化，网元之间的每一次服务调用背后都是证书在背书。粗算一笔账：一张省级5GC里，NF实例数量是4G时代EPC网元的五到十倍，证书数量再乘上去，**证书从“个位数的手工管理”变成了“成百上千的资产管理”**。 3GPP定义了完整的NDS/AF（网络域安全/认证框架）来支撑这一切，标准允许多种实现与部署方式，具体行为以各厂家官方文档为准——但运维侧的责任边界不会变：**证书台账是你的，到期监控是你的，应急SOP也是你的**。设备商能给你的是交付清单和告警能力，兜底的永远是自己人。 还有一个正在逼近的变化值得留意：Web领域已经在推动短周期证书（数十天有效期）以提升安全性，公网TLS生态的证书有效期趋势只会越来越短。电信专用PKI短期内未必跟进，但方向是明确的——**证书生命周期管理会从“偶发运维事项”变成“常态化运维工作”**，早一天建好自动化闭环，就少一次凌晨五点半的紧急集合。 ## 六、写在最后：把事故变成清单 回看这次事故，最讽刺的细节是：击穿3200万用户的，不是什么高明的APT攻击，不是精密的网络战，只是一串X.509证书里“Not After”字段的一个时间戳。安全机制越严格，安全资产本身的管理就越致命——**你信任链的锚，就是你的阿喀琉斯之踵**。 给同行们留一份三行清单，贴在值班台上： 1. **今天就去查**：全网在网软件版本的内置证书有效期，找厂商要清单，要不到就升级到合同层面； 2. **本月就建好**：证书台账+四级到期告警，T-90起步，T-7督办； 3. **本季度就演练**：核心节点分批重启预案，跑一遍真流量，把坑留在演练里。 网络运维这行，所有的重大事故在事后看都是“早就写好的剧本”。区别只在于：你是剧本的读者，还是主演。 ## 参考来源 1. [Wikipedia: O2 (United Kingdom)](https://en.wikipedia.org/wiki/O2_(United_Kingdom)) — 2018年12月6日故障的基本事实（3200万用户、最长24小时、语音短信拥塞）及2012年断网对比，援引BBC报道 2. [The Register: Why millions of Brits' mobile phones were knackered on Thursday](https://www.theregister.com/on-prem/2018/12/06/why-millions-of-brits-mobile-phones-were-knackered-on-thursday-an-expired-ericsson-software-certificate/339700) — 首日报道，确认根因为爱立信管理软件版本中的过期证书 3. [ZDNet: Ericsson: Expired certificate caused O2 and SoftBank outages](https://www.zdnet.com/article/ericsson-expired-certificate-caused-o2-and-softbank-outages/) — 爱立信官方结论与软银恢复情况 4. [TechMonitor: Ericsson: Expired Software Certificate Caused Those Data Outages](https://www.techmonitor.ai/hardware/o2-down-uk) — 爱立信初步根因分析声明原文引用 5. [The Verge: Millions of smartphones were taken offline by an expired certificate](https://www.theverge.com/2018/12/7/18130323/ericsson-software-certificate-o2-softbank-uk-japan-smartphone-4g-network-outage) — 多国运营商同时受影响的确认 --- > 本文由「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 等场景全覆盖。