我閱讀了很多關於WCF安全性的文章，但仍然沒有關於證書方案的清晰圖片。我們的部署環境具有NLB羣集（前端），只有少量ASP.NET站點與應用程序服務器（後端，也是NLB羣集）通信。 我們需要通過相互證書認證和SSL來保護它。 我是正確，我們需要做到以下幾點：與CN =應用程序服務器，NLB主機名和「服務器身份驗證」目的集羣環境中的相互WCF證書身份驗證/ SSL
我的問題是：
你好。由於沒有其他人回答，我會採取一些措施 - 但公平的警告 - 我是一名Java/UNIX開發人員，並且您提出的一些問題與Microsoft有關。但這裏有一個幾個答案：
1 - 發出與 CN =應用程序服務器，NLB主機名和 域CA. 「服務器身份驗證」目的的證書
目的是微軟具體的事情。這聽起來不錯，而且 - 您可能需要定期的「密鑰使用」纔是特別的 - 對於我通常使用keyEncipherment或keyAgreement的SSL證書。有時候網站使用digitalSignature。所有這三個在RFC中都是有效的，但是有時候微軟對於哪些工作有些w w。如果您使用Microsoft CA，我會看看它是否具有SSL證書的證書配置文件，並使用它。
2 - 使用「客戶端身份驗證」 目的發佈前端 框的證書。
與＃1相同 - 每個證書都需要某種基本的密鑰用法。您提到的字段是擴展用法，這可能也是必需的，但不是強制性的。
3 - 將後端證書的公開 密鑰導入前端節點的存儲器 （反之亦然）。
只有當這是微軟特定的事情。在正確的PKI中，您應該導入簽名SSL的可信CA的證書，但不必將每個端點（如後端證書）導入到前端。我會嘗試一下，只配置可信的CA鏈，看看能否讓它工作 - 從長遠來看，這會讓你的架構更具可擴展性。
4 - 配置WCF與 傳輸安全
5使用net.tpc - 配置服務行爲 （serviceCredentials部）
6 - 配置客戶端端點 行爲（clientCredentials部）
聽起來對我很好...
從那裏，我不認爲你已經錯過了別的。關鍵通常是通過模糊的錯誤消息。每個系統都有自己難以辨認的SSL握手失敗時出現問題的方式，所以它主要是瞭解哪裏出了問題。
從你描述的問題，我不認爲認爲你的安全架構是說你需要做一個證書狀態檢查。這是一種附加措施，可讓您的系統檢查證書是否已被CA吊銷。需要相當多的基礎設施才能使其工作（CRL或OCSP），所以我不會說你應該在沒有認真討論你的團隊的情況下轉而去尋求你的努力緩解什麼樣的風險，以及他們有多可能發生。
應該爲哪個主機名前端證書頒發？
它們代表的服務器的主機名。
關於主機名的問題 - 除非您使用完全限定的域名，否則某些系統將無法正常工作。其他人並不那麼挑剔。無論如何 - 證書的主題DN應該唯一地描述它所代表的服務，應用程序或服務器。
前端節點位於DMZ中，因此無法訪問域（CA）。這會導致任何問題嗎？
你不會有問題。
除非 - 您需要執行上述證書狀態檢查。如果您必須驗證證書狀態，則需要從終點（即DMZ）到證書狀態信息（CRL或OCSP服務器）。在複雜的基礎設施中，這通常是通過打開OCSP服務器的路徑完成的 - 這是一個到固定域名或IP的HTTP GET，因此在防火牆上打開路徑通常不會太糟糕。
就像我說的那樣，這將是高端的，嚴重的風險緩解型解決方案。對你的系統來說這可能是矯枉過正的 - 我對你的系統知之甚少，無法告訴你它是否有保證。