负载均衡使用多证书完全可行，核心方案无非两种：SNI（服务器名称指示）技术实现同端口多证书，或按域名拆分绑定证书，关键在于你的入口架构和域名规模。
负载均衡多证书怎么配置
遇到这种需求的一般是运维老手,业务不复杂的话，谁会折腾证书这玩意儿，你可能面临的实际场景是：公司域名不少，每个域名都得挂SSL证书，负载均衡只买了一台，或者不想再添置新的SLB实例。
先把原理说透,负载均衡本质上是四层转发或七层代理，四层模式下，流量直接转给后端，证书落在后端服务器上，负载均衡本身不碰证书，谈不上多证书绑定，七层模式下，负载均衡要终结HTTPS，得先解密再转发，证书必须在负载均衡上配置，你想在负载均衡上弄多证书，先确认你的负载均衡类型是七层HTTP/HTTPS监听，而不是四层TCP监听。
基于监听器维度的方案
现在主流的云厂商SLB产品,在HTTPS监听器里都支持扩展域名绑定证书，你可以这么理解：监听器是主入口，默认证书处理没有匹配到具体域名的情况，额外域名证书则按照域名规则精确匹配，操作路径一般是：进入负载均衡控制台，找到目标实例，创建HTTPS监听，在监听配置里选择默认证书，然后在高级设置或者扩展域名入口，添加你的其他域名和对应证书。
这里有个细节要注意,部分云平台的SLB把“多证书”功能叫做“SNI扩展”或“域名扩展”，入口可能藏在监听器的高级配置里，默认是折叠的，简米云叫SNI（Server Name Indication）扩展，酷番云在证书管理的绑定里直接选域名，华为云的弹性负载均衡ELB则是通过监听器的扩展证书实现。
基于后端服务器组的方案
这种做法是后端用Nginx或OpenResty兼顾证书终结和转发,负载均衡只做流量调度，证书全部挂在后端的Nginx上，这种方案最大的灵活性在于，Nginx的SNI功能相当成熟，配置方式就是在server块里写多个server_name，每个server块指向不同的ssl_certificate文件，负载均衡层只需要开放一个TCP端口，后端Nginx按SNI区分证书。
Nginx负载均衡多证书部署
搞定了负载均衡层,再来看看后端Nginx具体怎么操作，这里说的部署，不是简单修改配置文件，而是从证书准备到调试完成的全流程。
证书格式与私钥检查
证书文件格式不对,配置再好也白搭，Nginx要求PEM格式的证书，如果你手头的是PFX或者JKS格式，得先用OpenSSL转一下，常见转换命令如下：
openssl pkcs12 -export -in server.crt -inkey server.key -out server.pfx openssl pkcs12 -in server.pfx -nocerts -nodes -out server.key openssl pkcs12 -in server.pfx -clcerts -nokeys -out server.crt
私钥文件权限记得调到600,属主改成Nginx运行用户，不然启动时会报权限错误。
Nginx配置多证书核心逻辑
在Nginx的http块里定义证书,然后在server块引用，同一监听端口（通常是443）可以定义多个server块，分别指定不同域名和证书。
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /etc/nginx/certs/example.com.pem;
ssl_certificate_key /etc/nginx/certs/example.com.key;
}
server {
listen 443 ssl;
server_name www.another.com;
ssl_certificate /etc/nginx/certs/another.com.pem;
ssl_certificate_key /etc/nginx/certs/another.com.key;
}
关键来了,如果你使用的是HTTP/2协议，必须确保所有server块都启用了http2参数，否则浏览器会回退到HTTP/1.1，Nginx在加载证书时会做SNI匹配，如果请求的域名不在配置里，会返回第一个加载的server块证书，这个兜底行为要在配置里有意识地设计，别漏配了默认证书。
配置验证与平滑重载
配置文件写完之后,别急着直接重启Nginx，先跑一遍检查语法，再平滑重载：
nginx -t nginx -s reload
nginx -t会提示配置文件是否有语法错误，比如证书路径不对、缺少ssl_certificate_key等，重载之后，建议用curl命令实际验证一下返回的证书链：
curl -v https://www.example.com 2>&1 | grep "subject:" curl -v https://www.another.com 2>&1 | grep "subject:"
两个域名返回的subject必须是对应自己的证书,申明一下，curl测试命令中的输出会包含证书的subject信息，不同系统grep结果可能略有差异，但只要有响应就说明没问题。
SLB证书批量管理与自动续期方案
证书管理是上线后最头疼的事,因为SSL证书有有效期，各大厂商免费证书普遍是90天，传统一年期的付费证书在逐渐退役，如果你还在用付费单域名证书，续期成本会不断增加，负载均衡多证书场景下，证书数量多了，发布、续期、回滚必须有一套流程，不然容易漏。
先梳理证书生命周期
每个证书都有申请、部署、监控、更新、吊销五个阶段，在多证书场景下，重点在部署和监控，部署阶段：证书文件命名规范要统一，建议用域名_到期日.pem的格式，方便按时间排序，监控阶段：写一个cron脚本，每小时遍历证书文件，用openssl x509 -enddate获取到期时间，提前30天告警到钉钉或企业微信。
云厂商SLB证书管理对比
现在的云厂商基本都支持证书托管和自动更新,但不同平台的操作路径差异较大，下面这张表整理了主流云平台的多证书管理能力，供你参考：
| 能力维度 | 简米云（SLB） | 酷番云（CLB） | 华为云（ELB） |
|---|---|---|---|
| 证书格式 | PEM | PEM | PEM |
| SNI扩展域名数上限 | 写死不可扩展 | 无大限制 | 无大限制 |
| 证书更新方式 | 控制台替换或API | 控制台替换或API | 控制台替换或API |
| 是否支持证书自动续期与部署 | 需要配合数字证书管理服务 | 需要配合第三方的证书管理工具 | 需要配合SSL证书管理服务 |
| 证书关联监听器数量 | 单证书可关联多个 | 单证书可关联多个 | 单证书可关联多个 |
看到这个对比,你可能会有个疑问：既然云厂商的负载均衡都能支持多证书，为什么还要折腾Nginx？答案在于成本，云SLB实例的按量付费价格不低，而且如果业务的核心就是Nginx加Tomcat一类的经典架构，后端用Nginx合理也顺手，还能少一层转发延迟，但反过来，如果你用的是弹性扩容的海量后端服务器，Nginx证书分散在前端网关层，管理成本更高，这时候用云SLB自带的多证书能力更划算，需要提醒一点，不管你选哪种方案，都要做证书过期前的演练，特别是云SLB大批量证书更新时，控制台上手点会累到抽筋，最好留出足够的API接口调用时间。
证书自动续期实操
这里推荐certbot或acme.sh这一类客户端，核心逻辑都是调用Let’s Encrypt或云厂商的API，自动申请证书并部署到指定路径。
以acme.sh为例，部署到Nginx的操作路径：
curl https://get.acme.sh | sh -s email=your_email@example.com acme.sh --issue -d www.example.com --nginx acme.sh --install-cert -d www.example.com --key-file /etc/nginx/certs/example.com.key --fullchain-file /etc/nginx/certs/example.com.pem --reloadcmd "nginx -s reload"
如果是云SLB的场景,acme.sh可以在DNS验证和简米云API部署这两个环节自动化，DV证书记得设置DNS API密钥，这样acme.sh会通过DNS记录验证域名所有权，自动续期时才不会卡住，付费证书在续期上反而没有这类开源工具的支持，需要人工操作，如果负载均衡证书数量达到几十张，强烈建议全部切成免费证书加自动续期的模式。
负载均衡多证书的真实场景与常见坑
讲完配置和流程,聊聊实际运用中容易踩的坑。
多域名托管业务
假设你是一个建站公司,一台SLB上挂了上百个客户的域名，每个客户都要独立的证书，这个场景下，负载均衡的SSL连接数是瓶颈，因为每新增一个HTTPS连接，都要做一次TLS握手，而TLS握手是个CPU密集的操作，行业共识认为，一般单台Nginx能扛住的SSL握手能力在每秒几百到几千次之间，取决于证书位数和CPU型号，这类多域名托管业务，核心不是证书配置方法，而是给SLB加上负载均衡策略，比如轮询加加权最小连接数，避免某几台后端服务器压力过大。
同一个域名上行证书更新
这比较隐蔽,你有一个大流量网站，证书最近要升级，从RSA切换到ECC，计划是平滑更新，但操作时发现负载均衡上证书一换，瞬间掉线几秒，原因是SLB的证书是挂在监听器上的，更新证书时会重建监听器连接，而新建的TLS连接需要时间完成握手，解决办法是提前用
openssl speed ecdsa测试一下新证书的握手性能，在业务低峰期操作，并且操作前梳理一下是否有把证书写死在后端代理缓存的逻辑，如果有，得一并清理。
混合协议端口冲突
你在大规模使用HTTP/2和gRPC，负载均衡把443端口同时虚拟给多个证书使用，此时Nginx和SLB同时开启SNI支持，这类问题的排查难度在于，HTTP/2的连接复用会让旧证书失效但连接不释放，表现是页面时好时坏，很难抓到规律，处理方法是开启Nginx日志中的SSL变量，定位到具体的协议指纹和证书序列号。
简单列一下排查命令：
tail -f /var/log/nginx/access.log # 确认请求对应的server_name和SSL协议版本 grep "TLS" /var/log/nginx/error.log
结尾前聊一句成本与性能的真实感受
最后谈一个多数人忽略的性能点：多证书场景下，TLS握手次数比证书数量更值得关注，多个证书意味着多个TLS握手类型，ECDHE类型的握手明显比RSA的握手慢，但安全性更高，如果你追求极致性能，可以开启TLS会话缓存和TLS票据：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_session_tickets on;
这个配置能极大减少握手次数,在证书数量较多的场景下收益很明显。
负载均衡多证书方案对比与常见疑问解答
针对这类部署,你可能还有几个具体问题想确认，这里把高频问题整理成问答，帮你一步到位。
Q1：一个负载均衡实例最多能绑定多少张证书？
这取决于负载均衡硬件或云厂商平台,云SLB根据规格不同，上限一般在几十到几百张证书，且默认的SNI扩展域名数有配额限制，Nginx这类软件负载均衡的证书数量几乎没有限制，但受到内存和CPU性能的制约，一张证书需要额外的内存存储和解析时间，数量太大时需要做性能压测确定上限。
Q2：多证书模式下，如果SLB和Nginx都配置了多证书，优先使用哪一层？
流量达到后端Nginx时,Nginx已经能拿到客户端的SNI信息，所以Nginx会按照自己配置文件中的匹配规则选择证书，正常情况下，SLB只是用默认证书走了个过场，后端Nginx才是真正做证书决战的地方，但要注意，如果SLB监听器开启了“后端证书透传”或“SSL卸载”选项，行为会不一样，推荐的做法是：SSL终结在SLB，后端用HTTP，证书规划简单可控；如果业务有合规要求必须全程加密，就得在SLB和Nginx各配置一套证书，但这样成本会翻倍。
Q3：负载均衡上更新证书需要重启服务吗？
不需要重启服务,无论是云SLB的控制台替换证书，还是Nginx的平滑重载，已经建立的TLS连接都不会中断，新连接会立即使用新证书，旧连接等待超时后自然断开，这个过程对用户无感。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/585301.html
