<!-- title: 一枚过期证书，瘫了11国网络 -->

## 概述

2018年12月6日，一张嵌在爱立信SGSN-MME软件里的证书悄然到期：当天日本软银全国4G业务中断4小时25分，英国O2数据网瘫痪大半天，全球11个国家的运营商在同一时刻中招。没有任何割接、没有配置变更、没有升级——一次“无变更故障”。本文以爱立信官方声明与软银官方说明为事实底座（经ZDNet、Light Reading等报道核实），复盘这起事故，并给出一套核心网证书运维的可落地体系：怎么建账、怎么监控、怎么灰度续期、怎么演练。

## 目录

- 一、同一个下午，11个国家断网
- 二、根因：藏在软件包里的一张证书
- 三、证书为什么总是隐形资产
- 四、把证书当生产资源管：五个动作
- 五、5G时代，这道题只会更难
- 六、写在最后：运维人的十条自检

## 一、同一个下午，11个国家断网

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博瑞·埃克霍姆公开道歉：「引发问题的故障软件正在被退役，我们不仅向客户道歉，也向客户的客户道歉。」

```mermaid
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的报道](https://www.zdnet.com/article/ericsson-expired-certificate-caused-o2-and-softbank-outages/)）：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最经典的隐形杀手，特征高度一致：无变更、同时刻、多节点、一起死。

```mermaid
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
```

## 五、5G时代，这道题只会更难

如果说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握手失败，注册、会话类信令成片失败——故障形态更隐蔽，现象散落在各个业务里，定位路径更绕。级别只升不降。

## 六、写在最后：运维人的十条自检

1. 你能立刻说出全网还有多少张证书、最近一张什么时候到期吗？
2. 网管告警清单里，有没有「证书到期」这一类？
3. 每一个在网软件版本的内嵌证书到期日，有没有人登记？
4. 厂商的软件发布说明里，有没有证书信息字段？合同里有没有对应SLA？
5. 下一次换证的分批方案和回退预案，现在放在哪？
6. 灾备节点的证书和生产节点是同一批吗？到期日一致吗？
7. 测试环境最近一次证书过期演练是什么时候？
8. 值班手册里，「无变更、同时刻、多节点故障」的第一排查动作是什么？
9. SEPP、SBC这些对外边界网元的证书，和运营商侧还是厂商侧在管？
10. 如果明晚有一张证书过期，谁会在几点几分、通过什么渠道知道？

2018年12月6日那个下午没有坏人：厂商不该让证书随软件悄悄过期，运营商不该对软件内嵌证书一无所知——但事故恰恰发生在所有人都「没做错操作」的地方。可用性从来不只取决于你做了什么变更，还取决于那些9个月前就已注定、却没有任何人登记过的到期日。把证书当生产资源管起来，是这个案例教给每一代核心网运维人的必修课。

## 参考来源

1. [Ericsson: Expired certificate caused O2 and SoftBank outages — ZDNet](https://www.zdnet.com/article/ericsson-expired-certificate-caused-o2-and-softbank-outages/) — 爱立信官方声明与软银官方说明的完整引述，含故障时间线与恢复手段
2. [Ericsson says expired certificate for some nodes caused network issues — Light Reading](https://www.lightreading.com/mobile-core/ericsson-says-expired-certificate-for-some-nodes-caused-network-issues) — 行业权威媒体对爱立信声明的核实报道
3. [Millions of smartphones were taken offline by an expired certificate — The Verge](https://www.theverge.com/2018/12/7/18130323/ericsson-software-certificate-o2-softbank-uk-japan-smartphone-4g-network-outage) — 事件的完整公众叙述与影响面
4. [Expired Ericsson cert causes UK and Japan mega outages — ITNews](https://www.itnews.com.au/news/expired-ericsson-cert-causes-uk-and-japan-mega-outages-516617) — 根因结论与厂商回应
5. [Ericsson's Expired Software Certificate Issue Causes Massive Outages in UK's O2 and Japan's SoftBank — Security Boulevard](https://securityboulevard.com/2018/12/ericssons-expired-software-certificate-issue-causes-massive-outages-in-uks-o2-and-japans-softbank-network-services/) — 11国影响范围与软件版本细节梳理

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
