Eclipse Mosquitto 公共测试服务器 test.mosquitto.org 证书更新：CA 与客户端证书轮换的影响及应对指南

• 物联网
• 消息队列
• 后端
• 网络/通信

2020 年 6 月，运行于test.mosquitto.org的公共 MQTT 测试 Broker 完成了 CA 证书与服务端证书的更新，改用强度更高的密钥。本文基于该公告（原公告）展开，梳理这次证书轮换对客户端的影响范围、重新获取 CA 证书与重新生成客户端证书的具体操作路径，并结合本仓库的 TLS 配置文档、示例代码与历史公告，说明公共测试服务器各端口（明文 1883、TLS 8883、双向 TLS 8884、WebSocket 8080）的接入方式。读者读完本文后，能够判断自己的客户端是否受证书轮换影响，并掌握重新信任 CA、重新签发客户端证书以及自建 Broker 时证书相关配置的完整方法。

一、事件背景：公共测试服务器与证书更新公告

test.mosquitto.org是 Mosquitto 项目维护的公共 MQTT 测试服务器，用于帮助开发者在不搭建本地 Broker 的情况下验证客户端实现、测试协议行为以及演练 TLS 配置。仓库根目录的 README.md 明确将其列为公开资源：

There is also a public test server available attest.mosquitto.org

2020 年 6 月 9 日发布的本公告（见 www/posts/2020/06/test-mosquitto-org-cert-updated.md）传达了一个对既有使用者有直接影响的信息：

• 运行于test.mosquitto.org的 Broker 的CA 证书（CA certificate）与服务端证书（server certificate）已更新；
• 新证书使用了强度更高的密钥（a stronger key）；
• 因此，任何下载过旧 CA 证书的客户端都必须重新下载，否则将无法再信任该服务器；
• 使用过客户端证书生成器（client certificate generator）的开发者，其已生成的客户端证书不再被服务器接受，必须重新生成。

这是一次典型的 CA 根证书轮换：一旦信任锚（Trust Anchor）本身发生变更，所有基于旧信任链签发的证书与服务端证书校验都会失效，客户端与服务端两侧都需要同步更新。

二、影响判定：哪些连接会受影响

要判断自己是否受影响，先要明确客户端的连接方式。从 www/posts/2012/06/ssl-support-on-test-server.md 的历史公告可知，测试服务器长期以来提供如下接入模式：

结合本次公告，影响范围可以精确划分：

• 明文 1883 连接：不受影响，无需任何操作；
• 通过 8883 做 TLS 加密连接（仅校验服务器身份）：受影响，必须重新下载 CA 证书，否则客户端在校验服务器证书时找不到对应信任链；
• 通过 8884 做双向 TLS（客户端证书认证）：双重受影响，既要重新下载 CA 证书，也必须重新生成客户端证书——因为旧客户端证书由旧 CA 私钥签发，新服务端证书链不再信任它。

也就是说，这次更新并非简单的服务器证书更换，而是整条信任链的根基发生了变更，属于“换 CA”级别的操作。

三、重新获取 CA 证书与重新生成客户端证书

公告给出了两条明确的行动要求：

1. 重新下载 CA 证书。所有依赖 CA 校验服务器证书的客户端，都需要从服务器提供的路径重新获取新的 CA 证书，并替换本地已保存的旧文件。
2. 重新生成客户端证书。使用过客户端证书生成器的用户，需要重新走一遍生成流程，用生成器产出由新 CA 签发的新证书，替换旧的客户端证书/私钥对。

需要强调的是：重新下载 ≠ 增量更新。旧 CA 证书与新 CA 证书是两套不同的信任锚，本地证书存储中应当以新证书替换旧证书，而不是保留两份混用，否则部分工具在校验时可能因证书链不一致而报错。

四、客户端接入方式的源码佐证：TLS 配置与示例

本仓库的示例代码长期以test.mosquitto.org作为演示目标，可以直接作为重新接入时的参照。

明文接入（1883 / WebSocket 8080）

• examples/publish/basic-1.c 中通过mosquitto_connect(mosq, "test.mosquitto.org", 1883, 60)连接明文端口；
• examples/publish/basic-websockets-1.c 则演示连接 WebSocket 端口 8080。

这两种方式不涉及证书，证书轮换对它们没有影响。

TLS 接入（8883 / 8884）

客户端库提供了mosquitto_tls_set()接口用于配置证书，其原型定义在 include/mosquitto/libmosquitto_tls.h：

libmosq_EXPORT int mosquitto_tls_set(struct mosquitto *mosq, const char *cafile, const char *capath, const char *certfile, const char *keyfile, int (*pw_callback)(char *buf, int size, int rwflag, void *userdata));

参数含义与本次证书轮换的对应关系：

• cafile：PEM 编码的 CA 证书文件路径——8883/8884 连接都必须传入重新下载的新 CA 证书；
• certfile/keyfile：客户端证书与私钥——仅 8884 双向认证需要，且必须使用重新生成的证书；
• pw_callback：私钥口令回调。

调用必须发生在mosquitto_connect()之前（该头文件注释明确要求 “Must be called before mosquitto_connect”）。此外还有配套的mosquitto_tls_insecure_set()（include/mosquitto/libmosquitto_tls.h）可关闭服务器证书校验——仅建议用于调试，生产环境不应使用。

命令行的mosquitto_pub/mosquitto_sub工具同样支持--cafile、--cert、--key选项，可参考 man/mosquitto_pub.1.xml 与 man/mosquitto_sub.1.xml 的对应说明。

五、Broker 侧证书配置的底层原理（自建服务器参考）

公共测试服务器的证书轮换对自建 Broker 同样有参考价值：如果自己部署 Mosquitto 并维护 CA，轮换时涉及的配置项与本次事件完全一致。相关参数集中在 man/mosquitto.conf.5.xml 的 listener 配置节：

从源码结构看，CA 证书轮换对自建 Broker 的直接影响集中在cafile/capath：替换信任锚后，所有由旧 CA 签发的客户端证书会立刻失效（除非同时配置了crlfile或调整disable_client_cert_date_checks），这与公共测试服务器上“8884 客户端必须重新生成证书”的现象完全一致。文档还提到，certfile与keyfile指向的服务器证书/私钥会在 Broker 收到 SIGHUP 信号时重新加载（man/mosquitto.conf.5.xml、man/mosquitto.conf.5.xml），这是“无需停机即可滚动换证书”的运维手段；但本次是 CA 更换，客户端侧同样必须更新信任锚，单靠服务端热加载无法解决问题。

仓库的测试环境也保留了完整的 CA/证书体系可作参考：例如 test/ssl/all-ca.crt 包含 Root CA 与 Signing CA 两级证书链，test/ssl 目录下还有配套的服务器证书、客户端证书与openssl.cnf配置，展示了 Mosquitto 官方测试中如何组织 CA、签发证书与验证双向 TLS。

六、验证与收尾：如何确认自己已跟上更新

完成重新下载/重新生成后，建议按以下步骤确认连接恢复正常：

1. 用新 CA 证书替换本地旧文件，确认路径与mosquitto_tls_set()（或命令行--cafile）中的配置一致；
2. 对 8884 双向认证，确认certfile/keyfile指向的是重新生成的客户端证书，且私钥与证书匹配；
3. 分别尝试连接 1883（明文）、8883（TLS）、8884（mTLS），观察 TLS 握手是否报证书链错误；
4. 若需要同时测试 IPv6 路径，可使用test6.mosquitto.org——该域名是同一服务器仅带 AAAA 记录的 DNS 入口，可确保流量真正走 IPv6（见 www/posts/2016/01/test6-mosquitto-org.md）。

本次公告以“CA 证书更新”这一看似简单的运维动作，实际上演示了一个完整的信任链轮换流程：服务端更换 CA 与服务器证书后，客户端必须同步更新信任锚，双向认证场景下还必须重新签发客户端证书。理解这一流程，对使用公共测试服务器进行 TLS 演练，以及自建 Broker 时规划证书生命周期管理，都具有直接的实践价值。

• 物联网
• 消息队列
• 后端
• 网络/通信