2025年9月25日 go.opentelemetry.io 事件回顾
2025年9月25日，北京时间10:35，我们收到通知，`go.opentelemetry.io` 的 SSL 证书已过期。
该端点是 OpenTelemetry 组织内大多数 Go 模块的规范 URL。因此，从该端点下载任何模块都将变得不可能。
发生了什么？
该端点目前运行在 Google App Engine 平台，其 SSL 证书由 Google 管理。这是 `opentelemetry.io` 域下唯一运行在该平台上的端点。
去年7月，我们曾被一位安全研究人员告知，OpenTelemetry 的根域名（`opentelemetry.io`）缺少 CAA DNS 记录。因此，我们添加了一个记录，并将 Let's Encrypt 指定为唯一的签发者，因为这是 根域名证书使用的权威机构。
由于 Google 的 CA 未在 CAA 记录中列为签发者，AppEngine 平台无法续订 `go.opentelemetry.io` 的证书。因此，在2025年9月25日10:08:10 UTC，当证书过期时，所有请求都返回了带过期证书的错误。这导致了构建系统和查看 `go.opentelemetry.io` 包文档时出现问题。
由于这是我们维护的唯一运行在该平台上的应用程序，只有少数在美国的团队成员有相关经验，因此在他们醒来之前，我们难以高效地处理。UTC 时间12:03，我们获得了对 Google Cloud 控制台的访问权限，UTC 时间12:14，我们确定问题是由于 CAA 记录 引起的。
UTC 时间12:16，我们部署了一个新的 CAA 记录，以便 Google 可以正确生成证书。我们假设平台会在注意到 DNS 更改后自动重新生成新的 SSL 证书。这个假设似乎是有效的，但平台刷新 CAA 记录可能需要长达一天的时间。
UTC 时间13:58，我们看到 DNS 记录已经传播，但仍未生成证书。不幸的是，参与事件的人员对该平台了解不多，我们不知道如何强制重新生成证书。
UTC 时间14:54，我们禁用了 SSL 证书上的托管安全功能，然后又重新启用了它，这强制重新生成了一个证书。几分钟后，我们开始看到请求成功。
详细时间线
- 10:08 UTC – go.opentelemetry.io 的 SSL 证书过期
- 10:35 UTC – 用户首次报告问题
- 11:31 UTC – 创建了 公开问题以跟踪此事件
- 12:03 UTC – 获得 golang-imports 项目的 Google Cloud 控制台访问权限
- 12:14 UTC – 确定 CAA 记录缺少“pki.goog”签发者
- 12:16 UTC – 部署了包含正确签发者列表的新 CAA 记录
- 13:58 UTC – 确认 CAA 记录已传播但 SSL 证书未续订
- 14:54 UTC – 禁用了 SSL 证书上的托管安全功能，然后又重新启用
- 15:16 UTC – 确认已为 go.opentelemetry.io 签发了新的 SSL 证书
经验教训
在发现此事件时，我们有多人立即介入并试图找出原因。对于一个分布在全球的开源项目来说，这是一个积极的方面。
我们缺乏对该应用程序运行平台的了解，这导致此事件持续的时间比预期的要长。但是，我们很高兴 一年多以前，我们更改了该应用程序运行的 Google 帐户，因为在此之前我们甚至无法自行修复此问题。
行动项
我们已经开始 改进我们的操作手册 以访问 AppEngine 控制台，以便我们可以更快地获得访问权限。
我们需要确保该应用程序不再是一个“雪花”（特例），以便我们可以像操作 OpenTelemetry 维护的任何其他公共网站一样来操作它。因此，我们 将着手 将该应用程序从 AppEngine 平台迁移到 Netlify，即运行 `opentelemetry.io` 网站的平台。
在用户帮助下，我们还发现了 opentelemetry.io 域下存在一些未使用的子域，它们显示了过期的证书。虽然这些对我们的用户没有影响，但我们将 着手移除它们。