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.

[参考译文] CC3220SF:到 AWS IoT Core TLS 1.3的安全 MQTT 连接

Guru**** 1955920 points
Other Parts Discussed in Thread: CC3220SF, UNIFLASH
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1439169/cc3220sf-secure-mqtt-connection-to-aws-iot-core-tls-1-3

器件型号:CC3220SF
主题中讨论的其他器件: UNIFLASH

工具与软件:

您好!

我正在 尝试 在 TI 的 CC3220SF Launchpad 和 AWS IoT Core 代理之间建立安全 MQTT 连接。  我已经遵循了 与此问题相关的大多数其他线程、但是、 提供的解决方案要么不 适合我、要么似乎是死胡同。

我正在 使用"mqtt_client_over_tls_1_3"演示工程 TI-RTOS7和 SDK 7.10.00.13作为基础、似乎无法使 安全连接正常运行。  

我设法获得了一个不安全的连接,以及一个安全的连接为 mosquitto 代理工作,它只使用一 个证书进行验证,但 AWS 需要3个文件(root-CA.crt、client.cert.pem、private key.private .key ),而尝试用同样的方式使用它们似乎不起作用。

以下是我的当前配置以及到目前为止已尝试的各种功能:

-在"wifi_settings.h"中设置的 AP_SSID 和 AP_PASSWORD

-使用 mqtt_qos_0  

-连接标志: MQTTCLIENT_NETCONN_URL | MQTTCLIENT_NETCONN_SEC | MQTTCLIENT_NETCONN_SKIP_CERTIFICATE_CATEGORY_VERIFICATION

-端口8883

-在 userFiles 中使用 uniflash 刷写证书(根目录)

-安全文件: {"private-key.pem","client-cert.t52.pem","root-ca.pem", NULL}

使用 "安全文件"中的上述文件、我收到以下错误:
mbedtls_x509_crt_parse (远程根 CA 证书)::root-ca.pem 返回-8576

mbedtls_x509_crt_parse (本地 PEM 证书):client-cert.404.pem 返回-8576

mbedtls_pk_parse_key (私钥):private key.pem 返回-15616

...

mbedtls SSL/TLS 握手失败。

...

连接失败:-3001

-我也使用了尝试 转换证书到.der 文件使用以下命令:

OpenSSL x509 -inform pem -in <CA_CERT_FILE_NAME>-outform der -out root-CA.der

OpenSSL x509 -inform pem -in <CLIENT_CERT_FILE_NAME>-outform der -out client-cert.der

OpenSSL pkcs8 -topk8 -in. -inform pem -out private-key.der -outform der -nocrypt

使用.der 格式的证书时、它现在成功执行 SSL/TLS 握手并且证书验证通过、但是它会为我提供 以下 "mbedtls_ssl_READ return 0"、然后是 mqtt_event-server-disconnect  

-我已经用一个名为 MQTT Explorer 的测试客户端测试了这些证书+私钥。 当使用 原始格式(.pem/.crt)的证书时、我能够成功连接和发送/接收消息、但是以.der 格式使用证书时、连接失败。    

- AWS IoT Core Thing 设置正确,并附有政策。

-政策本身不受限制,其设置 为接受所有:{..,"行动":"IoT :*","资源":"*",...}

-我有 AWS CloudWatch 日志设置为 IoT Core 和一些日志显示,它确实设法连接,给出以下信息:

{...、"status":"succe""eventType":"connect""protocol":"mqtt"、"clientId":"iotconsole-..."、 ....}

尽管有连接、但它无法通过发送任何消息、似乎随后断开连接。

 

从我收集到的信息中、我认为证书解析不正确、导致连接失败。 如果我尝试使用.pem/.crt 格式进行连接、则无法解析证书、如果我使用.der 格式、它会给我一个 mbed_ssl_read()返回0 (这是当 peer/AWS 关闭连接时??)。  

如有任何帮助、将不胜感激。

  

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

    您好!

    我会坚持使用 DER 格式。

    返回代码0表示另一端(AWS 服务器)出于某种原因关闭了连接。

    您正在使用外部库 TLS1.3。 是否有机会使用内部 TLS 堆栈进行测试、即 MQTT 客户端示例?

    此外、如果可能、空气嗅探器也可以提供一些光线。

    Shlomi

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

    您好!

    我曾尝试使用 DER 格式进行连接、如上所述、他们似乎通过了验证(握手成功)、但 AWS 关闭了连接。 我可能会错误地转换它们? 我使用 MQTT Explorer 客户端对其进行测试时、会在.der 格式中导致连接失败。

    我明天可以使用 MQTT 客户端演示进行更多测试、如果我有任何进展、我们会联系您。  

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

    用于转换证书的 openssl 命令看起来不错。 您还可以双击它们、查看 Windows 是否打开证书 GUI。

    至于密钥、您确定它是  pkcs8吗? 密钥 pem 版本的标头是否以 ----开头? 开始使用私钥--- 或 --- 开始使用 RSA 私钥--- ?

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

    标题以  "----开头 开始使用 RSA 私钥--- "。 虽然我已经尝试使用以下命令转换它: OpenSSL rsa -in .private.key -out private-key.der -outform der。

    这会为密钥生成证书文件、但尝试打开该文件会出现以下错误:  

    将 client-cert 转换到.der 还会生成一个证书文件、我可以打开该文件、但显示 windows 无法验证它:

          

    唯一的 无缝转换是根证书、我可以将其从.crt 转换为.der、它在转换后仍然有效。

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

    密钥正常、不能像证书一样打开。

    根据报头、密钥是 rsa、pkcs1。 在您提到的原始线程中、使用 pkcs8并不好、但您现在用于转换的线程看起来不错。

    您的 Windows 目录中可能不存在证书颁发者。

    虽然问题不大、但您还需要确保根 CA 位于 cc3220的证书目录中。 是否可以共享正在使用的根 CA?

    Shlomi

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

    我正在使用 Amazon Root CA 1、这是我最初设置 IoT Core 时提供的根 CA。

    证书如下:

     --- BEGIN CERTIFICATE-----
    MIIDQTCCAimgAwIBAgITBmyfz5M/jAo54vB4ikPmljZbyjANBgkqhkiG9w0BAQsF
    ADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQDExBBbWF6
    b24gUm9vdCBDQSAxMB4XDTE1MDUyNjAwMDAwMFoXDTM4MDExNzAwMDAwMFowOTEL
    MAkGA1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEZMBcGA1UEAxMQQW1hem9uIFJv
    b3QgQ0eGMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAGOCggEBALJ4gHHKeNXj
    ca9HgFB0fW7Y14h29Jlo91ghYPl0hAEvrAIthtOgQ3pOsqTQNroBvo3bSMgHFzZM
    9O6II8c+6zf1tRn4SWiw3te5djgdYZ6k/oI2peVKVuRF4fn9tBb6dNqcmzU5L/qw
    IFAGbHrQgLKm+A/sRxmPUDgH3KHOVj4utWp+UhnMJbulHheb4mjUcAwhmahRWa6
    VOujw5H5SNz/0egwLX0tdHA114gk957EWW67c4cX8jJKLhD+rcdq08p8kDi1L
    93FcXmn/6pUCyziKrlA4b9v7LWIbxcceVOF34GfID5yHI9Y/QCB/IIDEgEw+OyQm
    jgSubJrIqg0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC
    AIYHQYDVR0OBBYEFIQYzIU07LwMlJQuCFmcx7IQTgoIMA0GCSqGSIb3DQEBCwUA
    A4IBAQCY8jdaQZChGsV2USggNiMOruYou6r4lK5IpDB/G/wkjUu0yKGX9rbxenDI
    U5PMCCjjmCXPI6T53iHTfIUJrU6adTrCC2qJeHZERxhlbI1Bjt/msv0tadQ1wU
    n+gDS63pYaACbvXy8MWy7Vu33PqUXHeeE6V/Uq2V8viTO96LXFvKWlJbYK8U90vv
    o/ufQJVtMVT8QtPHRh8jrdkPSHCA2XV4cdFyQzR1bldZwgJcJmApzyMZFo6IQ6XU
    5Msi+yMRQ+hDKXJioaldXgjUkK642M4UwtBV8ob2xJNDd2ZhwLnoQdeXeGADbkpy
    rqXRfboQnoZsG4q5WTP468SQvG5
    --- END CERTIFICATE-----

    我确保它没有任何多余的空格或新的线条等

    我还对 mqtt_client 演示(TLS 1.2)感到困惑、我似乎也无法在这里使用它。 在这个版本,它甚至似乎不执行握手,它只是直接给出了一个"连接失败:-458"。 我甚至无法 安全地连接到 test.mosquitto.org (它在 TLS 1.3上工作)、它再次给出了一个-"连接失败:-461"。    

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

    好的、我设法使用 mqtt_client 演示(TLS 1.2)实现了成功连接。 证明证书没问题、我忘记更新日期/时间定义了。 我用 mosquitto 和 AWS 测试了它-两者都 成功连接,并能够通过发送消息。 但它仍然无法用于较新的 TLS 1.3演示。  

    不确定整个证书目录的内容。 我使用本指南将证书添加到我的 Windows 个人目录中(不确定这是否正确、如果它有什么不同): https://learn.microsoft.com/en-us/biztalk/adapters-and-accelerators/accelerator-swift/adding-certificates-to-the-certificates-store-on-the-client

    我还尝试 在 uniflash 中将证书目录列表文件从我的 SDK 链接起来:

      

    尝试按此方式刷写时、它会抛出以下错误: FS_ERR_ROOT_CA_IS_UNKown、这意味着它无法在目录中找到证书? 不确定原因、我已经从 TI 网站查看了目录列表、其中包括 我正在 使用的 Amazon Root CA 1。 我甚至用同样的名称来命名它(见过类似的线程、其中提到命名约定很重要?):

      

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

    您好!

    我仔细检查了一下、这个根 CA 确实在目录中。

    您成功地与 TLS 1.2连接的事实证明了这一点。

    何时会出现  FS_ERR_ROOT_CA_IS_UNKown 错误? 在尝试连接到服务器时会发生什么? 更早?

    请注意、无论使用何种 TLS、目录的工作方式都相同。

    此致、

    Shlomi

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

    当我将证书目录从 SDK 加载到"受信任根证书目录"部分后、尝试在 uniflash 中对映像进行编程时会发生这种情况。  刷写过程结束时、它会弹出该错误。   

    我在 TLS 1.3方面的主要问题仍然是在成功握手和认证验证之后出现"mbedtls_ssl_READ 0"消息(根据我所了解的内容、这是由对等方发起的断开)。 我的 AWS 策略相当轻松(仅用于测试)、 CloudWatch 日志还显示 一些连接成功。  

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

    您好!

    就编程而言、在内部 TLS 堆栈和外部 TLS 上的工作之间应该没有任何区别。 因此、我不知道在编程时是如何得到这个错误的、以及它是如何与内部 TLS 堆栈一起工作的。 Uniflash 项目在两种情况下是相同的? 区别是什么?

    至于 TLS1.3的错误、可能值得在外部 TLS1.3堆栈上打开调试消息并了解其失败的原因。

    调试机制位于顶部的 slnetifWIFI.c 中。 我会首先将 DEBUG_LEVEL 增加到3。

    您是否在终端上看到消息?

    Shlomi

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

    您好!

    我看了看打印输出,看着客户的问候。

    您可以看到版本显示为[3:3]、该版本与 TLS1.2相关(输出记录:msgtype = 22、version =[3:3]、msglen = 240)、但在代码中 、它特意配置为 TLS1.2、 因此我不认为这是问题所在:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    int mbedtls_ssl_write_record( mbedtls_ssl_context *ssl, int force_flush )
    {
    int ret, done = 0;
    size_t len = ssl->out_msglen;
    int flush = force_flush;
    MBEDTLS_SSL_DEBUG_MSG( 2, ( "=> write record" ) );
    if( !done )
    {
    unsigned i;
    size_t protected_record_size;
    #if defined(MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH)
    size_t out_buf_len = ssl->out_buf_len;
    #else
    size_t out_buf_len = MBEDTLS_SSL_OUT_BUFFER_LEN;
    #endif
    /* Skip writing the record content type to after the encryption,
    * as it may change when using the CID extension. */
    mbedtls_ssl_protocol_version tls_ver = ssl->tls_version;
    #if defined(MBEDTLS_SSL_PROTO_TLS1_3)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    当您提到监听器时、您可以共享它吗? 是否是显示握手的无线监听器?

    我目前认为使用 TLS1.2不存在问题、但应该知道其失败的原因。

    Shlomi

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

    您好!

    以下是连接期间收到的其中一个数据包(名为"Server Hello")的日志输出:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    Frame 333: 181 bytes on wire (1448 bits), 181 bytes captured (1448 bits) on interface \Device\***, id 0
    Section number: 1
    Interface id: 0 (\Device\***)
    Interface name: \Device\***
    Interface description: WiFi 2
    Encapsulation type: Ethernet (1)
    Arrival Time: Nov 21, 2024 16:24:02.828045000 GMT Standard Time
    UTC Arrival Time: Nov 21, 2024 16:24:02.828045000 UTC
    Epoch Arrival Time: 1732206242.828045000
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.003290000 seconds]
    [Time since reference or first frame: 19.008555000 seconds]
    Frame Number: 333
    Frame Length: 181 bytes (1448 bits)
    Capture Length: 181 bytes (1448 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:tls]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
     

    还有其他数据包,如"更改密码规范","你好重试请求",我也收到在过程中,如果它的帮助,我可以发布.

    我决定暂时只使用 TLS 1.2演示、因为它目前使用的是 starfield 2级证书。

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

    密码套件 TLS_AES_128_GCM_SHA256似乎适用于 TLS1.3、而整个消息仍然使用 TLS1.2进行打包。 不知道为什么。

    另一个捕获显示"在 TLS 1.3兼容模式下忽略 ChangeCiphSpec "、并且  仅通过 TLS1.2从客户端发送 ChangeCiphSpec。

    TLS1.2最终工作的原因可能在于 mbedtls 是在启用兼容模式的情况下编译的。 请参阅库中的以下部分:

    /**
    *\def MBEDTLS_SSL_TLS1_3_compatibility_mode
    *
    *启用 TLS 1.3中间件箱兼容模式。
    *
    *如 RFC 8446第 D.4节所述,TLS 1.3提供了兼容性
    *使 TLS 1.3连接更有可能通过中间框的模式
    *预期 TLS 1.2流量
    *
    *打开兼容模式的代价是增加几个字节
    *在线路上,但它不会影响与 TLS 1.3实现的兼容性
    *不使用它。 因此、除非传输带宽至关重要
    *您知道不会发生中间盒兼容性问题,因此是的
    *建议您设置此选项。
    *
    *禁用 TLS 1.3兼容模式的注释。 If
    * MBEDTLS_SSL_PROTO_TLS1_3未启用、此选项不包含任何选项
    *对版本的影响。
    *
    */

    Shlomi

x 出现错误。请重试或与管理员联系。