基于FreeRTOS+Mbed-TLS的设备无法连接AWS Device Advisor求助

我有一台运行FreeRTOS和Mbed-TLS的自定义设备，该设备可正常连接AWS IoT Core生产端点，且能自由进行Pub/Sub操作；但当尝试通过AWS Device Advisor提供的端点执行MQTT Connect测试用例时，无法完成TLS握手。日志中仅有两条记录：客户端发送Client Hello，随后服务器返回close-notify告警。我使用自行编写的C#测试应用连接同一端点可正常工作，两者采用相同方法，仅设备不同。我已解码设备发送的Client Hello，未发现明显异常。

设备TLS交互日志 #

客户端发送的Client Hello #

TLS Record Sender CLIENT ContentType HANDSHAKE Length 149 Timestamp 2022-12-19T18:08:58Z
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 16 03 03 00 90 01 00 00 8c 03 03 76 9d 1d 5a 67 |...........v..Zg|
|00000010| e2 db 3f 45 13 41 2d 7e 28 77 00 87 e6 35 0e 32 |..?E.A-~(w...5.2|
|00000020| c2 24 bd 23 ee 69 72 77 f3 e1 69 00 00 04 c0 2b |.$.#.irw..i....+|
|00000030| 00 ff 01 00 00 5f 00 00 00 3d 00 3b 00 00 38 74 |....._...=.;..8t|
|00000040| 33 6e 78 35 69 7a 39 76 37 73 69 6a 73 2e 64 65 |3nx5iz9v7sijs.de|
|00000050| 76 69 63 65 61 64 76 69 73 6f 72 2e 69 6f 74 2e |viceadvisor.iot.|
|00000060| 75 73 2d 65 61 73 74 2d 31 2e 61 6d 61 7a 6f 6e |us-east-1.amazon|
|00000070| 61 77 73 2e 63 6f 6d 00 0d 00 06 00 04 04 03 04 |aws.com.........|
|00000080| 01 00 0a 00 0a 00 08 00 1d 00 17 00 18 00 19 00 |................|
|00000090| 0b 00 02 01 00                                  |.....           |
+--------+-------------------------------------------------+----------------+

服务器返回的close-notify告警 #

TLS Record Sender SERVER ContentType ALERT Length 7 Timestamp 2022-12-19T18:08:58Z
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 15 03 03 00 02 01 00                            |.......         |
+--------+-------------------------------------------------+----------------+

解码后的Client Hello详情 #

16 03 03 00 a4 
Record Header
    16 - type is 0x16 (handshake record)
    03 03 - protocol version is 3.3 (also known as TLS 1.2)
    00 90 - 0x90 bytes of handshake message follows 

01 00 00 a0 
    01 - handshake message type 0x01 (client hello)
    00 00 8c - 0x8c  bytes of client hello follows 
03 03 
    The protocol version of "3,3" (meaning TLS 1.2) is given. 

80 e3 df 37 83 02 08 84 9d b0 6f e8 86 e9 e0 12 5e 77 f9 97 c6 af 62 cf 43 c6 40 63 c0 77 3a 82 
    The client provides 32 bytes of random data.

00 
    Session id
    00 - length of zero (no session id is provided) 

00 04
    Cipher Suites - 4 bytes of cipher suits follow
    c0 2b 
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    00 ff 
        TLS_EMPTY_RENEGOTIATION_INFO_SCSV

01 00 
    01 - 0x1 (1) bytes of compression methods follows
    00 - assigned value for no compression 

00 73 
    00 73 - the extensions will take 0x73 (115) bytes of data 

00 00 
    Server Name Extension
    00 47 
        71 Bytes Follow
    00 45
        69 Bytes of list entry
    00 
        List entry type is 0x00 "DNS Hostname"
    00 42 
        66 Bytes of host name follow
    74 34 31 31 62 39 36 32 35 37 74 33 6e 78 35 69 7a 39 76 37 73 69 6a 73 2e 64 65 76 69 63 6561 64 76 69 73 6f 72 2e 69 6f 74 2e 75 73 2d 65 61 73 74 2d 31 2e 61 6d 61 7a 6f 6e 61 77 73 2e 63 6f 6d 
        Hostname - "t411b96257t3nx5iz9v7sijs.deviceadvisor.iot.us-east-1.amazonaws.com"

00 0d
    Signature Algorithms
    00 06 
        6 Bytes follow
    00 04 
        4 Bytes follow
    04 03 
        ECDSA/SECP256r1/SHA256 
    04 01 
        RSA/PKCS1/SHA256 

00 0a 
    Supported Groups
    00 0a
        10 bytes of "supported groups" extension data follows 
    00 08 
        8 Bytes of data are in the curves list
    00 1d 
        x25519
    00 17 
        secp256r1
    00 18 
        secp384r1
    00 19 
        secp521r1

00 0b 
    EC Point Formats
    00 02 
        2 bytes of EC points format data follows
    01 
        1 bytes of data are in the list
    00 
        Assigned value for uncompressed formo

已尝试的排查手段 #

• 添加ALPN并尝试8883和443端口，无变化
• 使用其他测试应用可正常连接，但日志未显示设备间差异
• 设备可正常连接常规端点并正常运行

排查建议 #

1. 验证证书适配性 #

AWS Device Advisor对证书的校验可能比生产端点更严格，确认设备使用的证书的SAN字段是否包含当前Device Advisor测试端点的完整域名，同时检查该证书是否被添加到AWS IoT的允许列表中，且绑定的Thing与测试用例匹配。

2. 对比C#应用的Client Hello细节 #

将设备发送的Client Hello字节流与C#应用的做逐字节对比，重点关注：

• TLS扩展的顺序（部分服务器对扩展顺序敏感）
• 密码套件的排序（Device Advisor可能优先选择C#应用中的套件顺序）
• 是否存在设备端缺失的扩展（比如extended_master_secret、status_request等）

3. 开启Mbed-TLS详细调试 #

启用Mbed-TLS的MBEDTLS_DEBUG_C编译宏，获取更底层的TLS握手日志，比如证书链加载、密钥交换初始化、服务器返回的隐性错误信息，这些细节可能解释close-notify的触发原因。

4. 检查设备时间同步 #

TLS握手依赖准确的系统时间来校验证书有效期，确认设备是否通过NTP同步了时间，时间偏差超过证书有效期范围会导致服务器直接关闭连接。

5. 排查网络路径差异 #

虽然设备能连接生产端点，但Device Advisor端点可能有不同的网络策略：

• 检查设备是否能正常ping通Device Advisor端点
• 确认是否存在防火墙或代理拦截了TLS报文
• 验证MTU设置是否合理，避免Client Hello报文被异常分片

6. 确认Mbed-TLS版本兼容性 #

检查当前使用的Mbed-TLS版本是否存在已知的TLS握手兼容性问题，尝试升级到AWS推荐的Mbed-TLS版本（与FreeRTOS适配的稳定版本）。

内容的提问来源于stack exchange，提问作者Aaron Decker