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.
工具与软件:
您好!
我正在 尝试 在 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 关闭连接时??)。
如有任何帮助、将不胜感激。
用于转换证书的 openssl 命令看起来不错。 您还可以双击它们、查看 Windows 是否打开证书 GUI。
至于密钥、您确定它是 pkcs8吗? 密钥 pem 版本的标头是否以 ----开头? 开始使用私钥--- 或 --- 开始使用 RSA 私钥--- ?
标题以 "----开头 开始使用 RSA 私钥--- "。 虽然我已经尝试使用以下命令转换它: OpenSSL rsa -in .private.key -out private-key.der -outform der。
这会为密钥生成证书文件、但尝试打开该文件会出现以下错误:
将 client-cert 转换到.der 还会生成一个证书文件、我可以打开该文件、但显示 windows 无法验证它:
唯一的 无缝转换是根证书、我可以将其从.crt 转换为.der、它在转换后仍然有效。
我正在使用 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、 因此我不认为这是问题所在:
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) /* TLS 1.3 still uses the TLS 1.2 version identifier * for backwards compatibility. */ if( tls_ver == MBEDTLS_SSL_VERSION_TLS1_3 ) tls_ver = MBEDTLS_SSL_VERSION_TLS1_2; #endif /* MBEDTLS_SSL_PROTO_TLS1_3 */ mbedtls_ssl_write_version( ssl->out_hdr + 1, ssl->conf->transport, tls_ver );
当您提到监听器时、您可以共享它吗? 是否是显示握手的无线监听器?
我目前认为使用 TLS1.2不存在问题、但应该知道其失败的原因。
Shlomi
您好!
以下是连接期间收到的其中一个数据包(名为"Server Hello")的日志输出:
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] Ethernet II, Src: 9e:05:d6:60:49:16 (9e:05:d6:60:49:16), Dst: Intel_ba:0f:4a (70:9c:d1:ba:0f:4a) Destination: Intel_ba:0f:4a (70:9c:d1:ba:0f:4a) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: 9e:05:d6:60:49:16 (9e:05:d6:60:49:16) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv4 (0x0800) [Stream index: 1] Internet Protocol Version 4, Src: 18.101.8.10, Dst: 172.20.1.132 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 167 Identification: 0x41bd (16829) 010. .... = Flags: 0x2, Don't fragment 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 243 Protocol: TCP (6) Header Checksum: 0x7d8c [validation disabled] [Header checksum status: Unverified] Source Address: 18.101.8.10 Destination Address: 172.20.1.132 [Stream index: 45] Transmission Control Protocol, Src Port: 443, Dst Port: 65312, Seq: 1, Ack: 303, Len: 127 Source Port: 443 Destination Port: 65312 [Stream index: 39] [Stream Packet Number: 6] [Conversation completeness: Incomplete, DATA (15)] ..0. .... = RST: Absent ...0 .... = FIN: Absent .... 1... = Data: Present .... .1.. = ACK: Present .... ..1. = SYN-ACK: Present .... ...1 = SYN: Present [Completeness Flags: ··DASS] [TCP Segment Len: 127] Sequence Number: 1 (relative sequence number) Sequence Number (raw): 762633888 [Next Sequence Number: 128 (relative sequence number)] Acknowledgment Number: 303 (relative ack number) Acknowledgment number (raw): 795576721 0101 .... = Header Length: 20 bytes (5) Flags: 0x018 (PSH, ACK) 000. .... .... = Reserved: Not set ...0 .... .... = Accurate ECN: Not set .... 0... .... = Congestion Window Reduced: Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 1... = Push: Set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set [TCP Flags: ·······AP···] Window: 7 [Calculated window size: 28672] [Window size scaling factor: 4096] Checksum: 0xa663 [unverified] [Checksum Status: Unverified] Urgent Pointer: 0 [Timestamps] [Time since first frame in this TCP stream: 0.090127000 seconds] [Time since previous frame in this TCP stream: 0.000000000 seconds] [SEQ/ACK analysis] [iRTT: 0.043888000 seconds] [Bytes in flight: 127] [Bytes sent since last PSH flag: 127] TCP payload (127 bytes) Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 122 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 118 Version: TLS 1.2 (0x0303) [Expert Info (Chat/Deprecated): This legacy_version field MUST be ignored. The supported_versions extension is present and MUST be used instead.] [This legacy_version field MUST be ignored. The supported_versions extension is present and MUST be used instead.] [Severity level: Chat] [Group: Deprecated] Random: 4e06fdbfbda6c87d63391479ff8e67c46766c85d11b1ce72c833667357724a03 Session ID Length: 32 Session ID: e148f32d16f530781f1a4795a6760cfcab3fa4edaa9530931808c0294a78871b Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301) Compression Method: null (0) Extensions Length: 46 Extension: supported_versions (len=2) TLS 1.3 Type: supported_versions (43) Length: 2 Supported Version: TLS 1.3 (0x0304) Extension: key_share (len=36) x25519 Type: key_share (51) Length: 36 Key Share extension Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: e73aba7317a30624091106e06fd49a54072f970740ab878b9db5629b2bc1a158 [JA3S Fullstring: 771,4865,43-51] [JA3S: f4febc55ea12b31ae17cfb7e614afda8]
还有其他数据包,如"更改密码规范","你好重试请求",我也收到在过程中,如果它的帮助,我可以发布.
我决定暂时只使用 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