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.

[参考译文] CC3120MOD:使用 DigiCert 高保证 EV 根 CA 的 OTA 证书失败

Guru**** 2391865 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/986085/cc3120mod-ota-certificate-failure-using-digicert-high-assurance-ev-root-ca

器件型号:CC3120MOD

我们 使用 DigiCert 高保证 EV 根 CA 进行 OTA 使用 Github 已超过一年、上周末它停止工作。  响应要求 使用 DigiCert 全局根 CA。  遗憾的是、这对已经在现场的产品没有帮助。  还有人有这个问题吗?  我还向 Github 开了一个 TT、因为我无法看到  DigiCert 高保证 EV 根 CA 为何应该停止工作。

Gary

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    全局根证书适用于 api.github.com、但在读取原始文件时、它要求提供高保证证书、为什么原始的高保证证书不能像以前一样适用于这两种情况?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、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

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    是的、该方法应该起作用。

    这是我们将要提出的方法之一-我们正在努力使其在我们的文档中正式。

    GitHub 建议的更新窗口有多长时间?

    您能否让我参与其中、以便我们可以向所有客户提出同样的问题?

    BR、

    Kobi

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、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 支持

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢 Gary、  

    我假设你得到的窗口是8小时、对吧?

    您能否提供有关此窗口的详细信息?

    BR、

    Kobi

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    GitHub 客户支持尚未告知我证书还原窗口的时间或时间、他们建议尝试与其他客户协调。  如果我听到任何声音、我会告诉您。

    Gary

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    好的、感谢您的更新。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    以下是 GitHub 开发人员支持的最新电子邮件:

    GitHub (GitHub 支持)

    2021年3月22日、UTC 下午5:12

    您好、Gary、

    感谢您回来。 我们仍在为恢复窗口制定计划、并正在查看其他选项、这些选项将帮助您重新开始。

    我直接与正在进行这些更改的工程团队合作、一旦我有更多内容要分享、我将与您再次联系。 很抱歉让你久等了!

    此致、
    Steve

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Gary、

    感谢您的更新!

    BR、

    Kobi

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    GitHub 今天的好消息。  我们下周有一个迁移到新证书的窗口。  我们还在考虑迁移到 Amazon S3、以便控制证书。  根据开发人员支持、GitHub 没有此选项。  感谢 Kobi 支持这项工作。

    GitHub (GitHub 支持)

    2021年3月25日、UTC 上午8:32

    您好、Kobi 和 Gary、

    我们正在与我们的证书提供商讨论他们可以为我们提供哪些选项。 根据答案、我们将有以下情形之一:

    ·       我们可以将绑定到旧根的证书作为一次性例外推出、直到该证书过期。 这意味着您将有时间将其翻转并修复更新机制。

    ·       如果他们无法提供帮助、我们将在几天内恢复到旧证书、以便您可以升级。

    因此、无论情况如何、我们都可以确保至少在下一个工作周使用旧 CA、并且您可以更新设备。

    时间窗口将为下周的周一至周四(周一08:00 UTC -周四15:00 UTC)

    无论我们最终选择了哪些选项、您都应该能够使用此窗口升级您的设备、以确保将来的升级也有效。

    根据上述场景中发生的情况、窗口可能会明显更长、但这是我们现在可以保证的最小值、以便您可以更快而不是更晚地准备。

    如果您对此计划有任何疑问或疑虑、请告诉我。

    此致、
    Steve

    Gary