Mosquitto_sub指定CA证书后报协议错误，请求排查原因

核心问题定位 #

从Broker日志的tlsv1 alert unknown ca错误来看，本质是客户端（mosquitto_sub）提交的CA证书无法被服务端的OpenSSL库识别，导致TLS握手失败。以下是具体排查方向：

可能原因及解决方法 #

• 证书路径错误
  Windows下执行mosquitto_sub时，如果只写证书文件名CACert.crt，程序会从当前命令行的工作目录找文件，而这个目录通常和Broker运行时的证书目录不一样，等于没读到正确的CA文件。
  解决：改用证书的绝对路径，比如：

  mosquitto_sub -h broker -t test/topic -p 8883 --cafile "C:\mosquitto\certs\CACert.crt"
  

• 证书格式损坏
  就算证书内容一致，要是文件存成了UTF-8带BOM格式，或者换行符被替换成了空格，OpenSSL就解析不了。
  解决：用Notepad++打开证书，选择「编码」→「UTF-8无BOM」重新保存，确保是标准的PEM格式（每行64字符，开头-----BEGIN CERTIFICATE-----，结尾-----END CERTIFICATE-----）。

• 未指定匹配的TLS版本
  Broker配置强制用tls_version tlsv1.2，但有些版本的mosquitto_sub默认TLS版本不匹配，握手时直接报错。
  解决：命令里显式指定TLS版本：

  mosquitto_sub -h broker -t test/topic -p 8883 --cafile CACert.crt --tls-version tlsv1.2
  

• 客户端版本不兼容
  如果mosquitto_sub的版本和Broker的2.0.20差太多，可能存在TLS协议实现的差异，导致握手失败。
  解决：把mosquitto_sub升级到2.0.20版本，和Broker版本保持一致。

• 主机名与证书标识不匹配（低概率）
  虽然发布端正常，但如果证书的通用名（CN）或备用名称（SAN）里没有broker这个主机名，部分严格的TLS客户端会触发信任错误（不过日志是unknown ca，这个原因可能性低）。
  解决：检查证书的SAN/CN字段，要么改成包含broker，要么用证书里有的主机名/IP执行订阅命令。

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