如何为东莞高防服务器上的多个网站配置不同的SSL证书?

去年年底，东莞南城一家做跨境电商园区的技术负责人阿杰，给我发来了一条长长的微信语音。他说他们园区里入驻了二十多家小型电商公司，都在同一台高防服务器上托管着各自的网站。之前一直用HTTP，倒也相安无事。但今年各大浏览器开始对HTTP网站标记“不安全”，租户们纷纷要求给自己的网站配上HTTPS。阿杰原本以为很简单，每个网站申请一个证书装上去就行了。结果配置的时候傻了眼，服务器只有一个公网IP，443端口只能被一个站点占用，这二十多个网站的SSL证书怎么共存?

阿杰遇到的这个问题，在东莞这个制造业和电商产业高度发达的城市里非常普遍。从虎门的服装电商到长安的电子配件批发，从厚街的家具商城到大朗的毛织交易平台，越来越多的企业开始重视网站的数据传输安全。但当多个网站共享同一台高防服务器的时候，如何给每个网站配置独立且正确的SSL证书，就成了很多技术人员的拦路虎。

我今天就想结合自己在东莞本地帮助各个企业解决这个问题的真实经历，把其中的原理、方法和注意事项，掰开揉碎了讲清楚。

先弄明白一个核心问题：为什么多个SSL证书不能直接共存

很多人想当然地认为，只要把不同网站的SSL证书都上传到服务器上，然后在配置文件里分别指定就行了。结果配置完一测试，发现不管访问哪个域名，浏览器展示的都是同一个证书，然后弹出“证书与域名不匹配”的安全警告。

为什么会这样呢?这要从HTTPS的握手过程说起。当客户端(比如用户的浏览器)访问一个HTTPS网站时，它会先和服务器建立一个TCP连接，然后开始TLS握手。在握手过程中，服务器需要向客户端出示自己的SSL证书。问题在于，服务器怎么知道客户端想访问的是哪个域名呢?因为在TLS握手这个阶段，客户端还没有发送HTTP请求，服务器根本不知道用户想访问的是siteA.com还是siteB.com。

这就好比你去一个写字楼，保安在门口问你找谁，但你还没说是去几楼几号，保安就不知道该给你刷哪张门禁卡。在传统的HTTPS配置下，一个IP地址的一个端口(默认是443端口)只能绑定一张SSL证书。这就造成了“一个IP一张证”的尴尬局面。

那么，这个问题有解吗?当然有。SNI技术就是专门为解决这个问题而生的。

SNI技术：多证书共存的核心基石

SNI的全称是服务器名称指示，它是TLS协议的一个扩展，目的就是为了解决一个服务器上托管多个HTTPS网站的问题。

SNI的工作原理其实不复杂。在支持SNI的浏览器和服务器之间，握手过程会多出一个步骤：当浏览器发起TLS握手时，它会在握手请求中附带一个信息，告诉服务器“我要访问的是siteA.com”。服务器收到这个信息之后，就可以根据这个域名去查找对应的SSL证书，然后用正确的证书来回应浏览器。

我把这个过程简化一下，方便你理解。客户端发起连接时说：“我要找siteA.com”。服务器收到后翻出自己的证书清单，找到siteA.com对应的那张证书，然后用这张证书与客户端完成握手。客户端发起另一个连接说：“我要找siteB.com”。服务器又去翻证书清单，找到siteB.com对应的那张证书。整个过程对用户来说是无感知的，用户只会看到浏览器地址栏里的小锁图标安安静静地待在那里。

目前主流的操作系统和浏览器都已经支持SNI，包括Windows、macOS、iOS、Android，以及Chrome、Firefox、Safari、Edge等主流浏览器。这意味着你不用担心用户的浏览器不支持这个功能，绝大多数情况下都是默认支持的。

但是有一点要特别注意，那就是高防服务器和SNI的兼容性问题。有些老旧的或者特殊架构的高防防护系统，在处理SNI的时候可能会有一些奇怪的行为。东莞一家做游戏平台的公司就踩过这个坑，后面我会详细讲到。

方案一：使用支持SNI的高防架构

解决多个SSL证书共存问题，最标准、最推荐的做法，就是使用支持SNI的高防服务器或者高防CDN。

在一个典型的高防架构中，用户访问请求是先到达高防节点的，高防节点经过清洗和过滤之后，再把干净的请求转发给源服务器。如果你的高防节点支持SNI，那你只需要在高防节点上配置多张SSL证书就可以了。源服务器甚至不需要配置HTTPS，回源用HTTP都可以。

具体怎么操作呢?我以常见的支持SNI的高防产品为例，把步骤拆解一下。

第一步，登录高防服务器的管理控制台，找到域名接入或者证书管理的功能模块。

第二步，上传你每个网站的SSL证书。一般来说，你需要准备两种格式的材料，一种是证书文件，通常以点crt或者点pem结尾，另一种是私钥文件，通常以点key结尾。有些高防平台还需要上传证书链文件，也就是中间证书和根证书。

第三步，在添加域名或者配置转发规则的时候，把域名和对应的证书关联起来。比如你添加siteA.com这个域名，然后从证书列表里选择siteA.com的那张证书。添加siteB.com，就选择siteB.com的证书。如果高防平台支持泛域名证书，你也可以用一个点siteA.com这样的泛域名证书来覆盖所有以siteA.com结尾的子域名。

第四步，配置转发规则，把经过高防节点解密后的请求转发给你的源服务器。回源可以用HTTPS，也可以用HTTP。如果你不想在源服务器上再配置一遍SSL证书，那就选HTTP回源。但要注意，HTTP回源意味着从高防节点到源服务器这一段网络是明文的，如果你的业务对安全性要求极高，或者这段网络跨越了不可信的网络环境，那还是建议配置HTTPS回源。

第五步，保存配置，等待生效。一般来说，高防平台上的域名配置会在几分钟之内生效。生效之后，用浏览器访问你的网站，检查地址栏里的小锁图标是否正常，点击小锁查看证书信息，确认是你配置的那张证书。

这个方案的优点是配置集中、管理方便，所有SSL证书都在高防节点上统一管理，源服务器不需要做任何HTTPS相关的配置。缺点是依赖于高防平台对SNI的支持程度，不同服务商的实现细节可能不太一样，有些平台可能对泛域名的匹配规则有特殊限制。

方案二：源服务器Nginx多域名SSL配置

如果你使用的高防服务器或者高防CDN不支持SNI，或者你对证书管理有特殊的要求，还有另一个方案可以选择。那就是在高防节点上只做TCP层的端口转发，把443端口的流量原封不动地转发给源服务器，然后在源服务器上配置Nginx，利用Nginx的SNI能力来区分不同的域名和证书。

这个方案的思路是，高防节点只负责清洗攻击流量，不参与TLS握手。TLS握手是在源服务器上完成的，而Nginx从很早的版本就开始支持SNI了，所以只要Nginx版本足够新，就能很好地处理多域名证书的问题。

具体操作步骤是这样的。

第一步，确认你的Nginx版本。在服务器上执行nginx -v命令，查看Nginx的版本号。SNI支持需要Nginx 0.9.8版本以上，并且编译时添加了--with-http_ssl_module参数。一般来说，只要不是特别老的发行版，默认的Nginx都是支持SNI的。

第二步，准备好每个域名的SSL证书文件。假设你有三个网站，分别是shopA.com、shopB.com和shopC.com，那你就需要三个证书文件和三把私钥文件。

第三步，编辑Nginx的配置文件。你可以把所有网站的配置都写在同一个配置文件里，也可以每个网站单独写一个配置文件，然后通过include指令包含进来。我个人的习惯是每个网站单独一个配置文件，放在/etc/nginx/conf.d/或者/etc/nginx/sites-enabled/目录下，这样管理起来更清晰。

每个网站的配置大概长这样：

对于shopA.com，配置文件中需要包含listen 443 ssl来监听HTTPS端口，用server_name shopA.com来指定这个配置块对应的域名，然后用ssl_certificate和ssl_certificate_key分别指定证书文件和私钥文件的路径。

对于shopB.com，也是类似的配置，只是server_name和证书路径不同。

第四步，配置完之后，执行nginx -t命令检查配置文件语法是否正确。如果显示syntax is ok，就可以执行nginx -s reload重新加载配置，让新的配置生效。

第五步，测试验证。用浏览器分别访问shopA.com、shopB.com和shopC.com，检查每个网站的小锁图标是否正常，证书信息是否正确。

这个方案的优点是灵活性高，不依赖于高防平台对SNI的支持，源服务器上可以自由配置各种复杂的证书策略。缺点也很明显，源服务器需要承担TLS握手的计算开销，而且每个源服务器上都要单独配置证书，如果有多个源服务器，证书管理的复杂度会上升。

两个易踩的坑，你一定要注意避开

无论选择哪种方案，有几个坑几乎是人人都会遇到的，我提前讲出来，希望能帮你少走弯路。

第一个坑是证书链不完整。这个问题特别隐蔽。你在浏览器里访问网站，小锁图标也是绿色的，看起来一切正常。但用SSL检测工具一扫描，或者某些用户访问的时候，就会报“证书链不完整”的错误。这是因为你的服务器只发送了网站证书，没有发送中间证书。浏览器需要从网站证书一路验证到根证书，中间缺了一环就会出问题。

解决方案是，在上传证书的时候，把中间证书和网站证书拼接在一起。大多数证书颁发机构在给你发放证书的同时，会提供一个中间证书文件。你需要用文本编辑器打开网站证书文件和中间证书文件，把中间证书的内容直接复制粘贴到网站证书内容的后面，然后把这个合并后的文件作为你的证书文件上传。证书的顺序是网站证书在前，中间证书在后，根证书可以不用包含，因为浏览器本地通常都有。

第二个坑是高防与SNI的兼容性问题。并不是所有高防产品都对SNI有良好的支持。东莞厚街一家做在线教育的公司就遇到过这个问题。他们在高防节点上配置了好几张SSL证书，结果用手机端的Safari浏览器访问的时候，死活匹配不对证书。排查了很久才发现，是他们用的那款高防产品在处理某些老旧客户端发起的没有携带SNI信息的TLS握手时，会默认返回第一张配置的证书，而不是根据域名匹配。

解决这个问题有几个办法。一个是在高防控制台查找是否有类似于“兼容模式”或者“非SNI客户端处理策略”的设置，有些平台允许你对不支持SNI的客户端返回默认证书或者拒绝连接。另一个办法是使用泛域名证书，用一个通配符证书覆盖所有子域名，这样即使SNI匹配失败，泛域名证书也能覆盖大部分场景。还有一个终极方案，就是切换到方案二，把TLS握手放在源服务器上完成。

选择哪种方案，关键看你的业务场景

说到这里，你可能会问，这两种方案到底该怎么选?我根据自己的经验，给你一些参考。

如果你使用的是主流云服务商的高防产品，比如那些技术实力比较强的厂商，它们通常都对SNI有完善的支持。你可以在高防节点上直接配置多张SSL证书，管理起来非常方便。这种情况下，方案一是首选。

如果你使用的是某些特殊架构的高防产品，或者你的源服务器分布在不同的机房、不同的服务商那里，统一在高防节点上管理证书反而增加了复杂度，那就可以考虑方案二。

另外，如果你的网站数量特别多，超过了几十个，那建议优先考虑使用泛域名证书或者多域名证书。泛域名证书用一张证书就能覆盖一个主域名下的所有子域名，比如点example.com的泛域名证书可以同时用于www.***.com、shop.***.com、blog.***.com等。多域名证书则是一张证书里绑定了多个完全不同的域名，比如一张证书同时保护***.com、***.net和***.org。这两种证书都能在一定程度上简化配置，减少证书数量。

总结

写到这儿，我想把今天讲的核心内容帮你梳理一下。

东莞高防服务器上给多个网站配置不同的SSL证书，核心是解决一个问题：在一个IP地址的443端口上，如何让服务器知道客户端想访问的是哪个域名。这个问题的答案就是SNI技术。

目前有两种主流的实现方案。一种是在高防节点上直接配置SNI和多张证书，流量在高防节点上解密后回源。这种方案配置集中、管理方便，但对高防平台的SNI支持能力有要求。另一种是在高防节点上做TCP转发，在源服务器的Nginx上利用SNI来区分域名和证书。这种方案灵活性高、不依赖高防平台的SNI能力，但源服务器需要承担更多的计算和管理责任。

无论选择哪种方案，都要注意证书链的完整性问题，以及高防与SNI的兼容性问题。这两个坑几乎人人都会踩，但只要提前知道，处理起来并不复杂。

对于东莞这座电商和制造业重镇来说，网站数据传输的安全性已经变得越来越重要。给每个网站配上正确的SSL证书，不只是为了让浏览器地址栏里多一把小锁，更是对用户数据的一种负责任的态度。