本文說明通訊協定傳輸層安全性 （TLS） 和數位證書的詳細數據。
傳輸層安全性 (TLS)
TLS 和 SSL 通訊協定位於應用通訊協定層與 TCP/IP 層之間，可在其中保護應用程式數據，並將應用程式數據傳送至傳輸層。 TLS/SSL 通訊協定會使用 加密套件 中的演算法來建立密鑰和加密資訊。 用戶端和伺服器會交涉通訊協定版本和加密套件，以在連線建立的初始連線（登入前）階段進行加密。 TLS 交握中一律偏好最受支援的 TLS 版本。 若要檢查不同 Windows作系統版本支援的 TLS 通訊協定版本，請參閱 TLS/SSL 中的通訊協定（安全通道 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）。 如需詳細資訊，請參閱 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 購買而來。 | 憑證部署已簡化，因為所有用戶端、裝置和伺服器都會自動信任憑證。 | 成本。 您必須事先規劃將所需的憑證數目降至最低。 |
為了證明憑證持有者是宣稱的持有者，憑證必須向其他用戶端、裝置或伺服器正確地識別憑證擁有者。 下表說明執行這項作的三種基本方法：
| 方法 | 說明 | 優點 | 缺點 |
|---|---|---|---|
| 憑證主體相符 | 憑證的 Subject 欄位包含主機的一般名稱 (CN)。 例如，發給 www.contoso.com 的憑證可用於網站 https://www.contoso.com。 |
- 與所有客戶端、裝置和服務相容。 -劃分。 撤銷主機的憑證並不會影響其他主機。 |
- 所需的憑證數目。 您只能將憑證使用於指定的主機。 例如，即使服務安裝在同一部伺服器上，您也無法使用 www.contoso.comftp.contoso.com憑證。-複雜性。 在 Web 伺服器上，每個憑證需要自己的 IP 位址繫結。 |
| 憑證主體別名 (SAN) 相符 | 除了 Subject 欄位，憑證的 Subject Alternative Name 欄位包含多個主機名稱的清單。 例如：www.contoso.comftp.contoso.comftp.eu.fabrikam.net |
-方便。 您可以將相同的憑證使用於多個不同網域中的多部主機。 - 大部分的用戶端、裝置和服務都支援 SAN 憑證。 - 稽核和安全性。 您完全知道哪些主機能夠使用 SAN 憑證。 |
- 需要更多規劃。 在建立憑證時，您需要提供主機清單。 - 缺乏分隔。 您無法選擇性地撤銷某些指定主機的憑證，而不影響憑證中的所有主機。 |
| 萬用字元憑證相符 | 憑證的 [主體] 字段包含通配符 (*) 加上單一網域或子域的通用名稱。 例如，*.contoso.com 或 *.eu.contoso.com。
*.contoso.com通配符憑證可用於：www.contoso.comftp.contoso.commail.contoso.com |
彈性。 當您要求憑證時，不需要提供主機清單，而且您可以在未來可能需要的任何數目的主機上使用憑證。 | - 您無法將通配符憑證與其他頂級域名一同使用。 例如，您無法將 *.contoso.com 通配符憑證用於 *.contoso.net 主機。您只能在與通配符相同層級的主機名上使用通配符憑證。 例如，您無法將 *.contoso.com憑證用於www.eu.contoso.com。 或者，您無法針對 *.eu.contoso.com使用www.uk.eu.contoso.com憑證。- 較舊的用戶端、裝置、應用程式或服務可能不支援通配符憑證。 - 擴展驗證（EV）憑證不支援通配符。 - 需要仔細的稽核和控制。 如果萬用字元憑證遭到入侵時，則會影響指定網域中的每個主機。 |