Windows Server 2012 R2 已啟用 TLS 1.2，為什麼還是連不上 HTTPS API？

問題情境：TLS 1.2 明明開了，連線還是失敗

某些企業內部系統仍運行在 Windows Server 2012 R2 或接近年代的環境。當這些系統需要串接新版 HTTPS API、金流服務、銀行服務或第三方雲端服務時，常見的第一個反應是檢查 .NET Framework 版本與 TLS 1.2 設定。

但實務上，即使主機已安裝 .NET Framework 4.8，並且在程式碼裡強制 SecurityProtocolType.Tls12、註冊檔的 SchUseStrongCrypto 與 SystemDefaultTlsVersions 也都設為 1，仍可能在 TLS handshake 階段失敗。我們手上一個客戶就卡在這個狀態，整套設定都「按教科書」做齊了，連線還是斷在握手。

排查重點：TLS 版本與 cipher suite 是兩件事

TLS 1.2 代表雙方使用的通訊協定版本，但真正完成加密連線前，client 與 server 還需要協商出共同支援的 cipher suite。若服務端只允許較新的 ECDHE-RSA AES-GCM 或 CHACHA20 類型組合，而舊版 Windows Server 的 Schannel 不支援，就算應用程式指定 TLS 1.2，也無法完成 handshake。

第一步：寫一支能對照的小工具

要跳出設定迷宮，得問一個更基本的問題：到底是這台機器連不到，還是這支程式連不到？如果同一台機器上用兩種不同的 SSL/TLS 引擎去連同一個目標，結果不一樣，那責任就不在 .NET 設定，而在 OS 本身。

我們寫了一支小工具 Tls12Checker.exe，可選擇兩種 backend——一個走 .NET SslStream + HttpWebRequest（底層是 Windows Schannel），另一個走內嵌 libcurl + OpenSSL（完全不依賴 Schannel）。兩種同時跑、並列輸出，問題位置一目了然。

在進入握手之前，先把 .NET 端「該打開的開關」打到最徹底，確保失敗不會被誤認成 .NET 本身的問題：

// 1. 程式碼層：強制只用 TLS 1.2
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
ServicePointManager.Expect100Continue = false;

// 2. 註冊檔層：啟用 .NET Framework 強加密與系統預設 TLS 版本
//    HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
//      SchUseStrongCrypto       = 1 (DWORD)
//      SystemDefaultTlsVersions = 1 (DWORD)
//    HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
//      ↑ 同上兩個值，給 32 位元 process 用

Schannel 透過 SslStream 直接做最底層的握手測試，並把握手後協商出的 cipher / hash / key exchange 強度全部印出來。如果連這一步都失敗，問題明顯就是兩端 cipher suite 沒交集：

// Tls12Checker.cs — RunSslStreamProbe（節錄）
using (var client = new TcpClient())
{
    client.Connect(host, port);
    using (var network = client.GetStream())
    using (var ssl = new SslStream(network, false, (sender, cert, chain, errors) =>
    {
        // 印出憑證驗證結果，方便辨認是 cipher 問題還是憑證問題
        PrintCertificateValidation(errors, cert);
        return allowInvalidCert || errors == SslPolicyErrors.None;
    }))
    {
        // ★ 關鍵：明確指定 SslProtocols.Tls12，排除 TLS 版本誤判
        ssl.AuthenticateAsClient(host, null, SslProtocols.Tls12,
                                 checkCertificateRevocation: true);

        Console.WriteLine("  Handshake: OK");
        Console.WriteLine("  Protocol: " + ssl.SslProtocol);
        Console.WriteLine("  CipherAlgorithm: " + ssl.CipherAlgorithm
                          + " / " + ssl.CipherStrength + " bits");
        Console.WriteLine("  HashAlgorithm: " + ssl.HashAlgorithm
                          + " / " + ssl.HashStrength + " bits");
        Console.WriteLine("  KeyExchangeAlgorithm: " + ssl.KeyExchangeAlgorithm
                          + " / " + ssl.KeyExchangeStrength + " bits");
    }
}

第二步：對照結果立刻看出差異

到這一刻，「是 .NET 設定問題」的假設就被否決了。如果是 .NET 的問題，那也是 .NET 委派給 OS 的 Schannel 元件——而 Schannel 就是 Windows 內建的 SSL/TLS 函式庫。

第三步：用 SSL Labs 比對 cipher suite 取交集

把對方服務端的網址丟進 SSL Labs，看它的 TLS 1.2 接受清單。我們這個案例裡，對方只允許三組現代套件：

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

對照 Microsoft 官方文件 TLS Cipher Suites in Windows 8.1（Server 2012 R2 與 Win 8.1 同核），即使打了 Update KB2919355，預設啟用的 ECDHE-RSA 套件都是 CBC 模式，例如 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384。「ECDHE-RSA + AES-GCM」與「ECDHE-RSA + CHACHA20」這三組，就是沒列在 Server 2012 R2 的 Schannel 預設清單上。

兩邊 cipher suite 取交集——空集合。TLS handshake 在「協商共同 cipher suite」這步直接判定失敗，連憑證驗證都還沒進到。所以你看到的不是「憑證錯誤」「TLS 版本不對」，而是「SocketException / 連線被對方斷掉」這種看起來莫名其妙的錯誤。

三個方案的權衡：不是每個問題都該只改程式

確認真因之後，解法只有三個方向。我們把優劣攤開讓客戶選：

以這次案例來說，我們的角色是協助客戶定位問題並提出建議，實作則由客戶自己進行。考量客戶現況，我們建議他們先採用方案 B（TLS Proxy 中介）：不需要動原有應用程式、上線速度快，可以立刻解掉燃眉之急；同時也為客戶爭取時間，後續再依組織內的時程與資源，決定要不要進一步走方案 A（升級 OS）或方案 C（改程式）。

下次遇到類似症狀的 SOP

把這份排查順序塞進團隊 wiki，下次至少省一天：

1. 先檢查 OS：是不是 Server 2012 R2 / Win 8.1 / Server 2008 R2 這類舊系統？
2. .NET 該設的都設了（強制 TLS 1.2、SchUseStrongCrypto=1、SystemDefaultTlsVersions=1）但仍 handshake 失敗？
3. 到 SSL Labs 掃對方服務端，看它的 TLS 1.2 cipher 清單。
4. 比對 Microsoft 官方 OS cipher 預設清單。
5. 交集為空 → 100% 是 OS Schannel 問題，跳到上面三個方案的權衡。
6. 不確定？寫支小工具同時跑 dotnet 與 libcurl 兩個 backend 對照——AI 協作下這種一次性工具幾小時就能搞定。

從「靠推論動手」到「靠實測確認再動手」

過去面對這類疑難雜症，因為「寫一支只為了驗證一個假設的小工具」成本太高、時程也不允許，我們大多只能用推論解：根據症狀、官方文件、過往經驗推敲最可能的原因，挑一個方向直接動手實作。

這條路的風險是——推論常常會撞到沒料到的邊角狀況：某個 library 版本不一樣、某個作業系統細節不一樣、某個 API 邊界行為與文件描述不符——結果做了大半時程才發現方向錯了，整個推倒重來，客戶與我們都付出可觀的時間成本。

這一兩年我們的工作方式已經不同：藉由 AI 協作快速產出針對性的驗證工具，搭配團隊在系統開發、作業系統與網路層面累積的基礎，我們可以在動手實作之前就先用實測確認問題真正所在，再向客戶提出已經被驗證過、確切可行的解法。

以這個案子為例，Tls12Checker.exe 是我們在排查過程中花約 3 小時做出來的驗證工具——這種工具在過去光是處理嵌入式 libcurl native bundle 展開、x64 / x86 切換、CURL 選項 P/Invoke 等細節就要花一兩天。AI 協作大幅壓縮這個時程後，這支工具讓我們能：

• 並列比較兩個 backend：同時跑 .NET / Schannel 與 libcurl + OpenSSL，印出協商完成的 Protocol、CipherAlgorithm、HashAlgorithm、KeyExchange 強度，差異一眼可見。
• 把例外鏈完整 unwrap（Exception[0..n] + Message[0..n]）：把藏在好幾層 inner exception 裡的真正錯誤訊息一次攤平。
• 把問題定位從「我覺得」變成「實測證據」：同一個 .exe、同一個目標、同一個時間點，dotnet 後端失敗、libcurl 後端成功——客戶看到對照截圖立刻就懂：問題不在程式碼、不在 .NET 設定，而是 OS Schannel 的 cipher 清單。後續不管選哪個方案，都有共同的實測基礎可以討論、向上爭取資源。

PS> .\Tls12Checker.exe https://your-target/ --backend both --timeout 30000
PS> .\Tls12Checker.exe https://your-target/ --backend libcurl     # 只跑 libcurl，驗證是不是 Schannel 問題
PS> .\Tls12Checker.exe https://your-target/ --allow-invalid-cert  # 跳過憑證驗證，先測純握手

關鍵節錄：libcurl backend 的繞道做法

libcurl 是把 OpenSSL 整包靜態連進來，整個 SSL/TLS 路徑完全跳過 Windows Schannel。下面這段就是「方案 C」的核心——把 .NET 端的 HTTPS 連線改走這條路：

// Tls12Checker.cs — RunLibcurlProbe（節錄）

// 1. 載入嵌入式 libcurl.dll（或外部指定路徑）
var resolvedLibcurlPath = LibcurlNative.ResolveAndPreload(libcurlPath);
LibcurlNative.curl_global_init(LibcurlNative.CURL_GLOBAL_DEFAULT);

IntPtr handle = LibcurlNative.curl_easy_init();
IntPtr errorBuffer = Marshal.AllocHGlobal(LibcurlNative.CURL_ERROR_SIZE);

// 2. 設定請求選項：URL、timeout、error buffer、忽略 redirect
SetCurlOption(handle, LibcurlNative.CURLOPT_URL, uri.AbsoluteUri);
SetCurlOption(handle, LibcurlNative.CURLOPT_USERAGENT, "Tls12Checker/libcurl");
SetCurlOption(handle, LibcurlNative.CURLOPT_ERRORBUFFER, errorBuffer);
SetCurlOption(handle, LibcurlNative.CURLOPT_TIMEOUT_MS, timeoutMs);
SetCurlOption(handle, LibcurlNative.CURLOPT_CONNECTTIMEOUT_MS, timeoutMs);
SetCurlOption(handle, LibcurlNative.CURLOPT_FOLLOWLOCATION, 0);

// ★ 關鍵：強制使用 TLS 1.2（libcurl 的 OpenSSL backend 會處理 cipher 協商，
//   不依賴 Schannel 的 cipher 清單）
SetCurlOption(handle, LibcurlNative.CURLOPT_SSLVERSION,
              LibcurlNative.CURL_SSLVERSION_TLSv1_2);

// 3. 執行請求、取回 HTTP status
var code = LibcurlNative.curl_easy_perform(handle);
if (code == 0)
{
    long responseCode;
    LibcurlNative.curl_easy_getinfo(handle, LibcurlNative.CURLINFO_RESPONSE_CODE,
                                    out responseCode);
    Console.WriteLine("  Request: OK");
    Console.WriteLine("  HTTP Status: " + responseCode);
}

// 4. 清理
LibcurlNative.curl_easy_cleanup(handle);
LibcurlNative.curl_global_cleanup();
Marshal.FreeHGlobal(errorBuffer);

實務上把這段抽成一個 HttpsClient 包裝類別，原本程式裡用 HttpWebRequest 的地方換成這個類別即可。libcurl.dll 可以放在 exe 旁邊，或像我們的工具一樣以嵌入式 native bundle 形式打包進 assembly 內，部署時只要一個 exe 帶過去就好。

給企業的建議：API 串接前，先盤點環境能力

舊系統串接新版 API 時，問題常常不只在一段程式碼。作業系統、runtime、憑證、TLS 版本、cipher suite、proxy、DNS、防火牆與第三方服務安全政策，都可能影響最後結果。

Larvata 在處理這類問題時，會先把問題拆成「應用程式層、作業系統層、網路層、第三方服務層」來排查，避免在錯誤方向上反覆修改。我們可以協助你定位問題、提出可行方案的取捨建議——後續實作可以由你的團隊接手，也可以由我們協助完成；對企業來說，這類排查不只是解 bug，也是在確認既有系統是否還能支撐未來的 API 整合與資安要求。