[参考译文] CC3200：无法使用 CC3200与 AWS IOT 内核连接

您提供的链接不显示证书。

您是否使用 sl_SetSockOpt 将套接字链接到证书(请参阅下面的示例)？

Sl_SetSockOpt(sockID, SL_SOL_SOCKET, SL_SO_SECURE_FILES_CA_FILE_NAME, ”rootCA.der”, strlen(“rootCA.der”));

函数 static _i32 create_socke API 已经在执行此操作。我已经附加了代码片段供您参考。  

请确认 sl_SetSockOpt (sockID、sl_SOL_socket、sl_SO_SECURE_FILES_CA_FILE_NAME、“rootCA.der”、strlen (“rootCA.der”));”) 我们是否需要显式执行此操作？  

我还通过私人聊天发送了证书  

您是否获得 了 SL_ESECBADCAFILE (-456)？

这意味着文件已损坏(但根 CA 格式看起来正常)或文件路径错误(您是否可以将文件存储在文件系统的根文件夹中、因此路径中不需要任何斜杠？)。

我也不认为这是 AWS 服务器的正确根 CA、但这会导致不同的错误代码。

很抱歉，我们收到(-458) /*错误安全级别错误私有文件*/错误。 当 我们按顺序、私钥、Device cert 下一个根 CA 在安全文件中提供所有3个证书时。

使用相同的证书，我可以使用 MQTT.FX 与 AWS IoT 内核连接。

您是否检查了根文件夹中的文件？

证书被复制到 f00_cer_private.der.Please 请告诉我是否需要更改？

您是如何复制证书的？ 或使用 Uniflash？

文件系统中的路径+名称应与"sl_SetSockOpt"中的路径+名称完全相同。  

您可以 使用"sl_FsGetInfo"来检查文件是否存在。

我们使用 Uniflash 下载该文件。 我使用  sl_FsGetInfo 函数验证了路径名称、它返回状态为"0"。我认为文件位置没有问题 、如果可能、您可以尝试使用  我提供的证书从您的一侧连接 AWS IoT 内核。我可以提供端点详细信息。

458表示栈在文件系统中找不到私钥文件(假设您使用了提供的私钥)。

您在哪里使用了以下文件名： f00_cer_private.der?

Kobi、

我正在与 Linga 合作执行这个项目。 包括更多详细信息。 "f00_cer_private.der"是我们的 CC3XX_template.xml 文件中的参考文件。

使用 uniflash 从目标器件获取的文件系统

已验证文件是否存在，并使用 simplelink 的函数 ReadFile()来获取证书的实际字节数。 与文件系统匹配。 仍然有-458错误  

您能否捕获 NWP 日志？ (请参阅 https://www.ti.com/lit/pdf/SWRU368C 中的第19章)

包含 NWP 日志。 请看一下、并告诉您的想法

e2e.ti.com/.../NWP.zip

日志有问题。 我无法解析它们。

Kobi 附上了这些日志。请查看它们。 包含文本版本和二进制版本。  e2e.ti.com/.../NWPCC3200.zip

我可以看到我们能够读取根 CA 文件、但解析失败(返回 BADCA=-456响应)。

确保写入"/cer/ca.der"的文件完全是您发送给我的 ca.de文件。 我找不到解析失败的任何原因(假设文件内容正确)、但我们将在内部对其进行审核/测试。 如果我发现任何问题、我会告诉您。

您是否安装了最新的 CC3200服务包(我在日志中看不到)？  

Kobi 我使用的文件与您共享的文件相同。ATS 端点也相同。我拥有证书的分区名是/cer/ca.de r 服务包详细信息为、

主机驱动程序版本：1.0.1.14
NWP 版本：2.15.0.1
固件版本：31.1.6.0.2
PHY 版本：1.0.3.37
编译版本2.15.0.1.1.31.6.0.2.1.3.37
芯片 ID 67108880

好的。 我将在结尾处尝试此根 CA

这可能需要几天 时间、 我会在完成后立即告知您我的调查结果。

Kobi、

最后 ，我们 能够在以下更改列表后连接 AWS IoT 内核。

使用以下命令将私钥文件转换为.der。  

OpenSSL RSA -inform pem -in aws_prvkey.key -outform der -out aws_prvkey.der

使用以下命令将器件证书文件转换为.der  

OpenSSL x509 -INFORM -IN AWS 设备证书 crt -outform der -out aws_rootCA.der

root-ca 按此票证 中指定的方式使用：https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/881308/cc3200-launchxl-cc3200

但有一点我无法理解为什么我们只需要使用"  Starfield 2类认证机构根 ca"、为什么不使用 AWS 提供的其他 RootCA。

基于在链接中提供的 AWS 详细信息：  准备 AWS 迁移到自己的证书颁发机构| AWS 安全博客(amazon.com).It不拥有 “ Starfield Class 2 Certification Authority root ca”证书。 请告诉我 、我们需要在 CC3200 SDK /Source 中进行哪些更改、以支持 AWS 或 Starfield Services 根证书颁发机构- G2提供的常规根 CA。

  Starfield Class 2认证机构根 CA 和 AWS / Starfield Services 根证书授权机构- G2之间的主要区别是签名算法。

使用的 Starfield Class 2认证机构根 CA： sha1rsa

AWS / Starfield Services Root Certificate Authority - G2 root ca used： sha256rsa

我们是否更新 CC3200 SDK 中的任何内容以支持 sha256rsa？

Kobi、

 我在个人聊天中发送了我的端点详细信息。

这是 AWS 的问题。  

抱歉、Kobi。这可能不是 AWS 问题、因为客户端拒绝连接。 AWS 根 CA 正在与所有其他微控制器和 PC 应用程序配合使用、只有 TI 不接受该证书。 我是否知道 TI CC3200是否支持 SHA256？ 我们是否可以使用 AWS 根 CA 将 CC3200连接到 AWS IOT？

是的、对于服务包、它应该支持 SHA256。

我不明白、您是否能够连接到"Starfield 2类认证机构根 CA"？

如果是、为什么要为此端点使用其他根 CA？

我能够与 Starfield 2类认证机构根连接、但无法与 AWS 根 CA 连接。 请参阅链接： 如何准备 AWS 迁移到其自己的证书颁发机构| AWS 安全博客(Amazon.com)

根据此链接 、Starfield 2类认证机构根 CA 不由 AWS 维护、该证书也将在2034年到期、这就是我们 不希望使用该证书的原因。 我们希望使用 由 AWS 维护的证书，以便当 证书发生任何更改时，该过程对我们来说很容易。

是的，我使用的是最新的服务包： CC3100_CC3200_ServicePack_1.0.1.1414-2.12.2.8  

请告诉我 、我们需要更改哪些内容才能使用 AWS 根 CA。

你好，Kobi，

 请告诉我、TI SDK 需要对 AWS 根 CA 支持进行任何更新。

每个套接字都可以分配一个根 CA。 如果服务器即将更换根 CA、您可以添加一个代码、尝试使用一个根 CA (例如  Starfield)进行连接、如果失败、则会尝试   再次连接到第二个根 CA (Amazon root ca)。

Kobi、

我的问题是、当我们使用 AWS 根 CA 时、为什么 TI 3200关闭 TLS 连接时出现证书错误。我知道每个套接字都将分配给根 CA。 如果您正在查找任何日志、请告诉我。 您能否检查 使用 AWS 根 CA 将 CC3200连接到 AWS IOT 内核。

当我们尝试连接到 AWS 时、它使用 Starfield 根 CA。

目前、AWS 未维护 Starfield 2类认证机构根 CA。请告诉我、TI 何时可以通过 CC3200支持 AWS 根 CA。

我们无法支持 CC3200上的任何新更新。 如果特定证书有问题(检查我看不到原因的内容)。 您可以尝试在 CC3200 TCP 套接字顶部使用外部 TLS 堆栈(如 mbedTLS)。  

 "您可以尝试在 CC3200 TCP 套接字顶部使用外部 TLS 堆栈(如 mbedTLS)。 "请告诉我此解决方案将如何工作，因为它仍然使用 SL_ZZZZ 网络 API，这将有相同的问题。

它将使用不安全的 TCP sl_socket (因此在 NWP 中使用网络堆栈、而不是 TLS 堆栈)。

在主机上、您将实现 TLS 堆栈。 在下一 个 CC32XX (3220/35) SDK 中、我们将包括此类支持 TLS1.3的解决方案(因为内部 TLS 堆栈仅支持 TLS1.2、无法通过 SP 进行修复)。 这也适用于 CC3200。

在这种情况下、证书将仅由基于主机的 TLS 堆栈处理。