传输层安全和数字证书

本文介绍协议传输层安全性(TLS)和数字证书的详细信息。

传输层安全性 (TLS)

TLS 和 SSL 协议位于应用程序协议层和 TCP/IP 层之间,可在其中保护应用程序数据并将其发送到传输层。 TLS/SSL 协议使用 密码套件 中的算法来创建密钥和加密信息。 客户端和服务器协商在建立连接的初始连接(预登录)阶段用于加密的协议版本和密码套件。 在 TLS 握手中,始终首选受支持的最高 TLS 版本。 若要查看不同版本的 Windows作系统支持的 TLS 协议版本,请参阅 TLS/SSL 中的协议(Schannel SSP)。 已针对 SSL 和早期版本的 TLS 报告了多个已知漏洞。 建议升级到 TLS 1.2 以确保安全通信。

SQL Server 可以使用 TLS 来加密在 SQL Server 实例和客户端应用程序之间跨网络传输的数据。 TLS 使用证书实现加密。

启用 TLS 加密将增强通过网络在 SQL Server 实例与应用程序之间传输的数据的安全性。 但是,使用 TLS 加密 SQL Server 和客户端应用程序之间的所有流量时,需要执行以下额外处理:

  • 连接时需要额外的网络往返。
  • 从应用程序发送到 SQL Server 实例的数据包必须由客户端 TLS 堆栈加密,并由服务器 TLS 堆栈解密。
  • 从 SQL Server 实例发送到应用程序的数据包必须由服务器 TLS 堆栈加密,并由客户端 TLS 堆栈解密。

重要

从 SQL Server 2016(13.x)开始,安全套接字层(SSL)已停止使用。 请改用 TLS(建议使用 TLS 1.2)。 有关详细信息,请参阅 TLS 1.2 对 Microsoft SQL Server 的支持。 SQL Server 2022 引入了对 TLS 1.3 的支持。 有关详细信息,请参阅 TLS 1.3 支持。 如果客户端和服务器计算机之间不存在匹配的协议,则可以遇到 远程主机强行关闭了现有连接中所述的错误。

数字证书概述

数字证书是一种电子文件,其作用如同联机密码一样,可验证用户或计算机的身份。 数字证书用于创建客户端通信所用的加密通道。 证书是由证书颁发机构(CA)颁发的数字声明,用于保证证书持有者的身份,并使双方能够使用加密安全地通信。

数字证书提供以下服务:

  • 加密:它们有助于保护交换的数据免受盗窃或篡改。
  • 身份验证:验证其持有者 (人员、网站,甚至网络设备(如路由器) )是否是他们声称的身份或身份。 通常情况下,身份验证是单向的(即源验证目标的身份),而双向的 TLS 身份验证也是可以实现的。

证书包含一个公钥,并将此公钥与持有相应私钥的个人、计算机或服务的身份联系起来。 客户端和服务器使用这些公钥和私钥在传输数据前加密数据。 对于 Windows 用户、计算机和服务,如果已在受信任的根证书存储中定义根证书,并且证书包含有效的证书路径,那么就可建立对 CA 的信任。 如果证书尚未吊销(该证书不在 CA 的证书吊销列表中或 CRL 中)或过期,则被视为有效。

下表描述了三种主要类型的数字证书:

类型 DESCRIPTION 优点 缺点
自签名证书 证书由创建证书的应用程序签名,或使用 New-SelfSignedCertificate 创建。 成本(免费) - 客户端计算机和移动设备不会自动信任该证书。 需要手动将此类证书添加到所有客户端计算机和设备上的受信任的根证书存储,但并非所有移动设备都允许更改受信任的根证书存储。

- 并非所有服务都使用自签名证书。

- 难以为证书生命周期管理建立基础结构。 例如,无法吊销自签名证书。
内部 CA 颁发的证书 此类证书由组织中的公钥基础结构 (PKI) 颁发。 例如,Active Directory 证书服务 (AD CS)。 有关详细信息,请参阅 Active Directory 证书服务概述 - 允许组织颁发自己的证书。

- 成本低于来自商业 CA 的证书。
- 部署和维护 PKI 的复杂性增加。

- 客户端计算机和移动设备不会自动信任该证书。 需要手动将此类证书添加到所有客户端计算机和设备上的受信任的根证书存储,但并非所有移动设备都允许更改受信任的根证书存储。
商业 CA 颁发的证书 从受信任的商业 CA 购买的证书。 证书部署已简化,因为所有客户端、设备和服务器都会自动信任证书。 成本。 需要提前计划,以最大程度地减少所需的证书数。

为证明证书持有者与其所声称的身份相符,证书必须准确地向其他客户端、设备或服务器标识证书持有人。 下表介绍了执行此作的三种基本方法:

方法 DESCRIPTION 优点 缺点
证书使用者匹配 证书的" Subject "字段包含主机的公用名称 (CN)。 例如,颁发给 www.contoso.com 网站的证书可用于网站 https://www.contoso.com - 与所有客户端、设备和服务兼容。

-划分。 吊销主机的证书不会影响其他主机。
- 所需的证书数。 只能将证书用于指定的主机。 例如,即使在同一服务器上安装了服务,也不能将 www.contoso.com 证书用于 ftp.contoso.com

-复杂性。 在 Web 服务器上,每个证书都需要自己的 IP 地址绑定。
证书使用者可选名称 (SAN) 匹配 除了" Subject "字段之外,证书的" Subject Alternative Name "字段也包含多主机名列表。 例如:
www.contoso.com
ftp.contoso.com
ftp.eu.fabrikam.net
-方便。 可以将同一证书用于多个单独域中的多个主机。

- 大多数客户端、设备和服务都支持 SAN 证书。

- 审核和安全性。 你确切知道哪些主机能够使用 SAN 证书。
- 需要更多规划。 需要在创建证书时提供主机列表。

- 缺乏隔离。 不能在不影响证书中的所有主机的情况下选择性地撤销某些指定主机的证书。
通配符证书匹配 证书的 “使用者 ”字段包含通配符的公用名称 (*) 加上单个域或子域。 例如,*.contoso.com*.eu.contoso.com*.contoso.com通配符证书可用于:
www.contoso.com
ftp.contoso.com
mail.contoso.com
灵活性。 请求证书时,无需提供主机列表,并且可以在将来可能需要的任意数量的主机上使用该证书。 - 不能将通配符证书用于其他顶级域(TLD)。 例如,您不能使用*.contoso.com通配符证书来对*.contoso.net主机进行认证。

- 只能在通配符级别对主机名使用通配符证书。 例如,不能将 *.contoso.com 证书用于 www.eu.contoso.com. 或者,不能将 *.eu.contoso.com 证书用于 www.uk.eu.contoso.com.

- 旧客户端、设备、应用程序或服务可能不支持通配符证书。

- 通配符不适用于扩展验证(EV)证书。

- 需要仔细审核和控制。 如果通配符证书遭到入侵,将会影响指定域中的所有主机。