一台服务器如何配置多个 SSL 证书

一、正确解决办法：登陆淘宝Gworg选择多域名SSL证书就可以，首先普通的服务器无法实现一台安装多个独立的SSL证书的。

二、技术颁发：IIS8、apache最新版除外，虽然可以安装多个独立的证书，但对CPU、内存会消耗一些，如果长期的大站还是选择通配证书或者多域名证书。

三、常见应用环境：目前一台服务器支持安装多个SSL证书的是：宝塔BT、WDCP（以上仅支持PHP语言为主）

IP直连可以避免localDNS解析导致的DNS劫持，但是在iOS中不仅仅是将host直接换成IP地址就可以了，还有以下需要注意的问题。

发送HTTPS请求首先要进行SSL/TLS握手，握手过程大致如下：

上述过程中，和HTTPDNS有关的是第3步，客户端需要验证服务端下发的证书，验证过程有以下两个要点：

如果上述两点都校验通过，就证明当前的服务端是可信任的，否则就是不可信任，应当中断当前连接。 当客户端使用HTTPDNS解析域名时，请求URL中的host会被替换成HTTPDNS解析出来的IP，所以在证书验证的第2步，会出现domain不匹配的情况，导致SSL/TLS握手不成功 。

针对 domain不匹配 问题，可以采用如下方案解决：hook证书校验过程中第2步，将IP直接替换成原来的域名，再执行证书验证。

方法为在客户端收到服务器的质询请求代理方法 -URLSession:task:didReceiveChallenge:completionHandler: 中，首先从header中获取host(第一点注意事项：HTTP请求头HOST字段设置)，从header中如果没有取到host，就去URL中获取host(降级为LocalDNS解析时不进行替换)，然后拿着host在自己的方法-evaluateServerTrust:forDomain:中创建SSL Policy证书校验策略，然后对证书进行校验。

SNI（Server Name Indication）是为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。它的工作原理如下：

在连接到服务器建立SSL链接之前先发送要访问站点的域名(Hostname)，服务器根据这个域名返回一个合适的证书。

目前，大多数操作系统和浏览器都已经很好地支持SNI扩展，OpenSSL 098也已经内置这一功能。

上述过程中，当客户端使用HTTPDNS解析域名时，请求URL中的host会被替换成HttpDNS解析出来的IP，导致SSL/TLS握手中服务器接收到的客户端发出的clientHello中的SNI为host解析后的IP，从而无法找到匹配的证书，只能返回默认的证书或者不返回，所以会出现SSL/TLS握手不成功的错误。

比如当你需要通过HTTPS访问CDN资源时，CDN的站点往往服务了很多的域名，所以需要通过SNI指定具体的域名证书进行通信。

SNI（单IP多HTTPS证书）场景下，iOS上层网络库 NSURLConnection/NSURLSession 没有提供接口进行 SNI 字段 配置，因此需要 Socket 层级的底层网络库例如 CFNetwork，来实现 IP 直连网络请求适配方案。苹果提供的一些指导，在 Networking Programming Topics 中，可以通过如下方式指定一个TLS hostname：

我们使用CFNetwork进行HTTP网络请求的方法，详见 [2] 。

Apple - Communicating with HTTP Servers

Apple - HTTPS Server Trust Evaluation - Server Name Failures

Apple - HTTPS Server Trust Evaluation - Trusting One Specific Certificate

[1]:HTTPS场景IP直连方案说明

[2]:使用CFNetwork进行HTTP请求

SNI指是一项用于改善SSL/TLS的技术，在SSLv3/TLSv1中被启用。它允许客户端在发起SSL握手请求时（具体说来，是客户端发出SSL请求中的ClientHello阶段），就提交请求的Host信息，使得服务器能够切换到正确的域并返回相应的证书。

上面这句哪都有，没什么含金量。下面是我的理解。

SSL网站用的证书，提交到web服务器时，原本设计的是按服务器IP+端口来提交的。这样就造成了同一服务器IP的443端口，只能用一个证书。这样设计比同一IP和端口的，多主机头设计差太多。于是提出SNI标准，以后新的SSL和服务器，允许用主机头 + 端口方式提交到同一服务器上，这样就灵活多了。

不支持服务器方式可以采取：独服务器端口实现，如：331端口1个SSL证书，332端口1个SSL证书。

特定环境：

1、可以使用windows 2012以上操作系统IIS8以上支持安装多个SSL证书。

2、服务器操作系统Linux，CentOS 6+ OpenSSL 101c+以上可以部署多个独立的SSL证书，缺陷就是该服务器环境仅支持Apache、Nginx、Tomcat属于在脚本语言上有一些限制，不过经常使用PHP或者js一样的非常适合。

不建议说明：SSL证书出现到期会手忙脚乱，无法管理。通常申请多域名SSL证书，1个SSL证书可以保护多个域名，方便管理与认证续费，减轻后期替换证书，维护证书的一些工作。

文 中国互联网络信息中心 姚 健康

一、国际互联网工程任务组是互联网技术协议发展大本营

互联网的发展改变了世界。互联网运行的核心技术标准和核心技术协议主要来自国际互联网工程任务组（IETF）。IETF 创立于 1986 年初，是负责制订互联网方面技术标准的重要组织，主要任务是负责互联网相关技术标准的研发和制定，超过90% 的互联网技术标准由其制定。IETF 通过技术标准的制定，保障了互联网的长期稳定运行。IETF大量的技术性工作均由其内部的各种工作组（WG）承担和完成。这些工作组依据各项不同类别的研究课题而组建。在成立工作组之前，IETF 通常会先设立兴趣小组（BOF）开展工作组筹备工作。筹备工作完成后，经过 IETF 高层研究认可，可正式成立工作组。IETF 汇聚了全球顶尖的互联网技术工程师，每年举行三次会议，参会规模均在千人以上。

互联网架构委员会（IAB）成立于 1983 年，是 IETF 的最高管理机构，由包括 IETF 主席在内的 13 名委员组成。IAB 的主要职责之一是负责互联网协议体系结构的监管，把握互联网技术的长期演进方向，保护互联网的长期发展，负责确定互联网标准的制订规则，指导互联网技术标准的编辑出版，负责互联网的编号管理，并协调与其他国际标准化组织的工作。

IETF 将工作组分类为不同的领域，每个领域由几个领域主任（Area Director）负责管理。领域主任组成互联网工程指导委员会（IESG），具体领域如下。

一是应用和实时研究领域（Applications andReal-Time Area）。该领域主要研究应用层相关的标准，也包括实时相关的网络协议。

二是通用研究领域（General Area）。该研究领域用于包括不适合放在其他研究领域的研究内容。

三是网际互联研究领域（Internet Area）。网际互联研究领域主要研究 IP 数据包如何在不同的网络环境中进行传输。

四是运营管理研究领域（Operations andManagement Area）。该研究领域主要涉及互联网的运营与管理方面的内容。随着互联网的快速发展与普及，对网络的运营与管理提出了更高的要求，因此，该研究领域也越来越受到重视。

五是路由研究领域（Routing Area）。该研究领域主要负责制订如何在网络中确定传输路径以将IP 数据包路由到目的地的相关标准。

六是安全研究领域（Security Area）。该研究领域主要负责研究 IP 网络中的授权、认证、审计等与私密性保护有关的协议与标准。互联网的安全性越来越受到人们的重视，因此，该领域也成为IETF 中最活跃的研究领域之一。

七是传输研究领域（Transport Area）。该领域主要负责研究特殊类型或特殊用途的数据包在网络中的端到端的传输方式。

在上述领域，除了安全研究领域专门研究安全技术以外，其他领域也会涉及安全问题。如何提高互联网技术协议的安全是 IETF 长期研究的重点议题。

二、互联网基础资源技术协议利用公钥信任链加强安全

IETF 互联网基础资源技术协议从默认信任数据转向保障数据来源可信、数据完整和防篡改等方向发展。

（一）域名系统协议利用公钥信任链加强安全

域名系统协议（DNS）是互联网的核心协议，是一种将域名映射为某些预定义类型资源记录（如IP 地址）的分布式互联网服务系统。作为一种互联网应用层的资源寻址基础服务，域名服务是其他互联网络应用服务的基础。常见的互联网络应用服务如网页远程访问服务、电子邮件服务、文件远程访问服务等一般都以域名服务为基础，实现资源的寻址和定位。

DNSSEC 协议是一个针对 DNS 协议的安全扩展，它通过给 DNS 的应答消息添加基于非对称加密算法的数字签名，保证数据未经篡改且来源正确；再通过域名体系自下而上逐级向父域提交自己公共密钥，实现整个域名体系的逐级安全认证。DNSSEC 为 DNS 数据提供了三方面的安全保障：一是数据来源验证，保证 DNS 应答消息来自被授权的权威服务器；二是数据完整性验证，保证 DNS 应答消息在传输途中未经篡改；三是否定存在验证，当用户请求一个不存在的域名时，DNS服务器也能够给出包含数字签名的否定应答消息，以保证这个否定应答的可靠性。

综上所述，DNSSEC 本质上是在域名系统树型授权体系的基础上，再建立一套基于密码学手段的签名/验证体系，也就是信任链体系，通过信任链上的逐级安全验证，确保 DNS 查询结果的真实可靠性、数据完整性和非否认性。

互联网名称与数字管理机构（ICANN）一直在全球推进 DNSSEC 的部署，2010 年 7 月，ICANN 正式用 DNSSEC 签署根域。为了更好地管理根密钥，ICANN 制订了根密钥管理计划。该计划在全球选择信任社区代表（TCR），负责生成管理根密钥。ICANN 一共选出 21 名 TCR 和一些后备TCR，所有的候选人都是来自互联网社区的个人。其中 14 名 TCR 是密码管理员（CO），美国东海岸和西海岸各 7 名，负责参与生成根密钥。另外 7名 TCR 是恢复密钥持有人（RKSH），负责硬件安全模块（HSM）内容的备份和管理，用于紧急状态时候恢复 HSM 工作状态。2010 年 6 月，在美国弗吉尼亚州的库尔佩珀（Culpeper）召开了全球第一次 DNSSEC 根密钥生成仪式会议。

ICANN 有两套完全相同的 HSM，分别放在美国东海岸和西海岸，用于根密钥的生成。启动HSM 的密钥由 CO 保管。根密钥生成仪式，轮流在东西海岸进行。如果 HSM 出现问题或者根密钥出现紧急情况，需要 RKSH 赴美恢复 HSM，重新恢复根秘钥。根据 ICANN 制定的根密钥管理规则，没有 TCR 的参与，ICANN 是无法生成根密钥的。通过 TCR 的参与生成和管理根密钥，使 ICANN 的根密钥生成管理更加透明，形成了全球参与根密钥生成管理的局面。

DNSSEC 机制利用公钥信任链机制构建了可信的域名查询体系，全球根服务器中的互联网顶级域名数据需要利用根秘钥进行签名，保证数据的安全可信。DNSSEC 只是保证了 DNS 数据的可信性，但是，并没有对 DNS 数据本身进行加密。

（二）资源公钥基础设施协议通过公钥信任链应对路由通告伪造问题

作为支撑互联互通的互联网基础设施，域名系统和域间路由系统对互联网的安全有着至关重要的影响。由于边界网关协议（BGP）缺乏对路由通告内容真实性的保证，因此黑客的蓄意攻击以及错误的网络参数配置都可以导致路由劫持现象的发生。路由劫持对互联网的正常运行影响极大，可能导致大面积的网络瘫痪。于是，IETF 提出了资源公钥基础设施（RPKI）协议。RPKI 的概念最早便诞生于描述安全边界网关协议（S-BGP）方案的论文中。S-BGP 提出了一种附加签名的 BGP 消息格式，用以验证路由通告中 IP 地址前缀和传播路径上自治域（AS）号的绑定关系，从而避免路由劫持。基于这样的设计，数字证书和签名机制被引入BGP 范畴，并利用了公钥基础设施（PKI）。为验证路由通告签名者所持有的公钥，该签名者的 IP地址分配上级为其签发证书，一方面，验证其公钥，另一方面，验证该实体对某个 IP 地址前缀的所有权。基于 IP 地址资源分配关系而形成的公钥证书体系，RPKI 的基本框架就此形成。

RPKI 体系由三大关键模块组成：基础资源公钥证书体系（RPKI）、数字签名对象、储存 RPKI签名对象的分布式 RPKI 资料库。这三大模块能够确保一个实体验证谁是某个 IP 地址或者 AS 号码的合法持有者。RPKI 可以使 IP 地址的合法持有者授权某个 AS 作为该地址的路由源，并进行验证。这种可以验证的授权，可以用来构建更加安全的路由表过滤项。

为了推动 RPKI 的部署，RPKI 架构充分利用了现有的技术和实践。RPKI 的结构可与现有的资源分配体系对应，可以看作是目前资源管理组织运行模式的自然技术延伸，而且现有的资源分配和回收方式在这套新体系中都有明确地相关定义。

（三）传输服务协议通过公钥信任链应对域名证书伪造和客户端认证问题

互联网上用于安全认证的证书一般由被称为认证机构（CA）颁发。然而，CA 模型比较容易受攻击，在互联网上受信任的 CA 有成千上万个，这些 CA 在理论上可以颁发任何一个证书。一个 CA可能存在恶意颁发或者错误颁发不属于互联网域名使用者的证书，从而形成中间人攻击，造成互联网安全的隐患。IETF 在 RFC6698 技术标准中提出了基于 DNS 的名字实体认证协议（DANE）技术，DANE 可以通过称为传输层安全认证（TLSA）的DNS 资源记录进行域名证书的认证和颁发，使只有控制域名的实际控制人才能颁发相应域名的安全证书，保证了 TLS 证书的安全。DANE 使用 DNSSEC基础设施存储和签署密钥，以及 TLS 使用的证书。DANE 提供了将公钥绑定到 DNS 域名的机制。由于管理公钥数据和管理DNS 域名的实体是同一个，减少了利用域名进行中间人攻击的机会。与域名关联的密钥只能由该父级域名密钥签名与关联。例如，“examplecn”钥匙只能由“cn”的密钥签名，“cn”的密钥只能由 DNS 根钥匙签名。任何域名的签名密钥都可以通过使用标准 DNSSEC 协议查询和分发签名密钥，通过 DANE 可以部署用户自签名证书。原本自签名证书被认为是不安全的，但是通过DNSSEC 的加持，针对域名自有域名的自签名证书在 DANE 里可以安全使用。

2021 年，IETF 又成立了网络客户端 DANE 认证（DANCE）工作组，利用 DANE 加强网络客户端相关协议的安全。目前，相关技术标准正在制定过程中。各种传输服务协议可以通过 DANE 机制中的公钥信任链应对域名证书伪造和客户端认证问题，使通信更加安全。

三、互联网基础资源技术协议向保护隐私化发展

2013 年的斯诺登事件爆发后，IETF 的最高技术管理机构 IAB 组织了专门的技术研讨会，研讨如何加强互联网的隐私保护，防止中间人进行窃听和信息截取。IAB 认为，IETF 的技术协议需要全面加强端到端的加密，以避免中间人攻击。此后，IETF 的各项协议都加强了安全的考虑，以保护用户的隐私不被中间人截取，推动互联网协议向保护隐私化发展。

（一）互联网传输协议向快速安全连接QUIC 协议演进

快速 UDP 互联网连接（Quick UDP InternetConnection，QUIC）协议是以谷歌开发和部署的网络协议为基础进行研究的基础传输协议，并被IETF 进行了标准化工作。谷歌认为传输控制协议（TCP）存在诸多问题，想设计一种新的传输协议，在 2012 年提出基于 UDP 进行设计的思路，并在2013 年 8 月发布的 Chromium 版本 29 中首次公开。QUIC 是众多对 TCP 进行完善的传输层网络协议之一。QUIC 协议于 2021 年 5 月正式发布，并编号为RFC9000。

QUIC 可以被认为是数据报传输应用程序。使用 QUIC 的应用程序协议使用 UDP 端口 443 发送和接收数据包。QUIC 很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，具有更好的安全性和低延迟性。QUIC 基于 UDP 传输，融合了包括 TCP、安全传输层协议（TLS）、超文本传输协议第 2 版（HTTP/2）等协议的特性，使传输协议更加高效。QUIC 的一个主要目标就是减少连接延迟，当客户端第一次连接服务器时，QUIC 只需要 1 次往返时延（RTT）的延迟就可以建立可靠安全的连接，相对于 TCP+TLS 的 1 3次 RTT，前者要更加快捷。之后，客户端可以在本地缓存加密的认证信息，当再次与服务器建立连接时，可以实现 0 RTT 的延迟。QUIC 同时重复使用了 HTTP/2 协议的多路复用功能，而且利用 UDP 成功避免了 HTTP/2 的队头阻塞问题。

（二）DNS 传输协议向保护用户隐私方向发展

由于 DNS 的明文设计，因此用户查询域名DNS 数据会泄露用户的行为，同时，第三方服务器会收集用户的查询日志，DNS 隐私保护方面的技术发展主要包括 2 个方面。

一是查询最小化机制。即递归解析器每次只发送必要的查询信息，不向根和顶级服务器暴露完整的域名。同时，有研究者提出，将每次真实的查询混淆在多个虚拟查询中，及服务器主动进行热点域名广播等方法，用来缓解用户隐私泄露的风险。

二是基于 HTTPS 的 DNS（DoH）和基于 TCP的 DNS（DoT）机制，分别利用 HTTPS、TCP 技术，实现 DNS 的加密，二者的底层都是基于 TLS。目前，二者已相继发布为 IETF RFC 技术标准。IETF 成立DNS 隐私传输交换工作组，专门研究 DNS 隐私保护相关的课题，基于 QUIC 的 DNS（DoQ）也在该工作组推动过程中。另一方面，HTTP-over-QUIC已被命名为 HTTP/3。DoH/DoT 发布为正式标准后，IETF 隐私相关的议题主要集中在对具有加密技术的解析器的自动发现及递归到权威解析器的隐私加密机制研究方面。

（三）传输层安全协议进行扩展以支持更隐私化技术

TLS 13 是 IETF 制定的 TLS 新标准。TLS 用于保护 Web（以及更多其他领域），提供加密并确保每个 HTTPS 网站和应用程序编程接口（API）的真实性。TLS 13 所属的 RFC 8446 标准在 2018 年发布，这是该协议的第一次重大改革，带来了重大的安全性和性能改进。TLS 13 基于更早的 TLS 12，但与 TLS 12 也有较大的 区 别， 例 如，TLS13 可以减少协议握手的延迟时间，提高抗攻击性，设计将密钥协商和认证算法从密码包中分离出来，移除脆弱和较少使用的算法，例如移除信息摘要算法 （MD5）和安全散列算法（SHA-224）的支持等。TLS13 将大部分传输信息进行了加密处理，但是 TLS 13 提供的服务器名字指示信息（SNI）并未在发送客户端问候（ClientHello）会话时加密。第三方可以轻松获取 TLS 13 双方交换信息时的服务器名字指示信息。IETF 目前正在推动如何把服务器名字指示信息（SNI）也进行加密的技术（ECH）。如果 ECH技术部署后，通信双方的服务器名字指示信息（SNI）将进行加密，第三方很难获知 SNI 信息，使双方通信更加隐私化。

四、互联网基础资源技术协议向全面安全可信发展

互联网已经融入了生活和工作的方方面面，互联网传输的数据越来越重要。互联网基础资源技术协议的数据从明文传输方式，逐步过渡到认证明文数据的来源可靠性、完整性和防篡改性，并对部分核心数据进行了加密，对有些协议参数也进行了加密。通过签名、信任链和加密等方式保证了互联网数据传输的可靠性和安全性，减少了中间人获取隐私信息的可能。基于上述分析，可以有以下判断。

一是 QUIC 协议展现了比 TCP 协议更好的性能，互联网的 TCP 协议有可能被 QUIC 协议逐步取代。在未来十年，QUIC 协议将逐步蚕食 TCP 协议的领地，更多的应用程序将基于 QUIC 协议传输而不是 TCP 协议。

二 是 TLS 13 协议正在逐步得到部署，逐步取代旧版本的协议，如果未来配合ECH 技术的部署，使互联网的端到端传输更加安全可靠，但是这项技术可能导致利用服务器名字指示信息（SNI）进行安全策略管理的防火墙的部分功能失效。

三是 RPKI 由于存在信任链和信任锚的安全管理问题，短期内很难得到大规模部署。如果 RPKI操作不当，证书错误配置或者恶意撤销也会引发一系列的安全问题。

四是自从互联网全球域名根区部署 DNSSEC技术十多年以来，由于技术部署投入和带来的收益不成正比，因此目前部署率不是很高。在下一个十年，如果没有关键应用的支持，DNSSEC 也很难进行大规模普及应用。

（本文刊登于《中国信息安全》杂志2022年第4期）

如果您在服务器上为某个站点添加了SSL证书，其他未添加证书的站点仍然可以访问到该站点，这可能是由以下原因导致的：

1 SSL证书未正确配置：请检查您的SSL证书配置是否正确。确保SSL证书已正确安装在服务器上，并且已正确配置到相应的站点。

2 SSL证书未过期：请检查您的SSL证书是否已过期。如果SSL证书已过期，其他未添加证书的站点可能仍然可以访问到该站点。

3 SSL证书未吊销：请检查您的SSL证书是否已被吊销。如果SSL证书已被吊销，其他未添加证书的站点可能仍然可以访问到该站点。

4 服务器配置问题：请检查服务器的配置是否正确。确保服务器已正确配置SSL证书，并且已启用SSL加密。

5 网络问题：请检查网络连接是否正常。如果网络连接不稳定，可能会导致其他未添加证书的站点仍然可以访问到该站点。

为了解决这个问题，您可以尝试以下方法：

1 检查SSL证书配置：确保您的SSL证书配置正确，包括证书文件路径、证书私钥文件路径、证书链等。

2 检查SSL证书有效期：确保您的SSL证书未过期，并且已过期的证书已被正确替换。

3 检查SSL证书吊销状态：确保您的SSL证书未被吊销，并且已被吊销的证书已被正确替换。

4 检查服务器配置：确保服务器已正确配置SSL证书，并且已启用SSL加密。

5 检查网络连接：确保网络连接稳定，以便其他未添加证书的站点仍然可以访问到该站点。

如果问题仍然存在，请联系服务器提供商或技术支持团队，以获取更详细的帮助。