企业官网建设流程全解析

搞嵌入式的人应该都有过这种体会：当手里那块STM32F103终于把MQTT跑通了，板子上的温湿度数据能发到服务器，心里刚松一口气，紧接着就会收到灵魂拷问——“你这数据是明文传输的吧？被截了怎么办？” 于是，给MQTTS（MQTT over TLS）加密就成了一道躲不过去的坎。但一提起TLS，很多人的第一反应是这玩意太重了，Cortex-M3这颗老芯片跑得动吗？Flash和RAM够用吗？别慌，这篇就来手把手讲清楚，怎么在STM32F103上把mbedtls 2.24.0跑起来，给MQTT通道套上一层加密壳。

mbedtls（前身是 PolarSSL）算是嵌入式领域做SSL/TLS的事实标准，专为资源受限设备设计，体积小、可裁剪、依赖少。它不但能提供TLS握手、加密传输，还能顺便搞定证书解析、哈希、随机数生成等一堆底层操作。对于STM32F103这种Flash通常在64KB到512KB之间、RAM只有20KB到64KB的单片机来说，只要裁剪得当，完全有戏。本文适合手里有STM32F103开发板、已经跑通基础MQTT裸传、正准备上TLS的工程师或爱好者，我尽量把从零移植到握手成功的完整过程和踩过的坑都写出来，让你少走弯路。

1. 整体设计与思路拆解

1.1 为什么MQTT裸传不够用，TLS到底在保护什么

先把需求看清楚。MQTT协议本身是一个应用层协议，它的设计重心是轻量、发布订阅模型，而不是安全。默认情况下，设备发给Broker的数据是明文的，包括你的主题、Payload，甚至ClientID和用户名密码。这在局域网玩一玩问题不大，可一旦设备要上公网，或者接入云平台（比如各种物联网云），数据在链路上就可能被监听、篡改甚至被重放攻击。

你可能觉得，一个温湿度数据被截了有什么大不了的？但换一个场景就明白了：如果你的设备控制的是一个电动阀门、一个门锁、一个逆变器，明文数据一旦被恶意篡改，后果就不是“丢一个温度值”这么简单了。TLS在整个通信模型中处于TCP和MQTT之间，它做的事情可以概括为三件：

• 身份认证：客户端验证服务器的证书，确保连的是真服务器而不是伪装的钓鱼节点。
• 加密传输：握手协商出会话密钥后，所有应用层数据都以密文在网络上传输。
• 完整性校验：每条记录都有MAC校验，数据在传输过程中被篡改，接收端立刻就能发现。

所以，在STM32F103这种MCU上跑MQTT，TLS不是锦上添花，而是上生产环境之前的必要步骤。尤其现在很多云平台强制要求设备和云端之间走TLS，不支持就接入不了。

1.2 为什么选mbedtls 2.24.0，而不是别的方案

在MCU上做SSL/TLS，可选方案其实不多。OpenSSL太大了，动辄几MB的Flash占用，在STM32F103上基本可以洗洗睡。wolfSSL（以前叫CyaSSL）也支持嵌入式，性能也不错，但它的License和API风格和mbedtls不太一样。真正让我推荐mbedtls的原因有三点：

• 体积可裁剪：mbedtls的模块化做得非常好，你可以通过配置头文件裁掉用不到的算法。后面我会演示如何配置，最小化的TLS客户端可以做到只占几十KB Flash的程度，这对F103来说完全可接受。
• ARM生态适配成熟：mbedtls本身就是ARM主导的项目，对Cortex-M系列的支持很完善，网上资料也多，遇到问题能搜到一堆解决方案。
• 2.24.0版本的稳定性：2.24.0是mbedtls 2.x系列里的一个维护版本，修复了之前不少安全漏洞，API又没像3.x那样大规模变动。如果你参考的是旧教程，很多函数名和配置项在2.24.0里仍然有效，踩坑概率低。

有人可能问，为什么不直接用2.28 LTS长期支持版？从功能和安全修复角度看，2.28确实更好，但很多教程、云平台SDK、甚至一些Broker配套的示例代码用的还是2.24.0时代的API。为了兼容性和改造成本考虑，先把2.24.0跑通，等整个链路稳定了，再升级版本也来得及。这也算是嵌入式开发的常态：先求跑通，再求版本追新。

1.3 系统整体架构与资源预算

我们要做的事情并不是“从零到一实现TLS协议”，而是把mbedtls当成一个库，集成进现有的STM32工程里，然后在MQTT连接之前先建立TLS握手，把原本直接往TCP Socket里写数据的操作，改为往TLS连接里写数据。整体通信链路是这样的：

STM32F103（mbedtls + MQTT客户端） │ TLS加密 ▼ TCP/IP协议栈（这里我用的是AT指令接ESP8266，后面会细说） │ ▼ Wi-Fi/以太网 │ ▼ MQTT Broker（如Mosquitto、EMQX）

在动手之前，先算一笔资源账。我用的板子是STM32F103ZET6，Flash 512KB，RAM 64KB。mbedtls全功能编译下来占用相当惊人，但裁剪之后完全不一样。我最开始的裁剪目标是：TLS 1.2客户端、只支持一种椭圆曲线、只保留AES-GCM和SHA-256、关闭所有调试输出，这样编译出来大概只占80~100KB Flash，运行时RAM占用大约10~15KB，对F103来说还能接受。

当然，如果你的Flash只有64KB，也不是完全没救，只是需要更狠地裁剪，比如把AES-CBC也去掉、把不需要的曲线全删掉，甚至可以考虑TLS-PSK模式（预共享密钥模式，不需要证书和公钥运算，体积更小）。不过本文先讲最常用的证书认证方式（TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256），这种方式用在小资源MCU上性价比最高。

2. 核心细节解析与实操要点

2.1 mbedtls源码结构与必须了解的文件

从mbedtls官网下载2.24.0源码包之后，整个目录结构看着挺吓人，但实际需要关注的其实就两块：library/和include/。library/目录下是所有C源文件，include/mbedtls/目录下是头文件。移植时不需要改这些代码，你只需要做两件事：

• 把你的工程编译器头文件搜索路径指向include/目录。
• 在编译时只选择你要用到的源文件参与编译，没用的不编译，减小Flash占用。

这里有个容易忽视的地方：默认的配置头文件叫mbedtls_config.h（在2.24.0里，旧版本叫config.h）。这个文件里用大量的#define和#undef控制着哪些模块启用、哪些算法开启。我强烈建议你不要直接改这个原厂头文件，而是自己在工程目录下复制一份，取个名字比如my_mbedtls_config.h，然后在编译器全局宏里定义MBEDTLS_CONFIG_FILE="my_mbedtls_config.h"。这样一来，你的裁剪配置全部集中在一个你自己的文件里，既不会被mbedtls源码升级覆盖，也方便后续维护和记录。

为什么这个文件这么关键？因为mbedtls的裁剪粒度就是“宏开关”。比如你不需要HTTPS那套，就可以去掉某些文件；你只跑TLS客户端，不需要服务端，就可以定义MBEDTLS_SSL_PROTO_TLS1_2之类的选项。这些开关直接影响最终的代码体积和RAM占用，所以移植的第一步就是理清这个文件。

2.2 时间函数：TLS握手绕不开的坑

TLS里有一个环节叫“证书有效期校验”。服务器给你发来一个证书，客户端要检查当前时间是否在证书的 valid_from 和 valid_to 之间，否则直接拒绝连接。这里的问题就来了：STM32F103上没有操作系统，也没有默认的“当前时间”概念。mbedtls提供了一个回调机制：mbedtls_ssl_set_timer_cb()或者通过MBEDTLS_PLATFORM_TIME_MACRO来提供时间函数。

我最开始移植时，没有认真处理这个函数，直接让时间函数返回0，结果握手永远失败，报错内容是指证书时间无效。后来查了资料才明白，TLS握手流程里有个步骤就是校验时间，如果返回的时间早于证书生效时间（比如很多证书的生效时间是最近几年），校验就会直接失败。

解决方案有好几种，我选的是最简单且通用的一种：定义MBEDTLS_PLATFORM_TIME_MACRO为我们自己的时间获取函数。这需要板上至少有一个能维护“Unix时间戳”的机制，也就是从1970年1月1日到现在经过的秒数。

uint32_t my_get_timestamp(void) { // 这里用RTC或者NTP同步后的全局变量维护 return g_current_timestamp; }

如果你的设备已经接了网络，那么可以在联网之后先通过NTP获取一次真实时间，存到RTC或全局变量里，之后每次TLS握手都从这个时间源读取。如果只是局域网测试，连不上NTP，那也有一个取巧的办法：直接把编译日期__DATE__转成时间戳，至少能让证书校验通过。但注意生产环境一定要用真实时间源，否则证书失效或未生效的边界情况会让你排查到怀疑人生。

2.3 随机数来源：别小看这个熵源

TLS握手里最核心的环节之一是生成随机数，用于生成会话密钥、抵御重放攻击。mbedtls自带的熵源模块可以从多个来源收集随机性。PC上能直接读/dev/urandom，但STM32F103上没有这种现成的东西，因此必须自己提供熵源。

对STM32F103来说，芯片内部没有硬件随机数发生器（HWRNG）——F4系列才开始有RNG外设。所以常规方案有以下几种：

• ADC噪声采样：把某个ADC引脚悬空，读取其转换值的低几位作为随机源。噪声虽然不大，但作为熵源之一够用了。这是最容易实现的方案，我试过，效果不错。
• 片内温度传感器或VREFINT：STM32F103内部自带温度传感器和内部参考电压，多读几次之后取低有效位，能提取出一些随机成分。
• 外部模块辅助：如果你外挂的Wi-Fi模块（比如ESP8266）有随机数读取接口，也能作为熵源。

我当时用的是ADC噪声法，代码大致长这样：

static int my_entropy_poll(void *data, unsigned char *output, size_t len, size_t *olen) { uint32_t acc = 0; for (int i = 0; i < 8; i++) { acc = (acc << 4) | (adc_read() & 0x0F); // 取ADC低4位 } memcpy(output, &acc, 4); *olen = 4; return 0; }

要注意，mbedtls的熵源收集是会多次调用你的回调函数的，每次收集一些后混合进熵池。你只需要保证回调能持续提供尽量随机的字节，不必强求一次性给满。还有个常见坑：如果回调传回的字节数太少或者全为同一个值，mbedtls的熵池会告警，个别版本会直接返回熵不足错误，这时需要多写几个不同的熵源来交叉混合。

2.4 证书处理：怎么把PEM证书塞进单片机

TLS证书通常有两种格式：PEM（Base64文本）和DER（二进制）。PC上的库可以直接读文件，但MCU上哪有文件系统？所以标准做法是把证书预处理成C数组，编译进固件里。

步骤很简单：先用openssl命令把PEM证书转成C数组，或者用工具xxd -i也可以。比如：

openssl s_client -connect your.broker.com:8883 -showcerts </dev/null 2>/dev/null | sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' > broker.pem xxd -i broker.pem | head -50

把输出的字节数组保存成一个.c文件，然后在代码里声明为extern const unsigned char broker_cert[];和extern const unsigned int broker_cert_len;。需要注意，mbedtls的mbedtls_ssl_conf_ca_chain()接收的证书链，如果是自签名证书或者测试证书，要确保整个证书链完整，否则验证会失败。

我当时为了省事，直接用了云平台的“测试证书”，而且把证书放到Broker的mosquitto -c配置里，设备侧只配置根CA证书。这样写出来的调用代码大概是这样：

unsigned char ca_cert[] = "..."; // PEM格式转成的字节数组 mbedtls_x509_crt_init(&cacert); mbedtls_x509_crt_parse(&cacert, ca_cert, sizeof(ca_cert)); mbedtls_ssl_conf_ca_chain(&ssl_conf, &cacert, NULL);

这里有一个特别值得说的细节：mbedtls_ssl_conf_ca_chain()第二个参数传NULL，表示不需要客户端证书（单向认证）。如果你的Broker要求双向认证 —— 即除了验证服务器，还要验证客户端证书 —— 那你需要额外调用mbedtls_ssl_conf_own_cert()把客户端证书和私钥也配置进去。大多数商业物联网平台为了简化，采用单向认证就够了，但从安全角度说，双向认证能有效防止非法设备接入，有条件的话还是建议上。

3. 实操过程与核心环节实现

3.1 初始化CubeMX工程与串口调试通道

这一步不是必须的，但对我调试帮助很大。我在CubeMX里开了两个串口：USART1和USART3，USART1专门用于TLS和MQTT的日志输出，USART3留作AT指令模块通信。这里顺便说一下关于串口1和串口3的使用差异，很多新手在这里栽过跟头：USART1默认挂在APB2总线上，时钟可以是72MHz；USART3挂在APB1上，最高36MHz。虽然波特率都够用，但如果你把两个串口的波特率、中断优先级都配置错了，或者把TX/RX引脚复用搞混，就会遇到“为什么串口1能发，串口3不能发”这种诡异问题。我的建议是：调试日志统一走USART1，外设通信走USART3，并且把中断优先级错开，避免同时进中断时数据错乱。

另外，如果你打算用ESP8266这类Wi-Fi模组和F103通信，注意电平匹配。F103是3.3V的，ESP8266也是3.3V，但如果你的模组是5V版本或者模块上自带的LDO压差大，就得确认好逻辑电平。

工程创建完之后，把mbedtls的include/路径添加进编译器头文件搜索目录，再把library/下需要的源文件加入工程。为了省心，我当时直接把所有.c文件全加进去了，编译一次看Flash占用，再做裁剪减法。全量编译时Flash占用直接破300KB，RAM占用也高得离谱，经过裁剪后才降到理想范围。所以如果你也想全量加，心里要有数。

3.2 适配底层网络接口：从TCP Socket到SSL_read/SSL_write

mbedtls本身不关心数据是通过Wi-Fi、以太网还是GPRS出去的，它只要求你提供两个回调：发送数据和接收数据。在典型场景里，这就是ESP8266的AT指令Socket收发函数。

比较坑的一点是，mbedtls在使用这些回调时会要求“非阻塞模式下返回特定错误码”或者“阻塞模式下返回实际收发字节数”。我们用的是AT指令这种半阻塞模式，所以要做一下适配。以下是我的伪代码：

int my_tls_send(void *ctx, const unsigned char *buf, size_t len) { // 把buf的数据通过ESP8266的TCP连接发送出去 esp8266_send((char*)buf, len); return len; } int my_tls_recv(void *ctx, unsigned char *buf, size_t len) { // 等待并接收数据，返回接收到的字节数 return esp8266_recv((char*)buf, len, timeout_ms); } // 配置给mbedtls mbedtls_ssl_set_bio(&ssl, NULL, my_tls_send, my_tls_recv, NULL);

特别提醒：mbedtls_ssl_set_bio()的最后一个参数传NULL，表示阻塞模式。如果传了my_tls_recv_timeout函数，则是超时模式，mbedtls会在超时时间内等待数据。AT指令模块通常有串口缓冲，所以阻塞模式也可以工作，但如果你希望握手失败时能快速退出，建议实现超时回调机制，否则死等串口数据会让整个系统卡死。

3.3 核心流程：mbedtls初始化、握手、读写

到这里，最激动人心的部分来了：把mbedtls和网络层接起来，跑通TLS握手。初始化流程我习惯按下面这个清单走：

第一步，初始化各组件：

mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; mbedtls_ssl_context ssl; mbedtls_ssl_config ssl_conf; mbedtls_x509_crt cacert; mbedtls_entropy_init(&entropy); mbedtls_ctr_drbg_init(&ctr_drbg); mbedtls_ssl_init(&ssl); mbedtls_ssl_config_init(&ssl_conf); mbedtls_x509_crt_init(&cacert);

第二步，熵源和随机数生成器：

mbedtls_entropy_add_source(&entropy, my_entropy_poll, NULL, 128, MBEDTLS_ENTROPY_SOURCE_STRONG); mbedtls_ctr_drbg_seed(&ctr_drbg, mbedtls_entropy_func, &entropy, NULL, 0);

my_entropy_poll就是前面写的ADC噪声回调。这里要注意，mbedtls要求初始化熵源时至少要加一个自带的mbedtls_entropy_source，然后是自定义的，最后调mbedtls_entropy_self_test检查一遍熵池状态。如果在mbedtls_ctr_drbg_seed这一步报错，多半是熵池不够随机，或者自定义回调的olen返回异常。

第三步，加载CA证书：

int ret = mbedtls_x509_crt_parse(&cacert, (const unsigned char*)ca_cert, sizeof(ca_cert)); if (ret != 0) { printf("parse cert failed: -0x%04X\n", -ret); return ret; }

返回的错误码需要转换成十六进制的负数查看，比如-0x2700表示证书解析的某种错误。网上有人把ret直接打印出来，结果看到一个很大的正数，怎么也对不上错误表，就是因为mbedtls的错误码是以负数存储的。

第四步，配置TLS参数：

mbedtls_ssl_config_defaults(&ssl_conf, MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT); mbedtls_ssl_conf_authmode(&ssl_conf, MBEDTLS_SSL_VERIFY_REQUIRED); mbedtls_ssl_conf_ca_chain(&ssl_conf, &cacert, NULL); mbedtls_ssl_conf_rng(&ssl_conf, mbedtls_ctr_drbg_random, &ctr_drbg); mbedtls_ssl_conf_read_timeout(&ssl_conf, 10000); // 10秒超时 mbedtls_ssl_setup(&ssl, &ssl_conf);

这里可以聊聊为什么authmode要设成MBEDTLS_SSL_VERIFY_REQUIRED而不是OPTIONAL。在开发阶段，有些人为了省去证书校验的麻烦，直接用VERIFY_NONE，但这样等于放弃了TLS的身份认证，防不了中间人攻击，加密也白加密了。生产环境必须VERIFY_REQUIRED，而且还要确保CA证书链正确。

第五步，TLS握手：

mbedtls_ssl_set_hostname(&ssl, "your.broker.com"); // 用于SNI和证书校验 // 先建立TCP连接（ESP8266部分省略） while ((ret = mbedtls_ssl_handshake(&ssl)) != 0) { if (ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE) { printf("handshake failed: -0x%04X\n", -ret); break; } }

握手阶段最常见的报错是MBEDTLS_ERR_X509_CERT_VERIFY_FAILED，也就是证书校验失败。排查方向就在证书和域名上：证书有没有加载对？是不是自签名的但没加到信任列表？域名和你访问的IP对不对得上？如果都不行，可以开启MBEDTLS_DEBUG_C并注册调试回调，让mbedtls把详细失败原因打印出来。这是我说了无数次的调试技巧：在移植阶段，务必打开调试输出，否则TLS握手这种协议栈黑盒行为，你会排查到崩溃。

第六步，握手之后的读写：

握手成功后，原来你调用的esp8266_send()和esp8266_recv()要换成mbedtls_ssl_write()和mbedtls_ssl_read()。对于MQTT协议来说，这就意味着你需要把MQTT的报文打包函数（比如MQTTSerialize_*系列）的输出直接丢给mbedtls_ssl_write，把收到的密文喂给mbedtls_ssl_read后再走MQTT的解包流程。

int send_mqtt_over_tls(mqtt_packet_t *packet) { unsigned char buf[512]; int len = mqtt_packet_serialize(packet, buf, sizeof(buf)); return mbedtls_ssl_write(&ssl, buf, len); }

这里特别注意一点：TLS记录层对单次写入长度有限制，一般不能超过16KB，但MQTT报文也不会那么大。真正要紧的是，mbedtls_ssl_write在阻塞模式下返回的字节数不一定等于你传入的len，它可能只写完一部分。稳妥写法是用循环把剩余数据写完，或者干脆确保单次调用前len不超过底层TCP发送缓冲。

3.4 mbedtls_config.h裁剪实例：从300KB到100KB

我在自己的工程中用的是一份精简过的配置，核心动作就是“删宏”。几个关键开关列在下面：

• 保持MBEDTLS_SSL_PROTO_TLS1_2开启，去掉MBEDTLS_SSL_PROTO_TLS1和MBEDTLS_SSL_PROTO_TLS1_1，老版本协议用不上。
• 只保留需要的椭圆曲线，比如MBEDTLS_ECP_DP_SECP256R1_ENABLED，把其它曲线全部关掉。
• 哈希算法只留MBEDTLS_SHA256_C，连SHA1都关掉（证书解析有些地方可能间接需要SHA1，实测可以关，节省Flash很可观）。
• 对称算法用MBEDTLS_AES_C+MBEDTLS_GCM_C，如果服务端恰好支持AES_128_GCM_SHA256，这套组合最省资源。
• 关闭MBEDTLS_DEBUG_C和MBEDTLS_SELF_TEST，开发阶段可以开，发布前必须关。
• 关闭不需要的MBEDTLS_SSL_DTLS_*系列以及服务端相关选项。

裁剪没有标准答案，核心思路是：先全量编译跑通，再根据自己需要的密码套件往回删。我的完整裁剪配置没法在这里贴全，因为每个人的应用不同、服务端强制的密码套件也不同，但我给你一个检查思路：在TLS握手中，服务端和客户端会协商出一个密码套件，你配置里开启的算法必须是这个套件所需算法的超集。如果只留了AES-GCM，而服务端非要AES-CBC，那握手一样会挂。

4. 常见问题与排查技巧实录

4.1 编译期报错：头文件找不到、宏冲突

mbedtls的源代码里有很多#include "mbedtls/xxx.h"的写法，所以编译器搜索路径必须包含include/目录，并且在设置里确认宏MBEDTLS_CONFIG_FILE被正确设置。我自己踩过的一个坑是：不同编译器对#include "my_config.h"的查找路径不一样，有的编译器会先找当前文件所在目录，导致它找不到我放在工程根目录下的自定义配置文件。后来我直接用了绝对路径或者把my_config.h和mbedtls_config.h放在同一个目录下，才彻底解决。

还有一个经典冲突：mbedtls自带的mbedtls/entropy.h和你的工程里某个外设驱动同名头文件撞了。检查一下，如果有，把mbedtls的include路径尽量往后放，或者给自定义文件改名。

4.2 mbedtls_ssl_handshake 死循环

这是阻塞模式下最糟心的现象：握手函数一直卡住，不报错也不返回。原因基本是两个：一个是网络层没有数据过来，另一个是你的recv回调阻塞了。排查方法很简单：在my_tls_recv里面加调试打印，看看有没有收到服务器发来的TLS记录。如果一直收不到，先检查TCP连接是否真的建立成功，再排查Broker的8883端口是否监听。

某种程度上，这个问题跟AT指令模组的AT指令阻塞时长也有关系。AT指令通常有响应超时，比如AT+CIPSTART可能等待5秒才返回，如果mbedtls回调期间AT指令还没执行完，就会造成死等。解决办法是把网络状态机做成分步处理，让recv回调在“还没收到数据”时返回MBEDTLS_ERR_SSL_WANT_READ，这样mbedtls会把控制权交还给主循环，而不是死等数据。

4.3 证书校验失败：时间、域名、根证书三座大山

我遇到过的证书校验失败，90%都能归到这三类：

1. 时间不对。F103的RTC没设或者断电清零了，导致证书校验认为证书已过期或未生效。去检测一下get_time()返回值是不是一个合理的Unix时间戳。
2. 主机名不匹配。mbedtls_ssl_set_hostname()里填的域名必须和证书里的CN或SAN匹配。如果你是通过IP访问Broker的，而证书只签了域名，那也会失败。
3. 根证书缺失或错误。有些Broker返回的证书链不止一层，你可能需要把整个证书链都加载进去，而仅仅加载根CA是不够的。

排查时可以开MBEDTLS_DEBUG_C，把调试级别调到最大。mbedtls会把每一步验证结果都打出来，非常有用。但要记住，这宏在最终版本里一定要去掉，否则不光Flash占用大，调试信息还可能泄漏敏感信息。

4.4 RAM 不足：heap 与 mbedtls 的内存占用

TLS握手过程需要动态申请内存，mbedtls从calloc/free获取内存。在STM32上，你首先要确认启动文件里的堆大小是否够用。我建议把堆从默认的0x400加到0x2000甚至更大，不然握手到一半突然分配不出内存，报错收场。

如果堆加大了还不够，那就要考虑裁剪密码套件、减小证书解析缓冲区、或者把TLS记录缓冲区改小。mbedtls在2.x版本里有个MBEDTLS_SSL_MAX_CONTENT_LEN宏，默认可能是16KB，如果RAM吃紧，可以改小到4096甚至2048。但要注意，如果MQTT包体较大，改小了会导致mbedtls_ssl_write报MBEDTLS_ERR_SSL_BUFFER_TOO_SMALL。

4.5 常见问题速查表

写在最后：一点实战后的感想

把mbedtls跑在STM32F103上，难点不在代码本身，而在三个细节：时钟、随机数、证书。这三个任一环节出了问题，TLS握手都会以各种面色狰狞的错误码回报你。我自己调试的第一个TLS握手，卡了整整两天，最后发现居然是RTC没初始化，时间返回0导致证书校验直接失败——从那以后我给自己定了个规矩：凡是涉及TLS的板子，第一步永远是确认时间函数返回的时间戳合理。

还有一点想说的是，如果条件允许，可以先用STM32串口连接PC上的openssl s_server或mosquitto做本地调试，把TLS的握手过程先用PC端验证一遍，再把同样的证书和逻辑搬到单片机上。这样能极大缩短定位问题的时间，也方便你观察不同密码套件的表现。等你把整个流程跑通了，再看那些云平台的连接SDK，就会发现它们虽然封装了一层又一层，但底层原理跟你今天亲手搭起来的这套，完全是一回事。

最后再分享一个小技巧：在STM32上跑MQTTS，千万别上来就搞双向认证。先把单向TLS打通，确认Wi-Fi模块、网络链路、Broker证书全都正常，再考虑设备证书和私钥管理。一步一步来，这个坑就填得轻松很多。