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 关闭连接时??)。
如有任何帮助、将不胜感激。
您好!
我会坚持使用 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、 因此我不认为这是问题所在:
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