別急著關掉 TLS 1.2：升級 TLS 1.3 前該懂的 Windows 相容性真相
資安弱掃跑完，報告上一條紅字：偵測到過時的 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 的核心措辭是使用「強式密碼學」，PCI SSC 已明確把 SSL／early TLS 排除在外，並長期建議遷移到 TLS 1.2 以上；它沒有普遍要求所有環境只能使用 TLS 1.3。實際是否合規仍要一起看 cipher suite、系...
IIS 用 C# 呼叫 LibreOffice：轉檔權限與逾時修正
我第一次把 LibreOffice 轉檔程式部署到 IIS 時，本機能跑，伺服器卻只留下三種結果：沒有輸出檔、權限不足，或 soffice.exe 卡著不結束。 我一開始把問題全歸到身分模擬，照網路範例串了 LogonUser、ImpersonateLoggedOnUser、DuplicateTokenEx 和 CreateProcessAsUser。程式變長一大截，權限也越開越多，問題仍然不好查。 後來我才發現，這個做法把兩件事混在一起了：誰負責執行 LibreOffice，以及程式怎麼確認轉檔成功。固定由同一個帳號轉檔時，最直接的解法是讓 IIS 應用程式集區本身就用那個身分執行，再由 Process.Start 啟動 LibreOffice。這樣不需要在每次請求裡切換 Windows token，也不用把密碼塞進 Web.config。 2026-07-27 修訂：舊版文章把 CreateProcessAsUser 的權限授予對象寫錯，也多做了一次不必要的 DuplicateTokenEx。這次依 Microsoft 與 LibreOffice 官方文件重寫，舊程式碼不建...
