SafeLine WAF中HTTPS反向代理的证书配置问题解析

在使用SafeLine WAF进行HTTPS反向代理时，当后端服务有多个域名且使用HTTPS协议时，可能会遇到SSL握手失败的问题。本文将深入分析这一问题的成因及解决方案。

问题现象

当配置SafeLine WAF作为反向代理，后端服务使用HTTPS协议且存在多个域名时，系统日志中会出现类似以下错误：

SSL_do_handshake() failed (SSL: error:0A000410:SSL routines::ssl/tls alert handshake failure:SSL alert number 40)

根本原因分析

这个问题源于Nginx的默认代理行为。在HTTPS反向代理场景下，Nginx默认会将proxy_ssl_name设置为客户端请求的$host值。当后端服务器运行多个HTTPS域名时，这种配置会导致SSL握手失败，因为后端服务器无法提供与客户端请求域名匹配的有效证书。

解决方案

SafeLine WAF团队建议采用以下最佳实践：

1. 前端HTTPS，后端HTTP：在WAF层面终止HTTPS连接，后端服务使用HTTP协议。这是最推荐的做法，具有以下优势：

   • 简化证书管理，只需在WAF上配置证书
   • 减少后端服务器的SSL/TLS计算开销
   • 避免复杂的代理SSL配置

2. 如需保持端到端加密：如果确实需要保持后端HTTPS连接，可以：

   • 在后端服务器上配置通配符证书或SAN证书
   • 或者在后端服务器上配置默认证书，接受所有域名请求

技术细节

在Nginx配置中，proxy_ssl_name指令控制SNI（Server Name Indication）扩展的发送。当代理HTTPS后端时，正确的SNI值对于多域名服务器获取正确证书至关重要。

错误配置示例：

proxy_ssl_name $host;  # 默认行为，可能导致证书不匹配

推荐配置（当必须使用后端HTTPS时）：

proxy_ssl_name backend.example.com;  # 明确指定后端域名

性能考量

采用WAF终止HTTPS的方案不仅能解决证书问题，还能带来性能优势：

• 减少后端服务器的SSL/TLS握手开销
• WAF可以集中管理证书更新和续期
• 便于实施统一的SSL安全策略

总结

SafeLine WAF作为安全防护层，最佳实践是在WAF层面处理HTTPS终止，后端采用HTTP协议。这种架构既简化了证书管理，又保持了安全性，同时避免了复杂的代理SSL配置问题。对于必须保持端到端加密的特殊场景，则需要特别注意SNI和证书的匹配问题。