通过

传输层安全性和数字证书

  • 项目

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

传输层安全 (TLS) (Transport Layer Security) (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 实例与应用程序之间传输的数据的安全性。 但如果 SQL Server 与客户端应用程序之间的所有通信流量都使用 TLS 加密，则还需要进行以下额外处理：

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

重要

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

数字证书概述

数字证书是电子文件，其运行方式如同可验证用户或计算机身份的联机密码。 使用它们创建用于客户端通信的加密通道。 证书是由证明证书持有者的身份的证书颁发机构 (CA) 颁发的数字声明，它使各方可通过使用加密来安全地进行通信。

数字证书提供以下服务：

  • 加密：它们有助于保护交换的数据不被盗窃或篡改。
  • 身份验证：它们验证其持有者（用户、网站甚至是路由器等网络设备）自称的身份是否的确属实。 通常，身份验证是单向的，其中源会验证目标的身份，但也可以进行相互的 TLS 身份验证。

证书包含一个公钥，并将该公钥附加至用户、计算机或持有相应私钥的服务的身份。 公钥和私钥由客户端和服务器用于在数据传输前对数据进行加密。 对于 Windows 用户、计算机和服务，当在受信任的根证书存储中定义了根证书且该证书包含有效的证书路径时，将在 CA 中建立信任。 如果证书尚未被撤销（它不在 CA 的证书吊销列表或 CRL 中）或已过期，则将其视为有效。

数字证书的三种主要类型如下表所示：

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

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

- 很难建立用于证书生命周期管理的基础结构。 例如，不能撤销自签名证书。
由内部 CA 颁发的证书 该证书由组织中的公钥基础结构 (PKI) 颁发， 例如 Active Directory 证书服务 (AD CS)。 有关详细信息，请参阅 Active Directory 证书服务概述。 - 允许组织颁发他们自己的证书。

- 比来自商业 CA 的证书更便宜。		 - 增加了部署和维护 PKI 的复杂性。

- 证书不会被客户端计算机和移动设备自动信任。 需要手动将证书添加到所有客户端计算机和设备上的受信任的根证书存储中，但并非所有移动设备都允许更改受信任的根证书存储。
由商业 CA 颁发的证书 证书是从受信任的商业 CA 购买的。 证书部署简化，因为所有客户端、设备和服务器都自动信任证书。 成本。 需要提前制定计划，以将所需的证书数量降至最低。

若要证明证书持有者自称的身份属实，证书必须向其他客户端、设备或服务器准确地标识证书持有者。 下表中描述了实现此目的的三种基本方法：

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

- 隔离性。 撤销某个主机的证书不影响其他主机。		 - 所需的证书数。 只能将证书用于指定的主机。 例如，即使将服务安装在同一台服务器上，也不能对 ftp.contoso.com 使用 www.contoso.com 证书。

- 复杂性。 在 Web 服务器上，每个证书都需要有自己的 IP 地址绑定。
证书使用者可选名称 (SAN) 匹配 除了“使用者”字段之外，证书的“使用者可选名称”字段还包含多个主机名的列表。 例如：
www.contoso.com
ftp.contoso.com
ftp.eu.fabirkam.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) 证书。

- 需要进行仔细的审核和控制。 如果通配符证书泄露，它将影响指定域中的每台主机。

相关内容