資安弱掃跑完，報告上一條紅字：偵測到過時的 SSL/TLS 協定。很多人看到就把 TLS 1.0、1.1、1.2 全關掉，只留 TLS 1.3——想說版本越新越安全。

問題就出在這：弱掃從來沒叫你關 TLS 1.2。把 1.2 一起關掉、只留 1.3，在 Windows 伺服器環境幾乎一定出事——網站連不上、SQL Server 連不上、舊的內部系統全掛。下面拆解為什麼，以及正確的做法。

先搞清楚：弱掃到底要你關什麼

弱掃報告寫「過時的 SSL/TLS 協定」，指的幾乎都是 SSL 2.0/3.0 和 TLS 1.0、1.1。這幾個有已知的結構性弱點（POODLE、BEAST 那一掛），該關。

TLS 1.2 不在這個清單裡。它到現在仍然安全、主流、被廣泛支援。常見的合規型弱掃通常不會要你停用 TLS 1.2。

法規這邊也說得很清楚。PCI DSS 4.0 的要求是「TLS 1.2 或更高」，把 SSL 和 early TLS（1.0/1.1）列為不合規。它從來沒要求你用 TLS 1.3——TLS 1.2 完全合規。所以「只留 TLS 1.3」這種建議，不是弱掃的要求，是誤讀。

為什麼「只留 1.3」會弄掛系統

撇開合規不談，純粹從技術可行性看，在 Windows 伺服器環境只留 TLS 1.3 也行不通。一層一層看。

作業系統這層

TLS 1.3 在 Windows 的 Schannel 裡，只有 Windows 11 和 Windows Server 2022 之後才原生支援。Windows Server 2019、2016 連這個協定都沒有。

所以如果你的機器是 Server 2019，在登錄檔裡「啟用 TLS 1.3」是沒有意義的——系統根本不會拿它協商。你以為開了，其實沒開；接著又把 1.2 關了，這台機器一個現代協定都不剩。

資料庫這層

SQL Server 更要小心。TLS 1.3 要 SQL Server 2022、加上累積更新 CU1 以後、跑在 Windows Server 2022 上、連線走 TDS 8.0（連線字串加 Encrypt=Strict），四個條件同時成立才支援。SQL Server 2019 與更早版本不支援。

更關鍵的一點：就算 SQL Server 2022 已經支援 TLS 1.3，微軟仍明確要求保留 TLS 1.2——因為衛星服務（像 SSIS、SSAS）啟動時需要 1.2。把 1.2 關掉，這些服務起不來。在有 SQL Server 的環境裡，TLS 1.2 基本上動不得。

應用程式執行環境這層

往上到應用層，同樣卡版本：

  • Java 要 JDK 11 以上才預設支援 TLS 1.3；Java 8 本身預設沒有，要更新到 8u261 或更新版本才補進來。
  • .NET Framework 要 4.8、而且跑在 Windows 10/11 上才能用 TLS 1.3，因為它實際靠底層 Schannel。更舊的框架版本頂多到 TLS 1.2。

只要環境裡還有一個沒跨過這條線的元件，「只留 1.3」就會在那裡斷掉。

正確的做法：淘汰舊的，守住 1.2

目標講清楚：要關的是 SSL 和 TLS 1.0、1.1；要保留的是 TLS 1.2；TLS 1.3 是有條件才加開，不是拿來取代 1.2。

先查目前的協定狀態（這步只看現狀、不改設定）：

1
2
# 列出 Schannel 底下所有 TLS/SSL 協定的啟用狀態
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" /s

真正要停用 1.0/1.1 時，得在每個協定的 Server 和 Client 兩個子機碼都寫兩個 DWORD 值：Enabled = 0、DisabledByDefault = 1。手動改登錄檔很容易漏，型別建錯（建成字串）設定還會無效。我的建議是直接用 IIS Crypto 這類工具套用 best practice 範本，它會把協定和 cipher suite 一起處理好，比手刻登錄檔安全。

這裡有個容易忽略的坑：關掉舊協定後，舊版 Windows（Server 2016 以前）的預設 cipher suite 順序，有時會讓某些 TLS 1.2 連線協商失敗——你以為是 TLS 版本問題，其實是 cipher 沒跟上。這也是用 IIS Crypto 連 cipher 順序一起調比只改協定保險的原因。

執行順序我會這樣排：

  1. 盤點。列出所有要連線的系統和它們的 OS、資料庫、執行環境版本，確認誰支援到哪。沒盤點就動手是最常見的災難來源。
  2. 備份。改之前先 reg export 把 SCHANNEL 整棵匯出，出事能立刻還原。
  3. 測試環境先跑。複製一份實際環境，關掉 1.0/1.1、保留 1.2，把關鍵流程跑一遍。
  4. 分批上。低風險系統先做，核心系統最後，每改一台測一台。

改完怎麼確認有沒有生效？對外網站可以用 SSL Labs 掃一遍看實際協商到哪個版本；內網服務用 openssl s_client -connect 主機:443 -tls1_2 指定協定測試，能握手成功就代表這個版本還通，反過來用 -tls1 應該要被拒絕。

TLS 1.3 什麼時候加開？等那台機器的 OS 是 Server 2022、資料庫是 SQL Server 2022 CU1 以上、應用框架也都跟上了，再把 1.3 開起來和 1.2 並存——是並存，不是替換。

收尾

現階段在 Windows 伺服器環境，正確的目標不是「升級到 TLS 1.3」，而是淘汰 1.0/1.1、守住 1.2、有餘力再加 1.3。等整個技術棧——作業系統、資料庫、執行環境——都跨過 Server 2022 那條線，再評估能不能逐步減少對 1.2 的依賴。在那之前，看到弱掃報告先深呼吸：要關的是 1.0 和 1.1，不是 1.2。