• 状态 Resolved
  • 已锁定 已锁定
  • 回复 11 回复
  • 订户 0 订户
  • 视图 709 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] CC3235SF：在证书目录之外使用中间 CA 时未经授权

admin
Guru**** 2487425 points
Other Parts Discussed in Thread: UNIFLASH

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1208862/cc3235sf-not-authorized-when-using-intermediate-ca-outside-of-cert-catalog

器件型号：CC3235SF
主题中讨论的其他器件：UNIFLASH

您好！

我正在使用自签名根 CA 颁发供应商/叶证书、以便将设备连接到 Azure 上的物联网集线器。 为了提高安全性，我希望添加一个可在必要时切换的中间 CA。 据我所知、只有根 CA 需要位于证书目录中(采用 DER 格式、无扩展名、其名称与其"颁发给"字段完全相同)。

由于我已经锁定了 OTP、我只需尝试将 InterCA 添加到文件系统并将其安装在服务器上。 返回："未接受连接：0x5：未授权"。 当我尝试了虚拟  证书时,它只能与虚拟中间证书一起使用。 这使我认为中间证书也需要在目录中。

是这样吗？ 如果是这样、则无法将其切换掉。 或者我在这里缺失了什么内容吗？

很喜欢这里的一些帮助,提前感谢!

此致

大卫

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

    中间证书不需要在目录中。 只应包括根 CA。 但这两个文件都应该在器件文件系统中可用(名称与它们的常用名完全相同、没有任何扩展名)。

    自签名根 CA 应签署自证(因此"签发人"的名称将是根 CA 的通用名称)。

    目录不包含证书的完整内容、仅包含 其摘要。 因此、根文件可能仍需要在文件系统上。

    我不确定 "0x5：未授权"的来源是什么(是来自 Azure SDK 吗？) -如果您能提供触发错误的 SL API (sl_Connect 或 sl_StartTLS)的返回代码-我将能够进一步帮助您找到根本原因。

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

    是的、这来自 Azure SDK。 我找不到"sl_Connect"或"sl_StartTLS"、我们在 Azure SDK 中使用"tlsi_sl.c"中的"tlsi_sl_open"。 您提到的函数之前调用还是之后调用？  

    以下是完整的错误消息(减去用户名等) 

    -> 10:40:17 CONNECT | VER: 4 | KEEPALIVE: 60 | FLAGS: 128 | USERNAME: -----------------&DeviceClientType=iothubclient---------------- | CLEAN: 0
<- 10:40:17 CONNACK | SESSION_PRESENT: false | RETURN_CODE: 0x5
Error: File:../../sdk/iothub_client/src/iothubtransport_mqtt_common.c Func:mqtt_operation_complete_callback Line:1749
Connection Not Accepted: 0x5: Not Authorized

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

    在 tlsi_sl_open 中- 您可以找到对 SlNetSock_startSec 的调用。

    请打印此函数的返回代码。

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

    这样返回-468："SLNETERR_ESEC_UNKNOWN ROOT_CA"、该消息是关闭的、因为如果我正确理解、它只是一条警告。 软件签名证书和中间 CA 都是从同一根 CA 创建的，并且当叶证书由根直接颁发时，连接工作正常。  

    是否为所有自签名根 CA 提供了-468？ 或者这是否意味着设备无法从 Leaf -> Intermediate -> Root 找到链？

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

    我做了一个测试,是的,即使当我们直接从根发布叶我们确实得到相同的-468错误代码。 这似乎不是问题(因为连接良好)、并且使用自签名根时始终会给出此警告。  

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

    -468表示您未提供正确的服务器根 CA (服务器的证书未由提供的根 CA 签名)。  

    要查看服务器所需的根 CA，请参阅 证书处理指南中的2.5.1章"查找服务器的根 CA"。

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

    我发现问题、我们在服务器上安装了一个旧的中间 CA、因此无法正确地验证 Leaf/Vendor Cert。  我创建中级 CA 的方式也有一个问题。 它激活了"basicConstraints=CA:true"，但缺少"KeyUsage=keyCertSign"。 因此，不允许签署证书，导致链验证失败。

    这很难确定、请使用"openssl verify -CAfile PathToRootCA.pem -untrusted PathToCA.pem PathToCert.pem"  进行检查。  

    一旦我们创建了新的配置文件(匹配的配置文件)并将其安装到服务器上、它就可以正常工作。  

    即使是正确的巴尔的摩证书,我们得到-468仍然是有点奇怪的。 您是否知道在具有有效连接的情况下出现错误的原因？ 只是想确保我们以后不需要更改内容。

    此致
    大卫

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

    这意味着证书不包括在 已安装的证书目录中(您是否正在使用虚拟"游乐场"目录？)。

    TI 正式目录中包含 "Baltimore CyberTrust Root"-如果您使用的是不同的证书或 虚拟目录-您将收到此警告(-468)、但连接仍将断开。 您可以忽略返回代码或禁用目录验证(请参阅 SLNETSOCK_SECURE_DISABLE_CERT_STORE 或 SLNETSOCK_SEC_ATTRIB_DISABLE_CERT_STORE 套接字选项)。如果您使用  的是来自 SDK 的 MQTT、则可以将 MQTTCLIENT_NETCONN_SKIP_CERTIFICATION_DATA_NETConnClient_CALIBRAMQConnFlags 设置为(在 TTClient_PARAMS 中 )。

    例如、在 MQTT 示例中、我们将进行以下设置： 

    #define MQTT_CONNECTION_FLAGS MQTTCLIENT_NETCONN_URL | MQTTCLIENT_NETCONN_SEC |
    MQTTCLIENT_NETCONN_SKIP_CERTIFICATE_CATALOG_VERIFICATION

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

    (我们有一个已锁定在 OTP 中的自定义目录、但我有时会使用虚拟目录和虚拟认证尝试新事物)

    好的、这更有意义。 Azure 正在将其巴尔的摩根 CA 切换为 DigiCert 全局根 CA。 我们尚未将巴尔的摩添加到目录中、我已经看到有一些方法可以更改目录(稍后添加/删除认证)。 但 OTP 中包含初始目录的签名。 如果 OTP 无法重新编程、如何更改目录？ 例如、要添加巴尔的摩 CA、我是否需要创建新的 otp.inf"和新的目录签名？ 还是自动处理这些问题？

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

    OTP 仅包含用于验证目录签名的"自签名"证书、目录只是由该密钥签名的文件。

    新目录只需要使用相对私钥签名。  

    如果使用 TI OTA 库、则可以使用 uniflash 或 CCS 创建包含要替换的目录的 OTA 映像。 也可以覆盖

    "/sys/certstore.lst 文件。
  • 0
    TI__Guru**** 2487425 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    啊、好的。 感谢您的澄清！