[参考译文] CC3230SF：CC32xx 需要最新的 certcatalogProduct_20240320.lst（游乐场太旧）

您好：

据我所知、操场目录仅包含所谓的 TI 虚拟证书。 如果要使用“真实“证书验证、必须在 UniFlash-Project-Settings 中激活“Use default Trusted Root-Certificate Catalog“。

该目录由 TI 处理、也是 SDK 的一部分、请参阅 \ \tools\cc32xx_tools\certificate-catalog。
该文件夹中是受支持的根 CA 的列表。

因为我不使用它,我不能说这是不是最新的。
在旧版本中、ISRG 根 X1 不在列表中。

此外、我也非常有兴趣了解 TI 对默认可信根目录的更新程度。

此致、
罗马

你好 Roman Jordan,

我仍然不确定其中一个部分：如果 TI 提供的默认可信根证书目录中未包含 ISRG 根 X1 证书、那么正确的包含方式是什么？

据我所知、创建自定义受信任根目录的过程需要对目录文件签名。 但是、由于 ISRG 根 X1 是公共证书、而不是我可以签署的证书（因为它不是我的私钥）、因此我在生成包含该证书的有效已签名目录时遇到了问题。

我的问题是 — 如果 TI 的默认目录缺少根证书、例如 ISRG Root X1、什么是 最佳方法 安全地包含该密钥、以便 CC32xx 器件能够执行正确的证书验证（而不跳过验证或禁用 TLS 检查）？

是否建议：

• 使用手动构建新的证书目录openssl、并使用我们自己的密钥对其签名？

• 或者、TI 是否有官方方式来更新或扩展默认的受信任根目录？

此致、
Aiman

您好、Aiman、

如果 ISRG 根 X1 证书未包含在 TI 提供的默认可信根证书目录中

在我当前工作的 PC 上安装了较旧的 SDK 5.30。
在我旧版 C：\ti\simplelink_cc32xx_sdk_5_30_00_08\tools\cc32xx_tools\certificate-catalog\readme.md 的关联文件中、未提及 ISG。
我假设它不受支持、至少在该 SDK 版本中是如此。

根据我的理解、创建自定义受信任根目录的过程需要对目录文件进行签名。 但是、由于 ISRG 根 X1 是公共证书、而不是我可以签署的证书（因为它不是我的私钥）、因此我在生成包含它的有效已签名目录时遇到了问题。

必须根据要包括在列表中的公共根证书创建目录文件。
该文件必须由您签名、而不是证书文件本身。
  有关详细信息、请参阅 SWRU547A 供应商器件验证。

如果 TI 的默认目录缺少根证书（如 ISRG Root X1）、什么是 最佳方法 安全地将其包含在内、以使 CC32xx 器件能够执行正确的证书验证（而不跳过验证或禁用 TLS 检查）？

好问题;)
您可以使用 openssl 通过自己的私钥创建自己的自签名证书、而不是创建证书目录并使用私钥对其进行签名。
您还必须创建自己的 OTP、该 OTP 必须刷写到器件中。
请记住、OTP 中存储的私钥存在限制。

TI SWRU547A：
信任根公钥[300 字节]【必需】–此公钥是用作的 RSA 密钥
供应商的信任根。 供应商的证书目录必须由相应的私有证书签名
密钥。 其他安全和已签名文件应使用目录中的其中一个链进行签名、也可使用该文件进行签名
按这个键。 公钥必须是 RSA-1024 密钥或 RSA-2048 密钥。

此致、
罗马

嗨、 Roman Jordan、

再次感谢您的解释。

我开始研究自定义受信任根目录的原因是因为我经常遇到这种情况 TLS 错误–468 可能会对 CC32xx 施加干扰 HiveMQ Cloud 。 与我使用类似工具进行验证的相似 MQTT 资源管理器 、连接仅在使用时工作正常 ISRG 根 X1 （Let's Encrypt 根证书）作为受信任的 CA。

但是、我目前正在处理的是 SDK 7.10. 看来是这样的 不包括 ISRG 根 X1 在该版本提供的默认可信根证书目录中。 目录的文档readme.md () 没有提及 ISRG、后者支持这一结论。

到目前为止、我已经尝试isrgrootx1以多种格式将证书上传到 CC32xx 文件系统：

• .pem

• .der

• .crt

然后我在我的套接字选项中引用了它，但不幸的是，这些选项都不起作用 — 连接仍然失败，并出现错误SLNETSOCK_SEC_ATTRIB_PEER_ROOT_CA–468。

经过仔细的检查,我意识到了 isrgrootx1.pem我当前使用的文件是 RSA 4096 位 。 这可能是一个关键问题、如所示 TI CC32xx 仅支持 RSA 1024 位或 2048 位密钥 不可信的证书处理中。 这两个限制在中强制执行 OTP 存储器 （用于信任根公钥）和 TLS 验证逻辑中。

因此、我一直在考虑生成定制的受信任根证书目录并对其签名、如中所述 SWRU547A 。 但我非常关注 刷写 OTP 存储器不可逆 —如果目录或密钥未正确准备、可能会导致设备永久砖化。

因此、在我继续之前、我想问：

是否有替代方法允许我安全地信任 CC32xx 上的 ISRG 根 X1、而无需刷写 OTP 或创建已签名证书目录？

理想情况下、我正在寻找能够满足以下条件的解决方案：

• 使用 ISRG Root X1 从 HiveMQ 验证 TLS 链

• 避免依赖过时的 TI 根证书目录（因为缺少 ISRG）

• 避免通过不正确的 OTP 编程来锁定器件的风险

再次感谢您的见解—我非常感谢您对此提供的任何指导。

此致、

Aiman

尊敬的 Aiman：

我现在很忙、因此很抱歉、答案很短、不完整。

为防止误解：

这可能是一个关键问题、如所示 TI CC32xx 仅支持 RSA 1024 位或 2048 位密钥 不可信的证书处理中。 这两个限制在中强制执行 OTP 存储器 （用于信任根公钥）和 TLS 验证逻辑中。

此限制仅适用于用于对证书目录进行签名的密钥。
它不适用于包含的证书。 因此、我假设这不是问题。

如果目录或密钥未正确准备、可能会永久性地冻结设备。

自签名的根 CA 证书也是如此。
所以要小心；）

其他的应该是可以替换的。

此致、
罗马

尊敬的 Aiman：

 如果控制器无法验证服务器的根 CA 证书、则通常会出现错误–468 SLNETERR_ESEC_UNKNOWN_ROOT_CA、因为该错误不是 TI 虚拟目录的一部分。
我扩展 TI 虚拟目录的尝试没有奏效。

是否有另一种方法允许我安全地信任 CC32xx 上的 ISRG 根 X1、而无需刷写 OTP 或创建签名证书目录？

是、您可以完全忽略此错误、因为 TI 也会忽略函数中的一些安全错误

SDK 使编程器也能够忽略一些安全错误。
请参见 SDK 函数 HttpClient_connect 、HttpClient_connect2 、文件 httpclient.c

此致、
罗马

您好、

你是对的。 此 ISRG 根 CA 不在需要刷新的最新目录中。

我会在内部进行研究、了解何时可以刷新。

现在,您可以使用  SLNETSOCK_SEC_ATTRIB_DISABLE_CERT_STORE 绕过测试 。

uint32_t dummyVal = 1;

retVal = SlNetSock_secAttribSet(secAttribs, SLNETSOCK_SEC_ATTRIB_DISABLE_CERT_STORE, (void *)&dummyVal, sizeof(dummyVal));
if (retVal < 0)
{
    SlNetSock_secAttribDelete(secAttribs);
    return (retVal);
}

Shlomi

你好  Shlomi Itzhak 和   Roman Jordan,

感谢您的更新。

我尝试绕过使用建议的证书验证SLNETSOCK_SEC_ATTRIB_DISABLE_CERT_STORE、但遗憾的是、我仍然遇到以下错误：

[NETWORK::ERROR] TLS connection failed with error: -111  
[MQTT_IF::ERROR] connect failed: -468

除此之外、我还尝试了中所述的方法 SWPU332A、第 2.5.5 节 功耗 swru547a、第 7.1 节 。 我故意避开了 第 7.2 节 以防止可能导致器件闪烁的潜在错误步骤。

我还尝试将各种格式（，，）.cert.pem.crt的证书直接添加到根目录中、希望它可以解决问题—但到目前为止没有成功。

如果有任何进一步的建议或在等待更新的根目录时有已知的解决方法、将不胜感激。

此致、

Aiman

您好、

让我们重点关注禁用目录。 另一个主题与 OTP 有关、但 OTP 是另一个故事。

作为 SLNETSOCK 机制的一部分、我增加了一种禁用证书目录的方法。

不确定您使用的是什么。

有一个套接字选项可用于禁用目录、使用 SL_SO_SECURE_DISABLE_CERTIFICATE_STORE。

status = sl_SetSockOpt(SockID,SL_SOL_SOCKET, SL_SO_SECURE_DISABLE_CERTIFICATE_STORE,
&dummyVal,sizeof(dummyVal));

Shlomi

尊敬的  Shlomi Itzhak：

再次感谢、但只是为了澄清一下—我已经SL_SO_SECURE_DISABLE_CERTIFICATE_STORE在实现中尝试使用了套接字选项、如下所示：

UART_PRINT("[NETWORK::INFO] Setting CA certificate: %s\n", caFileName);
ret = sl_SetSockOpt(sockId, SL_SOL_SOCKET, SL_SO_SECURE_FILES_CA_FILE_NAME,
                    caFileName, strlen(caFileName));
if (ret < 0) {
    UART_PRINT("[NETWORK::ERROR] SetSockOpt CA_FILE_NAME failed: %d\n", ret);
    sl_Close(sockId);
    return;
}
UART_PRINT("[NETWORK::INFO] CA certificate set successfully\n");

ret = sl_SetSockOpt(sockId, SL_SOL_SOCKET,
                    SL_SO_SECURE_DISABLE_CERTIFICATE_STORE,
                    &dummyVal, sizeof(dummyVal));
if (ret < 0) {
    UART_PRINT("[ERROR] Failed to disable cert store: %d\n", ret);
}
UART_PRINT("[NETWORK::INFO] disable CA certificate successfully\n");

但是、结果仍然是：

[NETWORK::ERROR] TLS connection failed with error: -111

同样、在使用时 MQTTClient_connectParams结构和设置标志：

connectParams.connFlags |= MQTTCLIENT_NETCONN_SKIP_CERTIFICATE_CATALOG_VERIFICATION;

[MQTT_IF::ERROR] connect failed: -5

文件系统中确实有目录、对吧？

哪个目录？ 是假的还是常规的？

您用于此连接的 CA 证书是否出现在编程的目录中？

是的、我目前正在使用 虚拟目录 。

关于这个问题：

您用于此连接的 CA 证书是否显示在编程的目录中？

我不太确定我完全理解这一点。

此外、我打开了一个新主题、询问有关 OTP 和正确的目录编程、以避免使本主题脱轨。

谢谢。

只需确保在代码中设置根 CA（即使您绕过它）、并且此根 CA 是目录的一部分。

因此、如果您使用虚拟目录、则可以设置例如 dummy-root-ca。

它不会被使用、但需要进行设置。

Shlomi

尊敬的 Shlomi Itzhak：

只是为了确认我的理解：

即使我习惯SL_SO_SECURE_DISABLE_CERTIFICATE_STORE绕过证书存储验证、我仍然是这样 必须使用设置根 CA SL_SO_SECURE_FILES_CA_FILE_NAME和 CA 文件 必须包含在证书目录中 刷写到器件中。

所以在我的例子中dummy-root-ca.der,我可以使用,在代码中设置它,如下所示:

sl_SetSockOpt(sockId, SL_SOL_SOCKET,
              SL_SO_SECURE_FILES_CA_FILE_NAME,
              "dummy-root-ca.der", strlen("dummy-root-ca.der"));

然后调用：

uint32_t dummyVal = 1;
sl_SetSockOpt(sockId, SL_SOL_SOCKET,
              SL_SO_SECURE_DISABLE_CERTIFICATE_STORE,
              &dummyVal, sizeof(dummyVal));

这是在根目录中插入的文件

即使证书实际上不会被验证、此设置也可以避免FS_ERR_ROOT_CA_IS_UNKNOWN TLS 连接期间出现签名错误。

如果正确或我误解了任何内容、请告诉我。

谢谢、

Aiman

是的。

您是否对其进行了测试？

是的、我已经进行了测试、但连接仍然失败、并出现以下错误：

#define SL_ERROR_BSD_ESEC_ASN_NO_SIGNER_E (-688L) // ASN no signer to confirm failure

是的、您配置的证书必须驻留在目录中、如果您使用的是真实目录、则伪根 CA 不好。

您需要使用目录中的一个根 CA。

您可以使用任意、无关紧要、因为您无论如何都绕过检查。

您可以在线找到其中的任何一种。

如果您无法找到一个、请告诉我。

您好：

也许它有助于澄清如何处理目录文件的 3 种不同的可能性。

为了进行全面的安全检查、您不能使用 TI 游乐场证书。
我不确定如果您使用 TI Playground、是否可以绕过目录商店。
但这也会影响安全性。

1.游乐场券
确实存在一个可用作 RootCA 的证书、即伪根 ca-cert
如名称所示,该认证可用于签署您的个人游乐场。
例如、您有一个名为  myserver.com 的服务器、并且要评估连接安全错误、则服务器的域证书必须使用 伪根 ca-cert 签名
据我所知、证书操场不能扩展。

2. TI 受信任的根证书目录
该目录使您能够评估连接安全错误。
目录文件会被处理并且必须由 TI 签名。
如果我理解阿菲格·艾门的问题是正确的,他可以使用它的更新版本来解决他的问题。
但据我所知、没有更新。

3.供应商证书目录
基本上与 TI 受信任的根证书目录相同、但允许的签署人从 TI 更改为供应商。
现在、供应商可以修改 Catalog。
为此、您需要执行上述操作。
负责证书和关联的密钥

TI 专家，如果我弄错了，请纠正我；）

此致、
罗马

您好、

您的理解是正确的。

选项 2 或 3 有效。

对于选项 2、我知道请求的根 CA 不在目录中、但由于他无论如何都会绕过它、他应该很好地从列表中引入任何现有的根 CA 证书（在同一目录的 README 文件中有一个受支持证书列表）。

此致、

Shlomi