VerneMQ 2.0.0版本PostgreSQL SSL连接问题深度解析

问题背景

VerneMQ作为一款开源的MQTT消息代理，在2.0.0版本升级后，用户反馈在使用Diversity插件连接PostgreSQL数据库时出现了SSL验证失败的问题。这个问题特别出现在连接Azure托管的PostgreSQL服务时，而在1.13.0版本中相同的配置却能正常工作。

问题现象分析

当用户从1.13.0升级到2.0.0版本后，使用相同的Docker参数配置时，系统会抛出SSL验证错误。错误日志显示：

{ssl_negotiation_failed,{options,incompatible,[{verify,verify_peer},{cacerts,undefined}]}}

这表明系统尝试以verify_peer模式进行SSL验证，但未能找到有效的CA证书链。

根本原因

经过深入分析，我们发现这个问题源于VerneMQ 2.0.0版本将底层Erlang/OTP从25升级到了26版本。OTP 26在SSL/TLS处理上有以下重要变化：

1. 客户端默认启用verify_peer验证模式
2. 加强了主机名验证(hostname verification)
3. 要求显式配置CA证书链

在Azure PostgreSQL服务中，服务器证书的Common Name(CN)与实际的连接域名不一致，只出现在Subject Alternative Names(SAN)中。OTP 26的严格验证机制会检查这一点，而OTP 25则较为宽松。

解决方案

针对这个问题，开发团队提出了多种解决方案：

1. 配置CA证书文件：通过设置vmq_diversity.postgres.cafile指向系统CA证书(如/etc/ssl/certs/ca-certificates.crt)

2. 调整主机名验证：对于Azure PostgreSQL这种CN与连接域名不一致的情况，可以配置：

   {customize_hostname_check, [{match_fun, public_key:pkix_verify_hostname_match_fun(https)}]}
   

3. 降低验证级别：在特定环境下，可以临时使用{verify, verify_none}关闭验证(不推荐生产环境使用)

4. 深度参数调整：对于复杂的CA证书链，可能需要配置depth参数

技术细节

Azure PostgreSQL使用的证书具有以下特点：

• Common Name: [hash].database.azure.com
• Subject Alternative Names: 包含实际的连接域名
• 证书链包含DigiCert的中间CA和根CA

这种证书结构在OTP 26的严格验证下会导致bad_cert,hostname_check_failed错误，因为：

1. 客户端使用SAN中的域名连接
2. 但证书的CN是另一个值
3. OTP 26会严格检查这种不匹配情况

最佳实践建议

对于使用VerneMQ连接云数据库服务的用户，我们建议：

1. 保持CA证书更新：确保容器内的CA证书文件是最新的

2. 明确验证策略：根据安全需求选择适当的verify模式

3. 测试环境验证：在升级前，先在测试环境验证SSL连接

4. 监控日志：密切关注SSL协商相关的错误日志

5. 考虑回退方案：对于关键业务系统，准备好回退到1.13.0版本的方案

总结

VerneMQ 2.0.0版本由于底层OTP升级带来的SSL验证强化，确实会对某些云数据库连接造成影响。开发团队已经意识到这个问题，并正在通过代码修改来提供更灵活的SSL配置选项。用户可以根据自身环境选择适当的解决方案，平衡安全性和兼容性需求。