Linux上EMQX启用SSL/TLS加密完整指南：从安装到安全加固-开发者社区

前阵子帮朋友在一台 Linux 服务器上部署 EMQX，照着官方文档装完，MQTTX 也能正常收发消息，一切看起来都很顺利。直到我习惯性地抓了把包，才发现 1883 端口上跑的 MQTT 报文全是明文——用户名、密码、Topic、Payload 一眼就能看完。那一刻我突然意识到，如果只是本地玩一玩这个无所谓，可一旦 broker 暴露到公网，这跟把设备控制权直接送人没什么区别。

这篇文章就记录一下我在 Linux 上从零安装 EMQX，到启用 SSL/TLS 加密连接的完整过程，包括证书怎么生成、配置怎么写、踩了哪些坑，还有一些安全加固的细节。不管你是刚接触 MQTT 的新手，还是已经在用 EMQX 但一直没做加密的老手，这篇文章应该都能帮你少走点弯路。

1. 环境准备与版本选择

1.1 为什么选择 EMQX 5.x 而不是 4.x

先说版本选择。目前 EMQX 官方主推的是 5.x，相比 4.x 变化非常大，不是简单的小版本升级。最直观的差别是配置方式：4.x 用 Erlang 风格的配置格式，看着像mqtt.listener.tcp.external {}这种结构；5.x 改成了 HOCON 格式，和现代很多配置框架（比如 Play Framework、Akka）保持一致的风格，阅读起来更清晰，也支持更灵活的嵌套和覆盖。

另外一个重要的变化是 Dashboard。5.x 的 Web 管理界面做得相当精致，内置了实时指标、客户端列表、订阅关系管理、甚至还有在线调试工具。对于团队协作来说，这比 4.x 时代要直观得多。

还有一点很关键：5.x 在集群能力上做了大幅增强，通过emqx ctl命令可以很方便地组建多节点集群。虽然单机部署用不到，但如果你有扩容打算，从 5.x 开始会平滑很多。所以我建议直接上 EMQX 5.x，目前最新的 5.x 稳定版大概在 5.5 左右，具体以官方发布为准。

1.2 系统要求和初始化建议

官方文档给出的最低配置是 1 核 512MB，但我建议生产环境至少 2 核 2GB，如果并发连接数比较多，直接上 4 核 8GB 不亏。因为 EMQX 底层是 Erlang/OTP 虚拟机，虽然单机性能很强，但内存占用并不算小，我看到过不少人在 512MB 的小鸡上部署 EMQX 导致 OOM 的案例。

操作系统方面，优先选择 Debian 12、Ubuntu 22.04 LTS、CentOS Stream 9 这类主流发行版。我个人最常用的组合是 Ubuntu 22.04 LTS，因为 EMQX 官网对 Ubuntu 的包支持最好，apt 源也很稳定。

系统初始化阶段，有几个小建议：

关掉不需要的 systemd 服务，减少安全暴露面。
确保防火墙规则是在系统层面控制的，不要裸奔。
给服务器配置一个稳定的主机名，因为证书里通常要写域名或 IP，后面做 SSL/TLS 时用得着。
预留好证书文件目录，统一放在/opt/emqx/etc/certs/下，防止后面权限混乱。

1.3 端口规划

这是很多人容易忽略的一步，先规划好才能避免后面改来改去。EMQX 默认会监听以下端口：

端口	协议	用途
1883	MQTT/TCP	明文 MQTT 连接
8883	MQTT/TLS	加密 MQTT 连接
8083	MQTT/WebSocket	Web 端明文连接
8084	MQTT/WebSocket/TLS	Web 端加密连接
18083	HTTP	Dashboard 管理界面

我的方案是：1883 只保留给内网或测试环境用，生产环境强制走 8883 的 TLS 加密连接。8083 同理，能不开就不开，如果前端要连 WebSocket，就用 8084。

2. 安装 EMQX：从 Docker 到二进制包

2.1 Docker Compose 部署（最省心）

如果你用的服务器本来就跑着 Docker，那用 Compose 部署 EMQX 是最快的方案。我给出一个适合单机生产的docker-compose.yml：

version: "3.8" services: emqx: image: emqx/emqx:5.5.0 container_name: emqx restart: always ports: - "1883:1883" - "8883:8883" - "8083:8083" - "8084:8084" - "18083:18083" environment: - EMQX_DASHBOARD__DEFAULT_PASSWORD=your_strong_password volumes: - emqx-data:/opt/emqx/data - emqx-log:/opt/emqx/log - ./certs:/opt/emqx/etc/certs:ro volumes: emqx-data: emqx-log:

注意我把证书目录挂载了进去，这样后面生成好证书后直接放到宿主机的./certs/就能生效。Dashboard 的默认密码也可以通过环境变量在容器创建时改掉，比启动后再进界面改要安全一些。

启动命令很简单：

docker compose up -d

然后访问http://服务器IP:18083应该就能看到 Dashboard。

2.2 APT 仓库安装（传统服务器推荐）

如果不希望引入 Docker 依赖，用官方 APT 仓库安装也很方便。Ubuntu 下的安装流程是：

curl -s https://assets.emqx.com/scripts/install-emqx-deb.sh | sudo bash sudo apt-get install emqx sudo systemctl enable emqx sudo systemctl start emqx

安装完成后检查一下运行状态：

sudo systemctl status emqx emqx ctl status

只要看到Node emqx@127.0.0.1 is started就说明安装成功。这种方式的好处是 EMQX 会作为 systemd 服务来管理，开机自启、日志集中、崩溃自动重启都是现成的。

2.3 二进制包安装和目录结构

还有一种方式就是直接下载官方编译好的二进制包，解压就能用。这种方式适合那些对系统环境有特殊要求、不想改动系统目录结构的场景。

# 下载 EMQX 5.5.0 的 Ubuntu 包 wget https://github.com/emqx/emqx/releases/download/v5.5.0/emqx-5.5.0-ubuntu22.04-amd64.tar.gz tar -xzf emqx-5.5.0-ubuntu22.04-amd64.tar.gz -C /opt cd /opt/emqx ./bin/emqx start

解压出来的/opt/emqx目录结构如下：

/opt/emqx ├── bin/ # 可执行文件，包括 emqx、emqx_ctl 等 ├── etc/ # 配置文件，主要看 emqx.conf 和 certs/ 子目录 ├── data/ # 运行时数据、heatmap、mnesia 等 ├── log/ # 日志文件 ├── lib/ # Erlang 模块和依赖库 └── plugins/ # 插件存放目录

需要明确的是，如果你用 APT 安装，安装路径通常也是/opt/emqx，所以后续配置文件的路径是一致的。

2.4 验证安装成功

无论用哪种方式装好，都建议在浏览器里打开 Dashboard 验证一下，地址是http://IP:18083，默认账号密码是admin/public。登进去后的第一件事，就是把默认密码改掉，这个习惯真的很重要。

其次，用系统命令确认端口在监听：

ss -tlnp | grep -E "1883|8883|8083|8084|18083"

看到这些端口有监听状态，说明 EMQX 已经正常工作了。

3. MQTT 与 EMQX 核心概念速览

3.1 MQTT 协议为什么适合物联网

在配置安全之前，先花点时间梳理一下 MQTT 本身的机制，因为后面排查问题时你会频繁和这些概念打交道。MQTT 是基于发布/订阅模型的轻量级消息协议，和传统的客户端/服务器请求响应模式完全不同。

MQTT 中有三个核心角色：Broker、Publisher、Subscriber。Publisher 把消息发到一个"主题"上，Subscriber 根据自己的关注订阅主题，Broker 负责转发消息。这种解耦带来的好处是：发布端不需要知道订阅端是谁，订阅端也不依赖于发布端在线。

QoS（服务质量）是另一个必懂的概念，分为 0、1、2 三个等级：

QoS 0：最多一次，消息发出后不关注对方是否收到，延迟最低但可能丢。
QoS 1：至少一次，保证对方能收到，但可能收到重复消息。
QoS 2：恰好一次，通过四次握手保证消息不重不漏，开销最大。

主题结构上用/做层级分隔，比如device/001/temperature和device/002/humidity。订阅时可以带通配符：device/+/temperature匹配所有设备下的温度主题，device/#匹配所有子层级。

理解这些概念对排查连接问题和设计 Topic 很重要，尤其是后面做 TLS 加密的时候，你依然要确认消息的路由逻辑是否正常。

3.2 EMQX 的 Listener 机制

EMQX 把每个端口的监听行为抽象成了一个"Listener"（监听器）。你可以理解为：一个 Listener 就是系统的"耳朵"，它负责在某一个端口上接收特定协议类型的客户端连接。

EMQX 5.x 默认配置了多个 Listener，分别是 TCP、SSL、WebSocket 等。在emqx.conf里，这些配置以listeners.tcp.default、listeners.ssl.default这样的键来组织。

我们启用 SSL/TLS 的本质，就是调整或新增一个 SSL 类型的 Listener，让它监听 8883 端口，并加载证书文件。

3.3 认证方式：从匿名到用户名密码

EMQX 默认是"匿名访问"的。也就是说，任何客户端只要知道 broker 地址和端口，就能不提供任何凭证直接连接、订阅任意主题，这是一个巨大的安全隐患，尤其是当你的 broker 暴露在公网时。

我建议这样做：先在 Dashboard 的"访问控制" -> "认证"里添加一个密码认证数据源，比如使用内置数据库（Built-in Database），创建几个测试账号。这样我们在验证 TLS 加密的时候，也可以顺便把认证打开，一举两得。

配置很简单，在 Dashboard 里选择"认证"，添加认证器，选择"内置数据库"，然后创建用户名和密码。客户端连接时必须在 CONNECT 包里带上用户名密码，否则会被拒绝连接。

4. SSL/TLS 证书准备：自签名还是 CA 签发的

4.1 三类证书方案怎么选

启用 TLS 加密的核心是证书。根据你的部署场景，有三种常见选择：

公网可信 CA 证书：像 Let's Encrypt、ZeroSSL 这类免费 CA 签发的域名证书，优点是浏览器和客户端默认信任，不需要额外配置。缺点是要求你有域名，并且需要验证域名所有权。
自签名证书：自己生成的证书，部署免费、生成快，适合内网测试环境。缺点是客户端连接时必须显式指定信任该证书或 CA，否则会报证书校验失败。
私有 CA 证书：自己搭一套 CA 体系，给内网环境统一签发证书。方案最完整，但管理成本高，适合有运维团队的企业场景。

结合大多数人的实际场景，我下面重点演示自签名证书的生成方式。虽然它是"自签名"，但只要在客户端把 CA 证书配好，安全性和 CA 签发的证书在传输加密层面没有本质区别。

4.2 生成自签名证书的详细过程

我用一套两层结构：先创建一个私有 CA，再用这个 CA 给服务器签发证书。这样可以模拟完整的 CA 签发流程，后面如果你要管理多个设备，也可以基于同一套 CA 签发证书，客户端只需要信任这个 CA 就能统一验证。

第一步，生成 CA 私钥和 CA 证书：

mkdir -p /opt/emqx/etc/certs && cd /opt/emqx/etc/certs # 生成 CA 私钥 openssl genrsa -out ca.key 2048 # 生成 CA 自签证书 openssl req -x509 -new -nodes -key ca.key -days 3650 -out ca.crt \ -subj "/C=CN/ST=Beijing/L=Beijing/O=MyIoT/CN=MyIoT Root CA"

这里有几个参数值得解释一下：

genrsa -out ca.key 2048：生成 2048 位的 RSA 私钥。2048 位是目前的最低推荐标准，低于这个位数（比如 1024）在 2024 年的环境下已经非常不安全。
-days 3650：CA 根证书有效期 10 年。自签名的 CA 是自己信任自己的体系，时间长一点方便管理。
CN=MyIoT Root CA：Common Name，建议写一个能表达身份的标识，方便以后人眼识别。

第二步，生成服务器的私钥和证书签名请求（CSR），并用 CA 签发服务器证书：

# 生成服务器私钥 openssl genrsa -out server.key 2048 # 生成证书签名请求 openssl req -new -key server.key -out server.csr \ -subj "/C=CN/ST=Beijing/L=Beijing/O=MyIoT/CN=broker.example.com" # 用 CA 签发服务器证书，有效期 825 天，并加入 SAN 扩展 openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out server.crt -days 825 -sha256 \ -extfile <(printf "subjectAltName=IP:192.168.1.100,DNS:broker.example.com")

这里的-extfile <(printf ...)是为证书添加 SAN（Subject Alternative Name）扩展。SAN 是什么？简单说，它是现代证书里用来记录"这个证书适用于哪些域名/IP"的字段。以前的证书主要看 CN，但现在浏览器和客户端都优先看 SAN，如果证书里没有包含当前访问的域名或 IP，即使 CN 匹配也会校验失败。

所以你需要把服务器的实际 IP 和域名都写在这个 SAN 列表里，逗号分隔。比如我用的是IP:192.168.1.100和DNS:broker.example.com，你可以替换成自己的。

4.3 顺手处理扫描器报的 CVE-2016-2183 告警

不少人做完 TLS 配置后用工具扫一遍，会看到SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183)【原理扫描】这种告警，这里顺便把这个常见问题讲透。

CVE-2016-2183 对应的是 SWEET32 攻击，原理是 3DES（Triple DES）算法在 CBC 模式下存在理论上的生日攻击风险。当加密套件里包含基于 3DES 的套件时，扫描器就会报这个漏洞。修复思路不是升级 EMQX，而是让 TLS 服务端不要支持 3DES 算法。

先检查系统 OpenSSL 是否支持 3DES：

openssl ciphers -v 'ALL' | grep -i 3des

如果支持，最简单的办法是使用高版本的 OpenSSL。OpenSSL 3.x 已经默认把 3DES 降级到安全级别 0 以下，很多情况下会自动禁用。

在 EMQX 层面，你也可以显式指定只使用高强度加密套件。以 EMQX 5.x 为例，在emqx.conf里加入ciphers配置：

listeners.ssl.default.ssl_options { ciphers = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256" }

这段配置只启用了 ECDHE + AES-GCM 这类现代强套件，完全排除了 3DES 和 CBC 系的老算法。处理完后再用扫描器扫一遍，告警就会消失。

4.4 私钥文件权限不容忽视

证书生成完之后，目录里会有这几个文件：ca.key、ca.crt、server.key、server.crt、server.csr。其中server.key是服务器私钥，泄露了就等于你的加密通道形同虚设。

务必执行：

chmod 600 server.key ca.key chmod 644 server.crt ca.crt

还要确认/opt/emqx/etc/certs/目录对 EMQX 运行用户有读权限，不然 EMQX 启动时会报错提示无法读取证书文件。

5. 启用 SSL/TLS 监听器配置实操

5.1 双端口方案：明文内网、加密公网

我推荐的做法是：1883 明文端口保留给内网/测试环境，8883 加密端口用于对外服务。这不是偷懒，而是很务实的设计。

内网设备之间通信，如果网络环境可控，走明文能降低设备端的运算开销，而且排查问题更方便。公网流量一律走 8883 加密。这样即使 1883 被暴露，由于绑定的是内网 IP，公网根本访问不到。

在 EMQX 5.x 中，可以通过设置 bind 地址来实现：

listeners.tcp.default { bind = "127.0.0.1:1883" }

把 1883 端口绑定到回环地址，相当于只有本机自己能访问，公网完全不可达。如果内网其他机器需要访问 1883，就绑定到内网网卡 IP，比如192.168.1.100:1883。

5.2 编辑 emqx.conf 配置 SSL Listener

EMQX 5.x 的主配置文件是/opt/emqx/etc/emqx.conf，我们需要在其中添加或修改listeners.ssl.default配置块。如果你用 APT 安装，直接编辑这个文件即可。

下面是完整的 SSL Listener 配置：

listeners.ssl.default { bind = "0.0.0.0:8883" ssl_options { cacertfile = "/opt/emqx/etc/certs/ca.crt" certfile = "/opt/emqx/etc/certs/server.crt" keyfile = "/opt/emqx/etc/certs/server.key" verify = "verify_none" } }

解释一下各项含义：

bind：监听地址和端口，0.0.0.0:8883表示所有网卡上的 8883 端口都接受 SSL 连接。
cacertfile：CA 证书路径，用于验证客户端证书（如果开启双向认证）时使用。即使目前verify_none，把它填上也不亏。
certfile：服务器证书路径。
keyfile：服务器私钥路径。
verify：客户端证书验证策略。verify_none表示不强制客户端提供证书，只做单向认证，这是我们最常用的模式。如果开启verify_peer，还需要客户端提供证书，那就是双向认证，配置复杂度高不少，大多数场景用不上。

5.3 修改配置后重启并验证

修改完配置后需要重启 EMQX：

sudo systemctl restart emqx

然后检查 8883 端口是否在监听：

ss -tlnp | grep 8883

如果能看到 LISTEN 状态，就说明 SSL Listener 已经成功启动。

再进一步，用openssl s_client这个瑞士军刀工具来验证证书链和 TLS 握手：

openssl s_client -connect localhost:8883 -showcerts

如果配置正确，输出里会包含完整的证书链信息，以及类似SSL handshake has read ... bytes的消息。如果报错，比如unable to verify the first certificate，通常就是证书链不完整或者 CA 不匹配。

5.4 验证加密套件是否安全

顺手检查一下当前服务端支持的加密套件：

openssl s_client -connect localhost:8883 -cipher 'HIGH:!aNULL:!eNULL:!3DES:@STRENGTH'

如果握手成功，就说明服务端已经只接受上述强加密套件。这正是处理 CVE-2016-2183 之后应有的效果。

6. 客户端连接验证：图形化与命令行双管齐下

6.1 用 MQTTX 验证加密连接

MQTTX 是目前最流行的 MQTT 图形化客户端，支持 Windows、macOS、Linux，界面简洁，对调试很友好，我一直在用。

新建连接时按以下方式配置：

Name：EMQX-TLS-Test
Host：mqtts://你的服务器IP
端口：8883
Username / Password：你在 Dashboard 里创建的用户名密码
点击 SSL/TLS：启用 TLS，选择"CA 证书"，然后选中ca.crt文件

如果使用 CA 签发的证书，MQTTX 默认就能信任，不需要额外导入。用自签名证书时，导入 CA 是必须的，否则客户端会因为不信任服务端证书而拒绝连接。

客户端启动并连接成功后，MQTTX 界面会显示绿色的 connected 状态。这时候你可以随便订阅一个主题，比如test/topic，然后通过 Dashboard 里的"消息工具"或者另一个客户端发布消息验证一下。

6.2 用命令行工具测试更可靠

有时候图形化界面能连上，但不代表所有场景都正常。我建议用命令行工具再做一次严格验证，这也能排查掉图形化工具隐藏的兼容性处理。

安装 Mosquitto 客户端工具：

sudo apt-get install mosquitto-clients -y

订阅端：

mosquitto_sub -h 你的服务器IP -p 8883 --cafile /opt/emqx/etc/certs/ca.crt \ -u testuser -P testpassword -t 'test/topic' -v

发布端（另开一个终端）：

mosquitto_pub -h 你的服务器IP -p 8883 --cafile /opt/emqx/etc/certs/ca.crt \ -u testuser -P testpassword -t 'test/topic' -m 'hello emqx tls'

这里值得提醒的是：--cafile必须指定为服务端自签名证书对应的 CA 文件（即ca.crt），不能是server.crt。因为客户端要验证的是服务端证书是否由该 CA 签发，所以它需要的是 CA 的公钥证书。

如果证书校验失败，命令行客户端通常会报OpenSSL Error: certificates verify failed，这时候去检查客户端传的 CA 文件是否和服务端证书匹配。

6.3 抓包确认加密效果

最后一步，用tcpdump抓包看看到底有没有加密：

tcpdump -i any port 8883 -A

抓包内容里应该全是乱码，看不到任何明文 MQTT 报文。拿同样的方法抓一下 1883 端口，对比就非常直观了，1883 端口上的 topic、payload 一目了然。这其实就是第 1 节开头说的"裸奔"现象。

tcpdump如果没有装，先执行：

sudo apt-get install tcpdump -y

6.4 双向认证（mTLS）扩展思路

如果你对安全要求更高，可以考虑启用双向认证（mTLS）。简单来说，客户端连接时除了验证服务端证书，服务端也会要求客户端出示证书。

EMQX 5.x 启用双向认证的配置改成：

listeners.ssl.default.ssl_options { verify = "verify_peer" fail_if_no_peer_cert = "true" }

同时生成客户端证书并导入到客户端侧。这个方案的优点是可以做到设备级的身份认证，比用户名密码更可靠。缺点是证书管理成本高，每一台设备都要签发和安装证书，所以适合对安全要求严格的场景，比如车联网、金融物联网终端等。如果你只是普通个人项目，单向认证 + 用户名密码已经足够。

7. 常见问题排查与避坑指南

7.1 证书链不完整导致握手失败

这是自签名证书最常踩的坑。场景是这样的：你拿openssl s_client测试服务端正常，但客户端连接时就报unable to verify the first certificate。

原因通常是服务端只发了叶子证书（server.crt），没有发送中间 CA 证书或者根 CA 证书。尤其在公网 CA 签发的场景下，根证书需要在系统信任库里有记录，但中间证书需要服务端主动下发。解决办法是把 CA 证书和服务器证书合并成一个文件：

cat server.crt ca.crt > server_chain.crt

然后把emqx.conf里的certfile指向这个合并文件。

7.2 防火墙/安全组拦截 8883 端口

云服务器上即使系统防火墙放行了，云厂商的安全组没有放行 8883，一样连不上。测试时先确认系统侧：

sudo ufw status # 或者 sudo firewall-cmd --list-all

如果需要放行：

sudo ufw allow 8883/tcp

然后去云厂商控制台的安全组策略里检查入方向规则，确认 8883 端口已放行。

7.3 EMQX 读取证书文件报权限错误

日志里出现这类关键字：

{error,{failed_to_read_certfile,"/opt/emqx/etc/certs/server.crt"}}

多数情况是证书文件权限不对。EMQX 运行用户无法读取私钥文件，或者私钥文件权限太高被 OpenSSL 拒读。核对一下：

ls -l /opt/emqx/etc/certs/

至少保证server.key只能被属主读写，server.crt和ca.crt对所有用户可读。注意如果私钥是 root 创建的，而 EMQX 以 emqx 用户运行，需要调整属主或添加读权限。

7.4 客户端时间不同步导致证书过期

证书校验失败还有一个隐藏原因：客户端本地时间不正确。如果客户端机器的系统时间和实际时间差了好几天，哪怕证书明明还在有效期内，也会被判定为过期。

排查方法很快，在客户端机器上执行：

date

如果时间不对，启用 NTP 同步：

sudo timedatectl set-ntp true

这个坑我见过挺多次，很多人纠结证书配置半天，最后发现是时间问题。

7.5 不同版本 EMQX 的配置差异

我上面写的是 EMQX 5.x 的配置写法。如果你还在用 4.x，配置方式会有所不同。4.x 的 SSL Listener 通常在etc/emqx.conf里这就是一个巨大的差异，5.x 中已经统一为 HOCON 结构。

升级或者迁移时建议直接看对应版本的官方文档，不要盲目照抄配置文件。具体来说，4.x 的配置通常在emqx.conf中通过listener.ssl.external这类键来配置，和 5.x 的listeners.ssl.default结构完全不同。

7.6 常见错误码速查表

整理一份我在调试过程中遇到的高频错误码，方便大家对照排查：

错误码/报错	可能原因	排查方式
`unable to verify the first certificate`	证书链不完整客户端不信任 CA	合并证书链，检查客户端 CA 导入
`self-signed certificate`	客户端没有导入服务器证书对应的 CA	在 MQTTX 中指定`ca.crt`并勾选 Verify
`connection closed`	端口没监听、防火墙拦截	执行`ss -tlnp`，检查云安全组
`certificate verify failed`	客户端时间不对或 CA 不匹配	检查系统时间，确认 CA 一致性
`key file permission error`	私钥权限过宽或无法读取	确认`chmod 600 server.key`

7.7 Dashboard 自身也别裸奔

很多人的 EMQX 加密连接配好了，但 Dashboard 管理界面还是裸奔在 HTTP 上，这其实是一个更严重的风险点。攻击者登录 Dashboard 后可以随意查看客户端数据、甚至修改配置。

EMQX 5.x 的 Dashboard 支持使用现有证书启用 HTTPS。在 Dashboard 的"设置"里选择 SSL，上传证书和密钥就能启用 HTTPS 访问。配置完后记得用https://你的IP:18083访问，不要再用 HTTP。

另外 Dashboard 的管理员密码至少要 12 位以上，并且不要使用常见的弱口令。这个细节很多人会忽略，但真的非常关键。

8. 生产环境选型建议与个人体会

8.1 生产环境证书选型优先考虑公网 CA

如果 EMQX 部署在公网环境，有域名，我强烈建议优先使用 Let's Encrypt 之类的公共 CA 证书，而不是自签名证书。原因很简单：客户端不需要额外配置 CA，所有标准的 MQTT 客户端开箱即用，省掉了不少部署成本。

Let's Encrypt 的证书有效期是 90 天，需要自动化续期。你可以用 certbot 配合定时任务或者 webhook 来实现证书的自动更新，更新后再同步到 EMQX。这类自动化方案网上资料很多，这里不展开。

自签名证书更适合的场景是内网环境、测试环境，或者设备端可以高度定制化接入的场景。就算用自签名，也要把证书有效期、轮换周期提前规划好，避免设备端证书过期导致大面积断连事故。

8.2 个人经验：先抓包再优化

我的建议是：无论配置再完美，最后一步永远用抓包工具确认一次加密效果。这不是形式主义，而是因为在 MQTT/TLS 混合部署的场景里，经常会出现"客户端明明用了 8883 端口"但实际连接走了明文代理的情况。抓包验证一下，才能真正确认流量已经被加密。

8.3 关于 EMQX 日志定位问题的技巧

遇到连接问题时，先看 EMQX 的日志输出。日志文件一般在/opt/emqx/log/下，运行日志默认级别是 warning。如果你想看到更细的接入过程，可以把日志级别临时调到 debug：

emqx_ctl log set-level debug

调完之后连接一次，日志里会显示完整的握手流程和报错原因。排查完记得调回 warning，否则日志量会非常大。

8.4 最后一个小技巧：定期备份配置和证书

配置文件emqx.conf和certs/目录务必定期备份，最好能和 EMQX 的数据目录一起纳入到整体的备份策略里。我见过不止一次服务器迁移时，数据拷走了但证书忘拷，结果新环境 TSL 完全起不来的情况。一个简单的 tar 命令就能搞定：

tar czf emqx-backup.tar.gz /opt/emqx/etc/emqx.conf /opt/emqx/etc/certs