EvolutionAPI中使用自签名证书的解决方案

背景介绍

在企业内部部署EvolutionAPI时，很多管理员会选择使用自签名证书来保护内部服务的安全通信。然而，近期有用户反馈在EvolutionAPI v1.8.2版本中，当尝试向配置了自签名证书的webhook端点发送数据时，系统会抛出"unable to verify the first certificate"的错误，即使已经将CA证书正确安装到容器中。

问题分析

这个问题源于Node.js对TLS证书的严格验证机制。当EvolutionAPI尝试通过HTTPS与内部webhook通信时，Node.js默认会验证服务器证书的有效性。对于自签名证书，由于不是由公共受信任的CA签发，验证过程会失败。

虽然用户已经将CA证书安装到容器中，但Node.js的TLS模块可能没有正确加载这些证书。通过命令行工具curl测试可以成功，是因为curl使用了系统证书存储，而Node.js应用有自己独立的证书验证机制。

解决方案

临时解决方案：禁用证书验证

对于需要快速解决问题的场景，可以通过设置环境变量来禁用Node.js的证书验证：

environment:
  - NODE_TLS_REJECT_UNAUTHORIZED=0

这种方法虽然简单，但存在安全隐患，因为它完全禁用了TLS证书验证，使系统容易受到中间人攻击。仅建议在完全可控的内部网络环境中临时使用。

推荐解决方案：正确配置Node.js信任自签名CA

更安全的做法是让Node.js信任自签名的CA证书。可以通过以下步骤实现：

1. 将CA证书文件复制到容器内的特定位置
2. 设置NODE_EXTRA_CA_CERTS环境变量指向该证书

environment:
  - NODE_EXTRA_CA_CERTS=/path/to/ca-certificate.crt
volumes:
  - /host/path/to/ca-certificate.crt:/path/to/ca-certificate.crt

高级配置：使用完整的证书链

如果自签名证书使用了中间CA，需要确保提供完整的证书链文件。通常需要三个文件：

• 服务器证书(.crt)
• 私钥文件(.key)
• 中间证书(.pem)

最佳实践建议

1. 对于生产环境，建议使用Let's Encrypt等免费CA签发的证书
2. 如果必须使用自签名证书，确保证书包含完整的SAN(Subject Alternative Name)信息
3. 定期轮换证书，特别是私钥文件
4. 考虑在企业内部部署私有CA，统一管理所有内部服务的证书

总结

在EvolutionAPI中使用自签名证书需要特别注意Node.js的证书验证机制。通过正确配置环境变量或提供完整的CA证书链，可以安全地实现内部服务间的HTTPS通信。管理员应根据实际安全需求选择合适的解决方案，平衡安全性与便利性。