我们 使用 DigiCert 高保证 EV 根 CA 进行 OTA 使用 Github 已超过一年、上周末它停止工作。 响应要求 使用 DigiCert 全局根 CA。 遗憾的是、这对已经在现场的产品没有帮助。 还有人有这个问题吗? 我还向 Github 开了一个 TT、因为我无法看到 DigiCert 高保证 EV 根 CA 为何应该停止工作。
Gary
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
我们 使用 DigiCert 高保证 EV 根 CA 进行 OTA 使用 Github 已超过一年、上周末它停止工作。 响应要求 使用 DigiCert 全局根 CA。 遗憾的是、这对已经在现场的产品没有帮助。 还有人有这个问题吗? 我还向 Github 开了一个 TT、因为我无法看到 DigiCert 高保证 EV 根 CA 为何应该停止工作。
Gary
您好、Gary、
感谢您的通知。 我们将对此进行检查、但它看起来是一个真正的问题。
现场设备的唯一解决 方案是联系 GitHub 支持、并要求他们在一段时间内恢复到以前的证书。 我们也会与他们联系。 我们有几个选项可支持多个证书。
我们将在下一个 SDK 版本中引入一个。
在"平均"中、您可以参阅以下主题中建议的修复(Dropbox 服务器存在类似问题):
https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/970443/3593954#3593954
BR、
Kobi
您好、Kobi、
今天上午,我找到了 Micheal 的一篇文章,他讲述了如何在同一个.pem 文件中存储多个根证书。 我试过这个、它运行良好。 我们实际上有3个证书用于不同的主机。 与下拉框中的帖子非常相似、GitHub 现在正在为2个证书、DigiCert 针对 API.GitHub 的全局根和针对原始文件的 DigiCert 高保证。 由于两个证书都位于一个 PEM 文件中、我能够使 OTA 再次正常工作。 GitHub 建议了一个更新窗口、我要求他们提供有关存储哪些其他证书的建议、以使 OTA 更符合未来需求。 我将汇报他们的发言。
Gary
您好、Kobi、
下面是我从 GitHub 支持处收到的最新电子邮件回复的副本、其中的回复以斜体显示、这似乎会导致 OTA 开发人员出现问题、尤其是在他们返回到一个证书之前。 您希望我如何让您参与其中? 您是否认为 TI 可能会施加一些压力来延长恢复时间、以便您可以警告您的客户、他们有时间编写代码并测试他们的解决方案?
您好、Gary、
感谢您的回复。 请在下方查找答案和备注:
如果我们只能持有有限数量的证书,那么我们如何决定哪些证书? 例如、我们可以简单地存储所有 DigiCert 证书。 他们需要多久更新一次?
我们不能保证我们将永远使用 DigiCert、尽管今天就是这样-因此、如果我们停止使用 DigiCert、您将再次拥有这种体验。 我们强烈建议不要使用 GitHub 进行无线更新、而是运行您自己的分发、您可以在其中完全控制证书。
或者,如果您有另一种机制,如使用公共/专用密钥库对生成的 blob 进行签名,并将公共密钥随设备一起发送,以便验证他们是否已对分布式二进制文件进行了签名,则可以完全禁用证书验证。
这类似于 APT for Debian/Ubuntu 如何仍然使用纯文本 http、但使用包签名作为信任模型。
为什么我能够连接到 api.git.com 的 DigiCert 全局根、但访问 raw.usercontent.com DigiCert 全局时失败、系统请求 DigiCert 高保证证书。 为什么 High Assurance 证书不能同时使用?
我们将缓慢地推出这些更改、最终都需要 DigiCert 全局根。
是否可以有一个8小时的窗口、然后在将来再次打开窗口、以覆盖无法在线进入第一个窗口的系统?
抱歉、我们将只有一个窗口用于这些更改。
我的存储库中有控制器更新文件、但我们也有一个 Irrigreen 组织。 如果我们将存储库置于 Irrigreen 组织之下、我们是否可以管理自己的证书以实现安全连接?
不能、您将无法管理自己的证书。
由于存储库文件已加密、我们是否应考虑不使用安全连接? 这也是一个选项吗?
我们不提供通过 HTTP Anywhere 的访问-我们将始终将 HTTP 301返回到 https://
另一个问题是:如果我们将 IrriGreen 组织升级为企业,这是否因为我们控制它们而解决了我们未来的证书问题?
不、这一点无关紧要如果升级到 GitHub 企业云(GHEC)-所有 GitHub.com 都是一个带有一个证书的端点。 如果您自己运行 GitHub Enterprise Server (GHES)、则可以控制您的证书、但这似乎是一个非常繁重的问题。
如果您考虑后者、则使用您自己的受控证书设置单独的分发 CDN 似乎是一种简单的解决方案。
此致、
Oluwaseun
GitHub 支持
GitHub 今天的好消息。 我们下周有一个迁移到新证书的窗口。 我们还在考虑迁移到 Amazon S3、以便控制证书。 根据开发人员支持、GitHub 没有此选项。 感谢 Kobi 支持这项工作。
GitHub (GitHub 支持) 2021年3月25日、UTC 上午8:32 您好、Kobi 和 Gary、 我们正在与我们的证书提供商讨论他们可以为我们提供哪些选项。 根据答案、我们将有以下情形之一: · 我们可以将绑定到旧根的证书作为一次性例外推出、直到该证书过期。 这意味着您将有时间将其翻转并修复更新机制。 · 如果他们无法提供帮助、我们将在几天内恢复到旧证书、以便您可以升级。 因此、无论情况如何、我们都可以确保至少在下一个工作周使用旧 CA、并且您可以更新设备。 时间窗口将为下周的周一至周四(周一08:00 UTC -周四15:00 UTC)。 无论我们最终选择了哪些选项、您都应该能够使用此窗口升级您的设备、以确保将来的升级也有效。 根据上述场景中发生的情况、窗口可能会明显更长、但这是我们现在可以保证的最小值、以便您可以更快而不是更晚地准备。 如果您对此计划有任何疑问或疑虑、请告诉我。 此致、 |
Gary