我需要為我的應用程式和 Sql Server 2008 之間的傳輸實作 SSL。
我使用的是 Windows 7、Sql Server 2008、Sql Server Management Studio，我的應用程式是用 c# 寫的。
我試圖按照有關建立憑證的 MSDN 頁面進行操作這在「針對特定客戶的加密」下，但我感到非常困惑。我需要一些小步驟才能在成功實施加密的道路上走得更遠。
首先，我不懂MMC。我在那裡看到很多證書...這些證書是我應該用於我自己的加密還是這些證書用於已經存在的東西？另一件事，我假設所有這些憑證都是檔案位於我的本機電腦上，那麼為什麼會有一個名為「個人」的資料夾？
其次，為了避免上述問題，我用自簽名程序集做了一個小實驗。如上面的MSDN連結所示，我使用SSMS中執行的SQL來建立自簽名憑證。然後我使用以下連接字串進行連接：
Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword;Encrypt=True;TrustServerCertificate=True
它連接起來，工作正常。然後我刪除了剛剛創建的證書，它仍然有效。顯然它從來沒有做任何事情，但為什麼不呢？我該如何判斷它是否真的「有效」？我想我可能錯過了（以某種方式？）將文件從 SSMS 獲取到客戶端的中間步驟？
我根本不知道自己在做什麼，所以我非常感謝您能給我的任何幫助、建議、評論、參考。
先感謝您。 :)
答案1
如果我正確理解 MSDN 規範，您只需在連接字串中指定即可Encrypt=True;TrustServerCertificate=True。這意味著客戶端請求加密並願意接受伺服器可能使用的任何證書。如果沒有其他可用的情況，伺服器始終具有在伺服器啟動時產生的自簽名憑證可供使用。如果客戶願意接受任何證書，那麼它將接受該伺服器的臨時自簽名證書，與任何證書一樣好。
這樣的設定提供的是應用程式和伺服器之間的加密通訊通道，這是一個無法輕易監聽的通道。然而，該通道容易受到惡意中間人攻擊。如果攻擊者可以欺騙客戶端連接他而不是伺服器（例如，透過控制 DNS 記錄，更準確地說是客戶端將使用的 DNS 伺服器 IP，這是一個簡單的 DHCP 設定來控制），那麼攻擊者可以提供任何憑證並且客戶端會接受它，然後它可以與客戶端進行完整的身份驗證往返，從而獲得使用的 SQL 用戶名和密碼，然後它可以連接到真實伺服器並來回轉發所有通信，免費查看全部內容。客戶永遠不會知道正在被「監控」。這就是「中間人」攻擊。
為了防止上述情況的發生，客戶必須刪除來自TrustServerCertificate=True連接字串的。完成此操作後，伺服器使用的證書有得到客戶的信任，這就是所有複雜情況出現的時候。如果您可以接受較弱的設置，並且您有加密的流量，但您理解那你可能遭受中間人攻擊並且您對此表示同意，然後使用更簡單的TrustServerCertificate=True設定。如果沒有，那麼不幸的是，您必須真正了解自己在做什麼，而這並不是微不足道的。如果數據是所以重要的是，也許花錢為您的伺服器購買 VeriSign、Thawte 或 GlobalSign（這是每個 Windows 用戶端信任的 3 個根）憑證（約 500 美元/年）並不是那麼奇怪。
答案2
「個人」是憑證儲存的一個誤導性名稱。當您在 MMC 中時，如果您看到可以選擇的證書，則可能沒問題。我建議使用真實的證書。這可以是使用 Microsoft 證書伺服器內部建立的證書，也可以是從證書提供者購買的證書。我不會使用自簽名憑證。 SQL Server 執行個體服務也必須重新啟動才能生效。
一些一般提示：
如果在用戶端上強制加密，則用戶端上的所有 SQL 通訊都必須使用傳輸級加密。
如果您在伺服器上強制加密，則該實例的所有 SQL 通訊都必須使用傳輸級加密。
無論您選擇哪種配置（選擇性的或強制的），您的應用程式仍然需要支援各種連接選項。例如加密連線關鍵字。
我個人發現 SQL Native 用戶端比內建 SQL 用戶端提供更多描述性錯誤訊息，但您可以使用/強制加密。
Microsoft 的文檔有點粗略，但有幾篇不錯的文章：
選擇性地使用與 SQL Server 的安全連接
關聯
如何使用 Microsoft 管理控制台為 SQL Server 執行個體啟用 SSL 加密
http://support.microsoft.com/kb/316898
在 SQL Server Native Client 中使用連線字串關鍵字
http://msdn.microsoft.com/en-us/library/ms130822.aspx